Kubernetes Pod Phase Definition

Kubernetes Pod Phase Definition is the precise characterization of status.phase, a single, coarse-grained enumerated field reported for every Pod, summarizing its overall position in its lifecycle as one of exactly five defined values. The phase is formally a high-level summary only; it does not attempt to encode every nuance of a Pod's condition, that finer detail belongs to the Pod's conditions and its per-container statuses, and it is not itself a complete state machine that other fields derive from, but rather a derived summary computed from the underlying container states.

The Five Defined Phases

Pending

Pending is the phase a Pod occupies from creation until at least one of its containers has started running. A Pod remains Pending while it awaits scheduling to a node, while its container images are being pulled, or while any init containers are still executing.

Running

Running is the phase entered once the Pod has been bound to a node and at least one of its containers is running, starting, or restarting. Formally, Running does not imply every container is healthy or ready; it implies only that the Pod has progressed past pending and has at least one active container.

Succeeded

Succeeded is the phase entered once every container in the Pod has terminated, and every container terminated with a successful (zero) exit code. This phase is terminal: a Pod in the Succeeded phase will not transition to any other phase.

Failed

Failed is the phase entered once every container in the Pod has terminated, and at least one container terminated with a non-zero exit code, or was terminated by the system for a reason other than a successful exit. This phase is also terminal.

Unknown

Unknown is the phase reported when the state of the Pod cannot be obtained, typically because communication with the node hosting it has failed. It is formally a statement about the control plane's inability to observe the Pod, not a statement about the Pod's actual condition, which may in fact be healthy.

Formal Transition Structure

Non-Reversibility of Terminal Phases

Once a Pod reaches Succeeded or Failed, it does not transition back to Pending or Running; a Pod's phase, once terminal, remains fixed for the life of that Pod object. A workload that must run again after completion or failure requires a new Pod object, created by its owning controller, not a phase transition on the same object.

Typical Progression

For a long-running service Pod, the typical progression is Pending to Running, remaining Running for the Pod's operational lifetime, until deletion causes its containers to terminate. For a batch-style Pod governed by a Job, the typical progression is Pending to Running to Succeeded or Failed, reflecting a workload expected to complete rather than run indefinitely.

Relationship to Container-Level State

Phase Is Derived, Not Primary

A Pod's phase is computed by the kubelet from the states of its individual containers, each independently Waiting, Running, or Terminated; the phase is a summary of this finer-grained data, not an independent source of truth that the container states are checked against.

kubectl get pod codartium-worker-abc123 -o jsonpath='{.status.phase}'
kubectl get pod codartium-worker-abc123 -o jsonpath='{.status.containerStatuses[*].state}'

Phase Does Not Imply Readiness

A Running Pod is not necessarily receiving traffic; readiness, tracked separately through the Pod's Ready condition and its containers' readiness probes, is what determines whether a Pod is included in a Service's set of endpoints, independent of its phase.

kubectl get pod codartium-worker-abc123 -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

Why Phase Is Kept Minimal

The Pod phase is formally restricted to five coarse values precisely so it can serve as a stable, simple summary usable by tooling and humans alike without requiring interpretation of the full status structure; anything requiring finer granularity, why a Pod is not yet ready, which specific container failed, is deliberately pushed into conditions and container statuses instead, keeping the phase itself a reliable, minimal signal of a Pod's broad lifecycle position.