9.13 Kubernetes Liveness Probe Behavior

Kubernetes Liveness Probe Behavior is the specific set of mechanics governing how the kubelet uses a liveness probe to determine whether a running container has entered an unhealthy or unrecoverable state, and how it responds to that determination by killing and, according to restart policy, restarting the affected container, distinguishing this probe type from readiness and startup probes by its direct authority to terminate a container.

Purpose and Underlying Assumption

Detecting Non-Crashing Failures

Liveness probes exist to catch failure modes where a container's process continues running without crashing, yet the application inside it has become unresponsive, deadlocked, or otherwise incapable of making forward progress, conditions that would otherwise go undetected since the container's process itself remains alive from the operating system's perspective.

The Restart-as-Recovery Assumption

The entire liveness probe mechanism rests on the assumption that restarting the container's process is a valid recovery strategy for whatever condition caused the probe to fail, which holds true for many transient issues such as memory leaks or stuck threads, but is not universally appropriate for every failure mode.

Configuration Fields

Probe Type Selection

A liveness probe can be configured using an HTTP GET request, a TCP socket connection attempt, an exec command, or a gRPC health check, with the choice depending on what health signal the application can most naturally expose, such as a dedicated /healthz endpoint for HTTP-based checks.

Timing and Threshold Fields

The initialDelaySeconds, periodSeconds, timeoutSeconds, successThreshold, and failureThreshold fields together determine how soon after container start the probe begins, how often it runs, how long each attempt is given to respond, and how many consecutive failures or successes are required before a state change is triggered.

Failure Accumulation and Restart Trigger

Consecutive Failure Counting

The kubelet tracks consecutive probe failures for each container independently, and only once the count reaches the configured failureThreshold does it take action; isolated, non-consecutive failures interspersed with successes do not accumulate toward triggering a restart.

Immediate Kill Upon Threshold Breach

Once the failure threshold is reached, the kubelet kills the container's process immediately, without waiting for any additional grace period beyond what is defined by terminationGracePeriodSeconds for the shutdown itself, and the container then proceeds through the same restart and backoff handling applied to any other termination.

Interaction With Startup Probes

Suppression During Startup

If a startup probe is defined for the container, liveness probe evaluation does not begin until the startup probe has succeeded, preventing an application with a legitimately long initialization time from being killed by a liveness probe that would otherwise start checking too early and mistake normal startup delay for a genuine failure.

Risk of Premature Liveness Checks Without a Startup Probe

In the absence of a startup probe, setting initialDelaySeconds too low relative to an application's actual startup time can cause the liveness probe to begin failing before the application has finished initializing, resulting in a restart loop caused entirely by misconfigured timing rather than any real application defect.

Independence From Readiness State

No Effect on Service Endpoint Membership

A liveness probe's pass or fail status has no direct bearing on whether the Pod is included in Service endpoints; that determination is governed exclusively by the readiness probe. A container can be failing its liveness probe and about to be restarted while still, momentarily, being considered ready if its readiness probe has not yet reflected the same underlying problem.

Risks of Misconfigured Liveness Probes

Cascading Restarts Under Load

A liveness probe configured with an overly aggressive timeout or an endpoint that itself depends on a slow downstream resource can cause the kubelet to interpret temporary application slowness under load as a failure, triggering unnecessary restarts that further degrade the very load conditions causing the slowness in the first place.

Guidance Toward Lightweight, Independent Checks

Because of this risk, effective liveness probe design favors lightweight checks that verify only that the process itself is responsive, avoiding checks that depend on the health of external systems such as databases, which are better suited to influencing readiness rather than triggering a restart of the container itself.