Add kubernetes readiness check uri

[vinny-sabatini]

Is your feature request related to a problem? Please describe.

In a Kubernetes deployment, it is recommended to include a readiness check for your application to let Kubernetes know when your pods are ready to accept traffic. A readiness endpoint should be created for the Eunomia operator, and it should be included in the Eunomia deployment.

Describe the solution you'd like

A /readiness endpoint is created that returns 200 when the operator is able to access the Kubernetes API. This should be included in the deployment of Eunomia.

Describe alternatives you've considered

It may be possible to add this into the operator-sdk itself. It looks like there is an issue that may include a Liveness and Readiness probe.
I'm not exactly sure how it would work if it were included in the operator-sdk in the case that an end user wants to have a different check/include additional checks. I would assume it would need to be extendable/configurable for the different operator use cases.

What version of eunomia are you using?

eunomia version: v0.0.5

Additional context

• Issue Add kubernetes liveliness(health) check uri #248 has been created to add the health/Liveness endpoint to Eunomia
• Here is the issue in the operator-sdk repo - Health Check (Liveness and Readiness probe for Operator) operator-framework/operator-sdk#1234

[akavel]

1. How are the semantics of this endpoint expected to differ vs. the one from Enable GCP LB's to work with Eunomia #180? Typically I'd expect one endpoint to be a dumb "always return HTTP 200", and a second one checking if the app can do anything reasonable (so, checking if we can contact Kubernetes API?) Now, both this issue (Add kubernetes readiness check uri #210) and Enable GCP LB's to work with Eunomia #180 seem to mention some detailed checks, so I'm not sure how exactly we want them to differ.
2. Do you know by chance if there's some specific Kubernetes API we could reasonably use for the check? Or do we want to leave it to be researched by the implementor? (sounds reasonable to me, just asking if you maybe happen to know some cool one off the top of your head)

[vinny-sabatini]

For 1, great call out, I'm checking in the other issue to see which issue should create the readiness check and which issue should create the health check so we don't have duplicate issues.
For 2, maybe we have it try to get the gitopsconfigs.eunomia.kohls.io in the namespace?

[akavel]

@vinny-sabatini by "get the gitopsconfigs..." you mean basically kubectl get gitopsconfigs...`, did I understand this correctly? sounds like a good idea to me, thanks!

[vinny-sabatini]

Yes, a kubectl get gitopsconfigs.eunomia.kohls.io was what I had in mind

[sanbornick]

Does it make sense to follow the z-pages pattern for this endpoint @vinny-sabatini @seanmalloy? If so endpoint should be /readinesszthen.

[sanbornick]

#180 is about specific GCP LB use cases. Instead I've created a new issue to track just the health endpoint and we can leave #180 out there to track this GCP LB use case. I've updated the issues main description with the new related issue.

[sanbornick]

Additionally, this could check the connectivity to the scm but that may get complicated quickly and could be its own issue.

[seanmalloy]

I good with /readinessz or /readyz