Readiness Probe

A readiness probe reports whether a container is ready to serve. Its result contributes to Pod readiness, which Service routing uses together with endpoint state and configuration. Failing readiness does not itself restart the container.

Keeping the three apart is most of the value here, because the common configuration error is putting a check in the wrong one.

Probe	Question	Failing it causes	Runs
Readiness	Can this instance serve?	Affects Pod readiness and endpoint eligibility; no restart	Throughout operation after startup gating
Liveness	Does it need restarting?	Failure threshold triggers termination; restart follows policy	Periodically after startup gating
Startup	Has initialization finished?	Failure threshold triggers termination; restart follows policy	Until startup succeeds

What failing readiness actually does

EndpointSlices record endpoints and their ready, serving and terminating conditions. A readiness failure normally makes a Pod-backed endpoint ineligible for regular Service traffic; the IP need not disappear from the EndpointSlice. With publishNotReadyAddresses: true, ready is published as true regardless of normal readiness.

The container can keep running while it initializes, warms caches or recovers. Routing updates take time, and this mechanism does not close existing connections or block direct Pod access. It is a routing input, not a firewall.

A busy Pod can withdraw and return, but its work may simply move to the remaining replicas. This is not automatically backpressure: producers must actually slow down for that. Evaluate remaining capacity, bounded admission and retry behavior, and thresholds that avoid repeated withdrawal and re-entry under load.

The Service’s label selector identifies candidate Pods. Their overall Ready condition includes container readiness and any readiness gates; endpoint termination and publishing settings also affect routing. A single probe result is not the entire endpoint-selection contract.

What to check in it, and what not to

Check whether initialization and required local resources allow useful service. A capacity check can help only when its thresholds and recovery behavior are designed together with the remaining replicas and upstream load.

Dependencies are the judgment call, and the answer depends on whether your service can do anything useful without them.

• Consider a required dependency when this instance cannot serve useful requests without it. Evaluate the effect of all replicas reporting the same dependency failure.
• Exclude it when the service can degrade — if some endpoints work without the cache, failing readiness on the cache takes the whole instance out of rotation for a partial problem.

A shared dependency check can make every replica withdraw at once. Choose that behavior deliberately, including any degraded service and recovery path, rather than assuming replication makes the check independent. See partial failure.

Why the liveness confusion is expensive

Liveness serves a different purpose: detecting a condition a restart can remedy, such as a deadlock. The Kubernetes guidance warns that using it to restart busy instances can amplify overload across replicas.

Read that as a sequence, because it is an outage pattern rather than a caution.

1. Load rises and responses slow down.
2. The liveness probe times out — because the service is busy, not because it is stuck.
3. The container restarts, losing its in-flight work and its warm state.
4. Its traffic moves to the remaining Pods, which now slow down too.
5. Their probes start failing.

A load-sensitive liveness check can turn slowness into repeated loss of capacity. Configure timeouts and thresholds around recoverability, use readiness for serving eligibility, and observe response performance through an SLO. Liveness does not wait for readiness; startup gating is a separate mechanism.

Slow starts get their own probe

A configured startup probe holds back liveness and readiness until it succeeds. Repeated startup failures reaching the threshold terminate the container, after which its restart policy applies.

Give startup enough time for the workload’s expected initialization, using initial delay, probe period and failure threshold. The default periodSeconds is 10 seconds. This is a configuration budget to validate under real startup conditions, not a guarantee of completion.

Readiness and shutdown are one design

Pod deletion triggers endpoint termination updates without requiring a readiness probe solely for that purpose. Normally ready becomes false while serving can describe drain eligibility. Services publishing not-ready addresses and proxies handling only terminating endpoints need their documented special behavior considered.

Endpoint updates and termination proceed concurrently. An upstream balancer or existing client connection can still send work while the process is stopping. A staged shutdown can reduce the race, but a brief sleep cannot prove every route has converged; see graceful shutdown.

The kubelet executes the probe, but application code and chosen thresholds determine what it means. Test the probe during startup, load and shutdown. Ephemeral by Default connects these checks to the workload’s other declarations.

References

• Kubernetes: Liveness, Readiness, and Startup Probes
• Service
• Kubernetes: EndpointSlices
• Kubernetes: Pod Lifecycle