chart: add liveness/readiness probes to chartsvc deployment #645
Conversation
chartsvc has endpoints for checking liveness and readiness but we were not taking advantage of these in our Kubernetes configurations. This updates the chart to configure the probes for this service.
| @@ -124,6 +124,18 @@ chartsvc: | |||
| # requests: | |||
| # cpu: 100m | |||
| # memory: 128Mi | |||
| livenessProbe: | |||
| httpGet: | |||
| path: /live | |||
There was a problem hiding this comment.
Is this route (/live) based on any common practice? I've seen the proliferation of healthz instead
There was a problem hiding this comment.
I see, you are just just using them.
There was a problem hiding this comment.
@migmartri when I implemented this in chartsvc, I used the https://github.com/heptiolabs/healthcheck library that suggests using /live and /ready https://github.com/heptiolabs/healthcheck#usage. Specifically, the difference from using a single /healthz is having two separate endpoints that might have different implementations of the healthcheck (e.g. /ready might check that MongoDB is connectable, though not currently implemented).
There was a problem hiding this comment.
Oh nice, I was not aware of that library, thanks for the info.
Specifically, the difference from using a single /healthz is having two separate endpoints that might have different implementations of the healthcheck (e.g. /ready might check that MongoDB is connectable, though not currently implemented).
Right, in the past I've been handling this by passing a liveness parameter to the /healthz endpoint.
There was a problem hiding this comment.
@migmartri makes sense, yeah, the name of the endpoints doesn't matter much here I guess, although I agree that healthz is more common. /live and /ready are also possibly too specific to Kubernetes, although the concept does transfer across. Either way, probably not important enough to change.
There was a problem hiding this comment.
@migmartri makes sense, yeah, the name of the endpoints doesn't matter much here I guess, although I agree that
healthzis more common./liveand/readyare also possibly too specific to Kubernetes, although the concept does transfer across. Either way, probably not important enough to change.
No it's not important, thanks for the info.
There was a problem hiding this comment.
I looked at the implementation of those healthchecks and it seems that they do not do much apart of being mounted. So I think that this task is still valid.
|
Refs #502 |
| httpGet: | ||
| path: /ready | ||
| port: 8080 | ||
| initialDelaySeconds: 0 |
There was a problem hiding this comment.
What's the default? Or you want to be explicit?
There was a problem hiding this comment.
Oddly, the documentation doesn't specify what the default is: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#probe-v1-core. I just copied these from the other services that have healtchecks (dashboard and frontend). I think it's good to be explicit (especially given it's unclear what the default is), and I think that it's fine for readiness to not have any delay. The initialDelaySeconds for liveness might actually be too long for a simple service like this, but this could give it more time to attempt to connect to MongoDB.
There was a problem hiding this comment.
As a funny note. In their advanced example, they mount the readiness check as healthz :P https://godoc.org/github.com/heptiolabs/healthcheck
chartsvc has endpoints for checking liveness and readiness but we were
not taking advantage of these in our Kubernetes configurations. This
updates the chart to configure the probes for this service.