Menu
The new ability to specify a HEALTHCHECK in a Dockerfile seems redundant with the Kubernetes probe directives. Any advice on what to use when?
374
Summary. Both liveness & readiness probes are used to control the health of an application. Failing liveness probe will restart the container, whereas failing readiness probe will stop our application from serving traffic.
The HEALTHCHECK directive tells Docker how to determine if the state of the container is normal. This was a new directive introduced during Docker 1.12.
Update: Since Kubernetes 1.8, the Docker HEALTHCHECK has been disabled explicitly in Kubernetes.
Protect slow starting containers with startup probes The trick is to set up a startup probe with the same command, HTTP or TCP check, with a failureThreshold * periodSeconds long enough to cover the worse case startup time.
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.
72
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
