9.11 Kubernetes Pod Condition Lifecycle

Kubernetes Pod Condition Lifecycle is the pattern by which each standard condition attached to a Pod, such as PodScheduled, Initialized, ContainersReady, and Ready, transitions between True, False, and Unknown status values as the Pod progresses through scheduling, initialization, and steady-state operation. Unlike the single coarse phase field, conditions provide a more granular, independently tracked timeline for each specific aspect of Pod health, each with its own transition history.

PodScheduled Condition

Transition to True

The PodScheduled condition begins as False or absent while the Pod awaits placement, and transitions to True the moment the scheduler successfully binds the Pod to a node. This is the earliest condition to resolve in the overall sequence, since no other lifecycle progress can occur until a node assignment exists.

Persistent False State

If a Pod cannot be scheduled due to insufficient resources or unsatisfiable constraints, the PodScheduled condition remains False indefinitely, accompanied by a reason such as Unschedulable and a message describing the specific constraint that could not be satisfied, giving operators a direct starting point for diagnosis.

Initialized Condition

Dependency on Init Container Completion

The Initialized condition transitions to True only after every init container declared in the Pod specification has executed to completion successfully. If the Pod defines no init containers at all, this condition is set to True immediately following scheduling, since there is no initialization work to wait for.

Blocking Effect on Later Conditions

While Initialized remains False, no application containers have started, which means both ContainersReady and Ready also necessarily remain False, illustrating how these conditions form a dependent chain rather than being evaluated in complete isolation from one another.

ContainersReady Condition

Aggregation Across All Containers

The ContainersReady condition transitions to True only once every application container in the Pod reports a ready status of true, whether because it has no readiness probe configured and is therefore considered ready by default, or because its configured readiness probe is currently passing.

Reversion to False

Unlike some conditions that only move forward, ContainersReady can revert from True back to False during the Pod's running lifetime if any container's readiness probe subsequently begins failing, reflecting that readiness is a continuously re-evaluated signal rather than a one-time milestone.

Ready Condition

Final Aggregate Signal

The Ready condition represents the topmost aggregate signal in this chain, becoming True only when ContainersReady is True and any additional readiness gates, such as those configured through readinessGates referencing external conditions, are also satisfied.

Role in Service Endpoint Inclusion

Because Service endpoint controllers consult the Ready condition when deciding which Pods to include as active endpoints, transitions of this condition between True and False directly and immediately affect whether the Pod receives live traffic, making it the most operationally significant condition in the entire lifecycle.

Condition Structure and Transition Metadata

Timestamps and Explanatory Fields

Every condition entry includes lastProbeTime, marking when the condition was last actively checked, and lastTransitionTime, marking when its status value last actually changed, along with reason and message fields that provide machine-readable and human-readable explanations respectively for the current status.

Distinguishing Stable From Flapping Conditions

By comparing lastTransitionTime across observations, an operator can distinguish a condition that has been stably True for a long period from one that is flapping between True and False repeatedly, a distinction that is often the key signal separating a genuinely healthy Pod from one experiencing intermittent problems masked by an instantaneous snapshot of its status.

DisruptionTarget as a Non-Sequential Condition

Independent Signal for Eviction Tracking

Unlike the sequential chain of scheduling and readiness conditions, the DisruptionTarget condition operates independently, appearing when a Pod has been selected for voluntary eviction, and serves a distinct purpose of allowing controllers to differentiate disruption-related terminations from ordinary application failures when calculating retry or failure budgets.