For the values.yamls, there are currently a couple of different structures to help build out k8s services and ingresses. This information is used to create hostnames in the global-env-vars configmap. As an example:
services:
engine:
port: 9031
targetPort: 9031
dataService: true
ingress:
hosts:
- host: pingfederate-engine._defaultDomain_
paths:
- path: /
backend:
servicePort: 443
creates:
PF_ENGINE_PUBLIC_HOSTNAME=pingfederate-engine
PF_ENGINE_PRIVATE_HOSTNAME=pingfederate-engine.{_defaultDomain_}
We also want to create additional variables of the type:
PF_ENGINE_PUBLIC_ENGINE_PORT=9031
PF_ENGINE_PRIVATE_ENGINE_PORT=443
It looks duplicative, however, the second use of ENGINE
is because there are some products (i.e. PingDirectory), where you might have multiple ports (i.e. 443, 289, 2443, 636, ...) that you want lit up publically, and with potentially different hostnames (we'll save that for later).
Having the service and ingress ports in separate structures makes it difficult to a) manage and b) process this in a predictable manner. I think we would propose the following. I'm using an example with PD to help make the point of multiple ports:
services:
api:
containerPort: 8443 <--- changed from targetPort
servicePort: 1443 <--- changed from port
ingressPort: 443 <--- new. moved from ingress
dataService: true
data-api:
containerPort: 9443 <--- changed from targetPort
servicePort: 2443 <--- changed from port
ingressPort: 2443 <--- new. moved from ingress
dataService: true
ingress:
hosts:
- host: pingdirectory.example.com
paths:
- path: /api
backend:
serviceName: api
- path: /directory/v1
backend:
serviceName: data-api
would create:
PD_PUBLIC_HOSTNAME=pingdirectory
PD_PUBLIC_API_PORT=443
PD_PUBLIC_DATA_API_PORT=2443
PD_PRIVATE_HOSTNAME=pingdirectory.example.com
PD_PRIVATE_API_PORT=443
PD_PRIVATE_DATA_API_PORT=2443