9.6 Kubernetes Pod Phase Progression

Kubernetes Pod Phase Progression is the observable sequence of transitions a Pod's phase field passes through over its lifetime, moving from an initial unplaced state toward either a long-running executing state or one of the terminal states that signal the Pod will never run again. Understanding this progression is central to interpreting Pod status output and diagnosing where in its lifecycle a Pod has stalled or failed.

Pending Phase

Entry Conditions

A Pod enters the Pending phase immediately upon creation and remains there for as long as any of its containers have not yet started running. This includes the entire period during which the Pod awaits scheduling, as well as the subsequent period during which the node is pulling images or executing init containers.

Distinguishing Causes of Prolonged Pending State

A Pod can remain Pending for fundamentally different reasons depending on where in the progression it is stuck, ranging from an inability to find a suitable node during scheduling, to a slow or failing image pull, to a stalled or failing init container, each of which is diagnosed differently despite producing the same outward phase value.

Running Phase

Transition Trigger

A Pod transitions into the Running phase once it has been bound to a node and at least one of its containers is either currently running or in the process of starting or restarting. Notably, this transition does not require every container to be running, only that the Pod has progressed past the point of having no active containers at all.

Running Phase Does Not Imply Readiness

Remaining in the Running phase says nothing about whether the Pod is passing its readiness probes or otherwise capable of serving traffic; a Pod can persist in the Running phase indefinitely while its readiness condition remains false, which is why phase and condition fields must be read together rather than in isolation.

Succeeded Phase

Applicability to Run-to-Completion Workloads

The Succeeded phase applies when all containers in the Pod have terminated and none exited with a failure, a phase primarily relevant to Pods managed by Jobs or CronJobs rather than long-running Deployments, since such workloads are expected to run to completion rather than persist indefinitely.

Terminal and Immutable Nature

Once a Pod reaches Succeeded, it does not transition to any other phase; its containers will not be restarted regardless of the Pod's restartPolicy, since a successful completion is treated as the intended end state for a run-to-completion workload.

Failed Phase

Entry Conditions

A Pod enters the Failed phase when all of its containers have terminated and at least one terminated with a non-zero exit code or was otherwise stopped by the system in a way considered a failure, combined with a restartPolicy of Never or exhausted retry attempts under OnFailure.

Relationship to Controller-Level Recovery

A Pod reaching Failed does not itself recover; recovery, if desired, is the responsibility of the owning controller, such as a Job creating a new Pod to retry the work, or a ReplicaSet creating a replacement to maintain its desired replica count, since the Failed Pod object itself remains in that terminal phase.

Unknown Phase

Loss of Communication

The Unknown phase is reported when the state of the Pod cannot be determined, most commonly because communication with the node hosting the Pod has been lost, such as during a network partition or node failure, leaving the control plane unable to confirm whether the Pod's containers are still running.

Resolution Path

An Unknown phase is typically resolved once node health monitoring components confirm the node is unreachable and the node is marked as not ready, at which point the cluster may proceed to evict and replace the affected Pods rather than leaving them indefinitely in this ambiguous state.

Phase Progression as a Diagnostic Tool

Reading Progression Alongside Conditions and Events

Because phase alone collapses many distinct underlying situations into a small set of values, effective diagnosis of a stalled or failed Pod requires cross-referencing the phase with its detailed conditions, container statuses, and associated Kubernetes events, which together reveal the specific point in the progression where the Pod deviated from the expected path toward a healthy, running, ready state.