The new ability to specify a HEALTHCHECK in a Dockerfile seems redundant with the Kubernetes probe directives. Any advice on what to use when?
When to use Docker HEALTHCHECK vs livenessProbe / readinessProbe
23.5k views Asked by Kushal Dave At
2
There are 2 answers
0
On
On Docker
the HEALTHCHECK is basically a command running recurrently during the lifespan of the container. It is used to let the Docker daemon know about the health (i.e. state) of a container.
It is not always useful in general contexts.
On Kubernetes
the liveness probe is a command running recurrently during the lifespan of the container to let the Kubelet know the container is alive and healthy (i.e. up-and-running). The liveness probe is considered successful if the command returns 0, and failed when it returns a non-zero value. If the liveness probe fails, the container is killed and restarted by the Kubelet.
the readiness probe is a command running recurrently during the lifespan of the container to let the Kubelet know if a pod is ready to receive traffic (i.e. ready to work as expected) while it is already alive.
It is useful in the sense that it provides some level of resilience by detecting unhealthy containers that will be automatically restarted.
If you use Kubernetes, I'd suggest using only the Kubernetes liveness/readiness checks because Docker healthcheck has not been integrated in the Kubernetes as of now (release 1.12). This means that Kubernetes does not expose the check status in its api server, and the internal system components can not consume this information. Also, Kubernetes distinguishes liveness from readiness checks, so that other components can react differently (e.g., restarting the container vs. removing the pod from the list of endpoints for a service), which the docker HEALTHCHECK currently does not provide.
Update: Since Kubernetes 1.8, the Docker HEALTHCHECK has been disabled explicitly in Kubernetes.