9.14 Kubernetes Readiness Probe Behavior

Kubernetes Readiness Probe Behavior is the mechanism by which the kubelet continuously evaluates whether a container is currently capable of handling live traffic, using the result to control the container's inclusion in the endpoint lists of any Services that select its Pod, without triggering a restart of the container regardless of how the probe evaluates, distinguishing it sharply from liveness probe behavior.

Purpose and Underlying Assumption

Separating Alive From Available

Readiness probes exist because a container can be entirely healthy and running correctly while still being temporarily unable to serve requests, such as during a warm-up phase, while reconnecting to a dependency, or while performing a resource-intensive background task, and restarting the container in these situations would be both unnecessary and counterproductive.

Traffic Gating Rather Than Recovery

Unlike liveness probes, which assume restarting the container is the correct recovery action, readiness probes assume the container will recover on its own given time, and the correct response to a failure is simply to withhold traffic temporarily rather than intervene directly in the container's execution.

Configuration Fields

Shared Mechanism Types With Other Probes

Readiness probes support the same set of check mechanisms as liveness and startup probes, including HTTP GET requests, TCP socket connection attempts, exec commands, and gRPC health checks, allowing the same underlying health-checking infrastructure to be reused across all probe types with different consequences attached to their outcomes.

Independent Timing Configuration

Although readiness probes use the same initialDelaySeconds, periodSeconds, timeoutSeconds, successThreshold, and failureThreshold fields as liveness probes, these values are configured independently for each probe type, allowing a container to, for example, check readiness far more frequently than liveness if traffic-routing responsiveness is a priority.

Effect on Pod Readiness Condition

Container-Level to Pod-Level Aggregation

Each container's individual readiness result feeds into the Pod-level ContainersReady condition, which requires every container in the Pod to be ready simultaneously, meaning a single unready container, even a minor sidecar, can prevent the entire Pod from being considered ready overall.

Continuous Reevaluation

Readiness is not a one-time gate passed during startup; it is continuously reevaluated on the configured periodSeconds interval for the entire time the container is running, meaning a Pod that has served traffic successfully for hours can still transition back to not ready if its readiness probe begins failing.

Consequence of Failure: Endpoint Removal

No Restart Triggered

When a readiness probe fails past its failureThreshold, the kubelet takes no direct action against the container's process; it simply updates the container's ready field to false, leaving the container running exactly as it was, distinguishing this clearly from the kill-and-restart behavior of a failing liveness probe.

Removal From Service Endpoints

The Endpoint or EndpointSlice controller watches Pod readiness and removes any Pod whose Ready condition has become false from the list of active endpoints backing its Services, meaning new traffic stops being routed to that Pod almost immediately after the readiness failure is detected, while existing established connections may continue depending on the networking layer in use.

Recovery and Reinstatement

Automatic Endpoint Reinstatement

Once a readiness probe begins passing again and accumulates enough consecutive successes to meet its successThreshold, the container's ready field returns to true, and the Pod is automatically added back to the relevant Service endpoints without requiring any manual intervention or restart.

Common Use Cases

Rolling Update Safety

Readiness probes play a central role during rolling updates, since a Deployment considers a new Pod's replica count toward the update's progress only once that Pod reports as ready, preventing traffic from being routed to instances of the new version before they have confirmed their own operational readiness.

Dependency-Aware Traffic Control

A common pattern is configuring a readiness probe to check connectivity to a critical downstream dependency, such as a database connection pool, allowing the Pod to gracefully withdraw from traffic if that dependency becomes unavailable, without treating the outage as a reason to restart the application itself.