Kubernetes Readiness Gate Behavior

Kubernetes Readiness Gate Behavior is the mechanism by which conditions defined outside the kubelet's own probe system are folded into a Pod's overall Ready condition, letting external controllers withhold traffic eligibility for reasons the kubelet has no direct visibility into. Configured through spec.readinessGates, this behavior extends the readiness model beyond container-level probes without requiring any change to the kubelet's core logic.

The Standard Readiness Model Without Gates

Container Probes Alone

Absent any readiness gates, a Pod's Ready condition is determined entirely by ContainersReady, itself derived purely from each container's own readiness probe results. This is sufficient when every relevant health signal originates from inside the Pod's containers.

status:
  conditions:
    - type: ContainersReady
      status: "True"
    - type: Ready
      status: "True"

Declaring a Readiness Gate

spec.readinessGates

A Pod declares one or more readiness gates, each naming a conditionType that an external controller is expected to populate in status.conditions. The gate itself does not create the condition; it only tells Kubernetes that this condition type must be checked when computing overall readiness.

apiVersion: v1
kind: Pod
metadata:
  name: readiness-gate-example
spec:
  readinessGates:
    - conditionType: "target-health.example.com/registered"
  containers:
    - name: app
      image: registry.example.com/app:1.0.0
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080

How the Combined Ready Condition Is Computed

Logical AND Across All Sources

The Pod's Ready condition becomes True only when ContainersReady is True and every condition type named in readinessGates is also present in status.conditions with status: "True". If a named gate condition is missing entirely, or present with any status other than True, the overall Ready condition is False.

status:
  conditions:
    - type: ContainersReady
      status: "True"
    - type: "target-health.example.com/registered"
      status: "False"
      reason: NotYetRegistered
    - type: Ready
      status: "False"

Who Populates Gate Conditions

External Controllers, Not the Kubelet

The kubelet never sets the status of a custom readiness gate condition; that responsibility belongs to whatever external controller owns the semantics of that condition type, commonly a cloud load balancer controller confirming target registration, or a service mesh controller confirming sidecar proxy configuration has propagated.

kubectl get pod readiness-gate-example -o jsonpath='{.status.conditions}'

Common Use Case: Load Balancer Target Registration

Avoiding a Startup Traffic Gap

A frequent application is preventing a newly started Pod from receiving traffic through a Deployment rollout before an external load balancer has finished registering it as a healthy target, closing a window where the Pod would otherwise appear Ready to Kubernetes internally while still invisible to the actual traffic source.

readinessGates:
  - conditionType: "elbv2.k8s.aws/pod-readiness-gate-abc123"

Readiness Gate Diagram

Readiness gates make it possible to model any external system's opinion of a Pod's fitness for traffic as a first-class part of Kubernetes' own readiness computation, without modifying container-level probe configuration at all.