Kubernetes Readiness Availability

Kubernetes Readiness Availability is the specific mechanism by which a pod's readiness state controls whether it receives traffic through a Service, distinct from liveness's restart-triggering role, covering the endpoint controller's reaction to readiness transitions, readiness gates for custom external conditions, minReadySeconds stabilization, and the design considerations for a readiness check that accurately reflects a pod's true capacity to serve requests.

Readiness as the Traffic-Eligibility Signal

The Endpoint Controller's Reaction to Readiness

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5

When a pod's readiness probe fails, the endpoint controller removes it from the Endpoints (or EndpointSlice) object backing its Service, immediately stopping new traffic from being routed to it, without restarting the container or removing the pod itself, a categorically different and less disruptive response than the container restart a failing liveness probe triggers.

Readiness During Startup

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
readinessProbe:
  httpGet: { path: /ready, port: 8080 }

Because a new pod does not become an endpoint until its readiness probe first succeeds, readiness is what protects a rolling update from routing traffic to a container that is technically running but not yet fully initialized (warming a cache, establishing database connections), directly preventing the availability degradation a naive "running equals ready" assumption would cause.

Readiness Gates for External Conditions

Extending Readiness Beyond the Probe

spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"

Readiness gates let a pod's overall readiness depend on additional conditions set by an external controller (a service mesh sidecar confirming successful proxy configuration, a load balancer confirming target registration), extending readiness beyond what a container's own probe endpoint can express, since the pod is only marked Ready once every readiness gate condition is True in addition to its container readiness probes passing.

status:
  conditions:
    - type: "www.example.com/feature-1"
      status: "True"

minReadySeconds Stabilization

Guarding Against Readiness Flapping

spec:
  minReadySeconds: 10

minReadySeconds requires a pod to remain continuously ready for the specified duration before it is considered "available" for rolling update progress accounting, preventing a pod that flaps between ready and not-ready (a transient dependency blip during startup) from being counted as a stable, successful replica prematurely, which would otherwise let a rollout proceed based on a misleadingly optimistic readiness signal.

Graceful Traffic Shifting During Rollouts

Readiness as the Rollout Pacing Mechanism

During a Deployment rolling update, the controller uses each new pod's readiness state, not merely its running state, to decide when it is safe to proceed removing old replicas, meaning readiness accuracy directly determines whether a rollout correctly waits for new capacity to actually be traffic-serving before reducing old capacity, or incorrectly proceeds based on a container that is running but still initializing.

strategy:
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

Setting maxUnavailable: 0 combined with an accurate readiness probe guarantees the rollout never reduces available capacity below the pre-rollout level at any point, relying entirely on readiness correctly reflecting true serving capacity for this guarantee to hold in practice.

Designing an Accurate Readiness Check

Shallow vs. Dependency-Aware Checks

# shallow: only confirms the process is listening
readinessProbe:
  tcpSocket:
    port: 8080

# dependency-aware: confirms the process can actually serve a real request
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

A shallow readiness check (confirming a port is open) can report ready while the application is still unable to serve a real request because a required dependency, a database connection pool, a downstream service, is not yet available; a dependency-aware readiness endpoint, implemented by the application itself, checks these dependencies directly and is a meaningfully more accurate reflection of true serving capacity, at the cost of the readiness endpoint itself depending on those external systems remaining reachable.

Avoiding Readiness Checks That Cascade Failure

A readiness check that fails whenever any downstream dependency is degraded, even a non-critical one, can cause every replica to simultaneously become unready during a downstream outage, removing all capacity from the Service entirely rather than degrading gracefully; readiness logic should distinguish dependencies genuinely required to serve any request from those whose absence should degrade functionality rather than remove the pod from service entirely.

Relationship to Reliability and Availability Areas and the Availability Model

Readiness availability is the specific mechanism that operationalizes the client-perspective definition of "available" introduced under the availability model, endpoint membership, not mere pod existence, and it is the traffic-control counterpart to the restart-focused pod recovery mechanisms covered elsewhere: liveness and pod recovery answer "should this container be replaced," while readiness answers "should this pod currently receive traffic," and a complete reliability posture requires both signals to be accurately and independently implemented.