Kubernetes Readiness Probe Behavior

Kubernetes Readiness Probe Behavior is the set of rules governing how the kubelet uses a readinessProbe to determine whether a running container is currently capable of handling requests, and how that determination feeds into Service endpoint membership. Unlike a liveness probe, a readiness probe failure never restarts the container; its sole effect is to control whether the Pod participates in load-balanced traffic.

Purpose: Traffic Eligibility, Not Health Restoration

What Readiness Should Check

A readiness probe should verify that the application is presently able to serve a real request correctly, dependencies reachable, caches warmed, connection pools initialized, rather than merely that the process is alive. This is the appropriate place to check downstream dependency health, in contrast to liveness probes, since a failed readiness check simply removes the Pod from traffic without disturbing the running process.

containers:
  - name: app
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5
      failureThreshold: 2

Effect on the ready Field and Conditions

Container-Level ready Flag

Each failed accumulation of failureThreshold consecutive readiness checks sets that specific container's ready field to false in status.containerStatuses. A success streak of successThreshold consecutive passes flips it back to true.

Pod-Level Condition Propagation

The Pod's ContainersReady condition is True only when every container in the Pod reports ready: true. The Ready condition then depends on ContainersReady together with any configured readinessGates.

status:
  containerStatuses:
    - name: app
      ready: false
  conditions:
    - type: Ready
      status: "False"

Effect on Service Endpoints

Endpoint Removal Without Deletion

When a Pod's Ready condition becomes False, the endpoint controller removes it from the corresponding Service's Endpoints (or EndpointSlice) object, so new connections are no longer routed to it. The Pod itself remains running and unaffected; only its traffic eligibility changes.

kubectl get endpoints app-service -o wide

Automatic Re-Addition

Once the readiness probe passes again for successThreshold consecutive checks, the Pod is automatically re-added to the Service's endpoint list without any manual intervention.

Interaction With Rolling Updates

Gating Rollout Progress

Deployment controllers watch Pod readiness to decide how quickly to proceed with a rolling update. A new Pod that never becomes ready blocks the rollout from advancing past maxUnavailable, preventing an update from replacing healthy old Pods with broken new ones faster than the broken state can be detected.

spec:
  strategy:
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Readiness Versus Liveness Independence

Two Probes, Two Independent Signals

A container can simultaneously report ready: false while still passing its liveness probe, meaning it is alive but temporarily unfit for traffic, for example while reconnecting to a dependency after a network blip. This is the intended, common case, not an error state.

containers:
  - name: app
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080

Readiness Probe Flow Diagram

This traffic-only remediation path makes readiness probing the correct tool for handling temporary, self-resolving unavailability, while restart-triggering liveness probing remains reserved for conditions the application cannot recover from on its own.