How many Pod phases are there?

Exactly five: Pending, Running, Succeeded, Failed and Unknown. The phase is a high-level summary in pod.status.phase; the more detailed STATUS column in kubectl often shows container reasons like CrashLoopBackOff or ImagePullBackOff, which are container states, not phases.

What is the difference between a phase and a container state?

A phase is the whole-Pod summary (one of five values). A container state is per-container: Waiting, Running or Terminated, each with a reason. A Pod can be in Running phase while a container is Waiting on a restart backoff.

Does a Pod restart change its phase?

Not necessarily. A container that crashes and is restarted by the kubelet keeps the Pod in Running phase if restartPolicy is Always. The phase only moves to Succeeded or Failed when all containers have terminated and will not restart.

When does a Pod enter Unknown phase?

Unknown means the kubelet that owns the Pod cannot be reached, usually due to a node failure or network partition, so its true state cannot be reported. The control plane may later mark such Pods for deletion.

Is CrashLoopBackOff a phase?

No. CrashLoopBackOff is a container Waiting reason shown in kubectl STATUS. The underlying Pod phase is typically Running because the kubelet is actively trying to restart the container.

Kubernetes Pod Phases Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Kubernetes Pod phases at a glance

Every Kubernetes Pod has a single high-level status.phase value summarising where it is in its lifecycle. The kubelet on the node owning the Pod sets it from the aggregate state of all containers. This reference lists the five phase values, when each is assigned, and which container states they imply.

How it works

The phase is derived, not configured. After scheduling, a Pod starts in Pending while images pull and init containers run. Once at least one container is started it moves to Running. Terminal phases depend on the restartPolicy:

Pending  -> Running  -> Succeeded   (all containers exit 0, no restart)
                     -> Failed      (a container exits non-zero, no restart)
         -> Unknown                 (node/kubelet unreachable)

With restartPolicy: Always (the Deployment default) a crashed container is restarted and the Pod stays Running — you will see container reasons like CrashLoopBackOff in kubectl get pod even though the phase is still Running. Only Never and OnFailure policies let a Pod reach Succeeded or Failed.

Tips and notes

The STATUS column in kubectl get pod mixes phases and container reasons — treat CrashLoopBackOff, ImagePullBackOff and Completed as container or derived states, not as the phase field.
A Pod stuck in Pending usually means it cannot be scheduled (no node fits resource requests, taints, or unbound PVCs) — check kubectl describe pod.
Unknown is rare and node-level; the Pod’s real state is unknowable until the kubelet reconnects.
Use kubectl get pod -o jsonpath='{.status.phase}' to read the raw phase.