Return 200 on / when ready

[Legogris]

This is for playing nicely with Google's Load balancer, which requires that pods respond with 200 on /. Reuses the /ready response with 200 instead of 204 on ready.

[CLAassistant]

All committers have signed the CLA.

[steven-sheehy]

You need to sign the CLA.

Also, I don't use GCP but just glancing at the docs it seems like you can specify a --request-path for the health check?

[Legogris]

Also, I don't use GCP but just glancing at the docs it seems like you can specify a --request-path for the health check?

Indeed. However, when using GKE Ingresses with Google's Loadbalancer, health checks will be automatically created (see https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#health_checks and https://cloud.google.com/kubernetes-engine/docs/tutorials/http-balancer#remarks).
If user overrides this (by editing the backend/health check), it will work but be overriden by GCP automatically (for example I had this happen when a pod was replaced due to OoM).

Actually overriding the default / health check is pretty finicky and failprone (though possible) and expects a 200 (just verified it failing on 204). This is different from the k8s readiness/liveness checks that seem to be happy with a 204.

I see two alternatives to this:

1. Make /ready return 200 instead of 204
2. Change the probes in the provided helm charts to use /metrics as url instead of /ready

In general it will make things a lot less more straightforward for GKE users if / returns 200, or at least if the default readiness and liveness probes do.

[steven-sheehy]

If you're using the helm chart, you can already override the health check to use /metrics in your custom values.yaml. I think making /ready return 200 sounds reasonable, just return some success message in the content as well.

[Legogris]

If you're using the helm chart, you can already override the health check to use /metrics in your custom values.yaml. I think making /ready return 200 sounds reasonable, just return some success message in the content as well.

Yeah, that's what we ended up doing to make it work. How about /ready returning 200 with the server timestamp as content perhaps?

Is there any particular reason against deciding against 200 for /? I am certain that there are other users who would appreciate that.

[steven-sheehy]

I think a string constant "Health check successful" or similar would be fine.