Closed leochr closed 5 years ago
@jwalcorn The nodePort
field is hardcoded in the Service
under deploy.yaml
. Wondering if that's really necessary. In the event of port collisions, the system would be unable to allocate that port.
We had been hardcoding that because we needed to register the redirect URL for IBMid, and we needed to be able to predict that URL ahead of time. But lately we've not been using the OpenID Connect path (to IBMid), but have instead been using just basicRegistry. Also, we have adopted Ingress now, so we are trying to wean ourselves off of node ports.
I've also been having some health endpoint discussions with @kyleschlosser. Can this be used to specify a readinessProbe?
@jwalcorn thanks for the response. Glad that we don't need to include/worry-about hardcoded nodePort
in values yaml.
Right now, our chart uses HTTP endpoint /
(or /health
if MicroProfile Health is enabled) to determine readiness. We are enhancing our Liberty chart to allow customizing readinessProbe, so users can specify a custom endpoint (e.g. /trader
).
So where do I define my Ingress? Right now, there are 3 Kubernetes objects defined in my full deploy.yaml: the deployment, the service, and the ingress. I think the Liberty helm chart is doing the service for me. But what about the ingress?
Oh, never mind. I see the ingress:
section in the trader-values.yaml now.
Right, it's controlled by the ingress
parameter.
Regarding monitoring, please check the information in Readme and Release notes about some of the limitations (due to ICP) and evaluate it's fine for these microservices.