Kubernetes Pod Condition Lifecycle

Kubernetes Pod Condition Lifecycle is the progression of the typed, timestamped boolean entries in a Pod's status.conditions array as the Pod advances from creation through readiness and, eventually, termination. Conditions provide a finer-grained view than the single status.phase value, each one tracking a specific aspect of the Pod's health independently and transitioning on its own timeline rather than in lockstep.

The Standard Condition Types

PodScheduled

PodScheduled transitions to True the moment the scheduler successfully binds the Pod to a node. It is the first condition to appear and, once true, never reverts to false for the life of the Pod object, since a Pod is never unscheduled from an already-assigned node.

status:
  conditions:
    - type: PodScheduled
      status: "True"
      lastTransitionTime: "2026-07-18T09:00:00Z"

Initialized

Initialized transitions to True once all init containers have completed successfully. If an init container is still retrying, this condition remains False, and the Pod cannot progress toward Ready regardless of how healthy its application containers might eventually be.

ContainersReady

ContainersReady reflects whether every container in the Pod, application containers specifically, currently reports ready: true in its container status. It can flip between True and False repeatedly over the Pod's lifetime as individual containers pass or fail their readiness probes.

Ready

Ready is the condition that determines whether the Pod is added to matching Service endpoints. It becomes True only once ContainersReady is True and any configured readinessGates also evaluate to True.

status:
  conditions:
    - type: ContainersReady
      status: "False"
      reason: ContainersNotReady
      message: "containers with unready status: [app]"
    - type: Ready
      status: "False"

Transition Metadata

lastTransitionTime, reason, and message

Each condition entry carries lastTransitionTime, updated only when the condition's status value actually changes, not on every reconciliation pass. reason provides a short machine-readable code (ContainersNotReady, PodCompleted) and message provides human-readable detail, both populated primarily when a condition is False or Unknown.

kubectl get pod condition-lifecycle-example -o jsonpath='{.status.conditions[?(@.type=="Ready")].lastTransitionTime}'

Readiness Gates as an Extension Point

External Conditions

readinessGates allow external controllers to inject additional named conditions that must also be True before the Pod's overall Ready condition can become True, extending the standard set beyond what the kubelet manages natively. This is commonly used to gate readiness on external signals such as load balancer target registration.

spec:
  readinessGates:
    - conditionType: "target-health.example.com/registered"
status:
  conditions:
    - type: "target-health.example.com/registered"
      status: "True"

Ordering Guarantees Between Conditions

A Loose Partial Order

While PodScheduled always precedes Initialized, which always precedes ContainersReady, the transition to Ready depends on the logical AND of ContainersReady and any readiness gates, meaning Ready can lag behind ContainersReady indefinitely if an external gate has not yet been satisfied.

Condition Lifecycle Diagram

Tracking conditions rather than phase alone is what allows operators and automation to distinguish precisely where in the lifecycle a stalled Pod is stuck, since each condition's False status and accompanying reason narrows the search to a specific subsystem.