Cloud-Native Microservices With Kubernetes - 2nd Edition

The Fundamentals of Health Checks: Liveness, Readiness, and Startup

Kubernetes health checks are implemented using 3 types of probes:

• Liveness Probe: This probe determines if a container is running. If it fails, Kubernetes will kill the container and restart it. This is useful for detecting and recovering from situations where an application is running but is stuck in a non-responsive state.

• Readiness Probe: This probe determines if a container is ready to accept traffic. If it fails, Kubernetes will remove the Pod from the list of available endpoints for services (e.g., a ClusterIP service will stop sending traffic to that Pod). This is useful for preventing traffic from being sent to a container that is not yet ready to handle requests, such as during startup or when it is overloaded.

• Startup Probe: This probe is used to determine if a container has started successfully. If it fails, Kubernetes will kill the container and restart it. This is useful for applications that have a long startup time and may not be ready to accept traffic immediately after being started.

Liveness and Startup probes may seem similar, but they serve different purposes. The Startup probe is used to determine if a container has started successfully, while the Liveness probe is used to determine if a container is running and responsive. We can use the Liveness probe to check if the application has started successfully, but separating the two probes allows us to have more granular control over the health checks and separate the concerns of startup and runtime health, especially for applications with long startup times.

There's another difference between the two probes: the Startup probe is executed only once, when the container is started. When it succeeds, it is never executed again. The Liveness probe, on the other hand, is executed periodically throughout the lifetime of the container.

The following table summarizes this section: