Kubernetes Pod Phase Progression

Kubernetes Pod Phase Progression is the ordered path a Pod's status.phase field travels through over its lifetime, from initial creation to final termination. Unlike the detailed condition array, phase is a single coarse-grained value intended to answer, at a glance, which broad stage of existence a Pod currently occupies, and its progression follows a small set of well-defined transition rules rather than an arbitrary sequence.

The Phase Values

Pending

A Pod enters Pending the instant it is accepted by the API server and remains there through scheduling, image pulling, and container creation, for as long as any container has not yet started running.

kubectl get pod phase-progression-example -o jsonpath='{.status.phase}'

Running

A Pod moves to Running once it has been bound to a node and at least one of its containers is running, or is in the process of starting or restarting. Note that Running does not imply every container is healthy or ready; it only reflects that the Pod has begun executing.

Succeeded

A Pod reaches Succeeded when all of its containers have terminated successfully and none will be restarted, a terminal phase typically associated with Jobs and other run-to-completion workloads.

Failed

A Pod reaches Failed when all containers have terminated and at least one terminated with a non-zero exit code or was otherwise stopped by the system in a way not considered successful.

Unknown

A Pod shows Unknown when the state of the Pod cannot be determined, typically because communication with the node's kubelet has been lost, commonly seen alongside a NodeLost condition.

Legal Transitions

Forward-Only Movement

Phase progression is monotonic for terminal outcomes: once a Pod reaches Succeeded or Failed, it never transitions back to Pending or Running. A Pod that needs to run again is not resurrected in place; a controller creates an entirely new Pod object instead.

status:
  phase: Succeeded
  conditions:
    - type: PodScheduled
      status: "True"

Pending to Running

The transition from Pending to Running requires the Initialized condition to become true, meaning all init containers succeeded, followed by at least one application container entering the Running container state.

Phase Versus Readiness

Why Phase Alone Is Insufficient

Because Running only requires one container to be active, relying on phase to determine whether a Pod is safe to send traffic to is a common mistake. The Ready condition, driven by readiness probes, is the correct signal for traffic eligibility, and it can be false even while phase reports Running.

status:
  phase: Running
  conditions:
    - type: Ready
      status: "False"
      reason: ContainersNotReady

Phase Interaction With restartPolicy

How restartPolicy Affects Terminal Phases

A Pod with restartPolicy: Always never reaches Succeeded or Failed on its own, since any container exit triggers a restart rather than a terminal state; only OnFailure and Never policies allow a Pod to reach a terminal phase, which is why Jobs typically avoid Always.

spec:
  restartPolicy: OnFailure

Phase Progression Diagram

Once a Pod arrives at either terminal branch of this diagram, its phase progression is complete, and any further work, such as retrying a failed task, happens through the creation of a new Pod object rather than a change to the existing one.