9.12 Kubernetes Container Health Probe Flow

Kubernetes Container Health Probe Flow is the operational sequence by which the kubelet repeatedly invokes a container's configured probes, interprets their results, and translates those results into concrete actions such as restarting a container or adjusting its inclusion in Service endpoints. This flow ties together the startup, liveness, and readiness probe types into a coordinated evaluation cycle that runs continuously for the life of each container.

Probe Mechanisms

HTTP GET Probes

An HTTP GET probe issues a request to a specified path and port within the container, treating any response with a status code between 200 and 399 as success, and any other response, connection failure, or timeout as failure, making it well suited for containers exposing a dedicated health endpoint.

TCP Socket Probes

A TCP socket probe attempts to open a connection to a specified port, treating a successful connection as success regardless of any application-level response, which is useful for services that do not expose an HTTP interface but can still confirm they are accepting connections.

Exec Probes

An exec probe runs a specified command inside the container, treating an exit code of zero as success and any non-zero exit code as failure, offering the most flexibility since arbitrary internal checks can be encoded directly into a script or binary invoked by the probe.

gRPC Probes

A gRPC probe invokes the standard gRPC health checking protocol against the container, treating a SERVING response as success, providing a native mechanism for gRPC-based services without requiring a separate HTTP or exec-based health endpoint to be maintained alongside the primary service.

Timing Parameters Governing the Flow

initialDelaySeconds and periodSeconds

The initialDelaySeconds field delays the first probe execution after the container starts, while periodSeconds determines how frequently the probe is subsequently repeated, together shaping how quickly the kubelet begins forming an opinion about the container's health after it starts running.

timeoutSeconds

The timeoutSeconds field bounds how long the kubelet waits for a single probe attempt to respond before considering that individual attempt a failure, which is distinct from the overall pattern of repeated failures needed to trigger an action.

successThreshold and failureThreshold

The successThreshold field specifies how many consecutive successes are required to consider a probe healthy again after having failed, while failureThreshold specifies how many consecutive failures are required before the probe is considered to have failed overall, together preventing single transient blips from triggering unnecessary actions.

Startup Probe Gating the Flow

Suppression of Other Probes Until Startup Succeeds

If a startup probe is defined, the kubelet executes only that probe initially, withholding liveness and readiness evaluation entirely until the startup probe reports success, which prevents a slow-initializing application from being killed by an impatient liveness probe or marked unready prematurely.

Transition Into Regular Probe Cycling

Once the startup probe succeeds, or immediately if none is configured, the kubelet begins the regular cycle of evaluating liveness and readiness probes independently and concurrently, each following its own configured timing parameters from that point forward.

Divergent Consequences of Liveness and Readiness Results

Liveness Failure Leads to Restart

When a liveness probe accumulates enough consecutive failures to reach its failureThreshold, the kubelet kills the container's process, after which the container proceeds through the standard restart handling and backoff logic dictated by the Pod's restartPolicy.

Readiness Failure Leads to Endpoint Removal

When a readiness probe fails past its threshold, no restart occurs; instead, the container's ready field is set to false, which propagates to the Pod's aggregate readiness conditions and results in the Pod being removed from the endpoint list of any Services selecting it until readiness is restored.

Continuous Nature of the Flow

No Terminal State While Running

Unlike a one-time check performed only at startup, the probe flow persists indefinitely for as long as the container remains in the Running state, meaning health is treated as an ongoing property that must be continuously reaffirmed rather than a status established once and assumed to hold indefinitely thereafter.