What are the phases of a Pod's lifecycle?
Quick Answer
A Pod's status.phase is one of: Pending (accepted by the cluster, but one or more containers not yet running — commonly waiting to be scheduled or waiting on an image pull), Running (bound to a node, at least one container running), Succeeded (all containers terminated successfully, won't restart — the normal end state for a Job's Pod), Failed (all containers terminated, at least one with failure and won't restart), or Unknown (the Pod's state can't be determined, typically because the node it's on is unreachable). This top-level phase is a coarse summary. The real diagnostic detail lives in each container's individual status and the Pod's conditions.
Detailed Answer
The five phases
| Phase | Meaning |
|---|---|
| Pending | Pod accepted by the API server, but not all containers are running yet — could be waiting to be scheduled onto a node, waiting on an image pull, or waiting on a volume to attach |
| Running | The Pod has been bound to a node, and at least one container is running (others might be starting, restarting, or have already completed, for multi-container Pods) |
| Succeeded | All containers terminated successfully (exit code 0), and won't be restarted — the expected end state for a Job's Pod, not something you'd normally see for a Deployment's Pod |
| Failed | All containers have terminated, and at least one terminated with a non-zero exit code or was terminated by the system, and won't be restarted |
| Unknown | The Pod's state couldn't be determined, typically because the node hosting it stopped communicating with the control plane |
Why "phase" alone is often not enough to diagnose a problem
A Pod stuck in Pending could mean several very different things: no node has enough free resources to satisfy the Pod's requests, no node matches its affinity/taint requirements, the image is still being pulled, or a required volume hasn't attached yet. The phase alone doesn't distinguish these. You need to look at the Pod's conditions and events for the actual reason:
kubectl describe pod <pod-name>
# Look at the "Conditions" section and "Events" at the bottom --
# these contain the actual human-readable reason, e.g.:
# "0/3 nodes are available: 3 Insufficient memory."
Pod conditions — more granular than phase
Alongside phase, a Pod has several boolean conditions, each with its own status and reason: PodScheduled (has it been assigned to a node), Initialized (have all init containers completed), ContainersReady (are all containers passing their readiness probes), and Ready (is the overall Pod ready to receive traffic — this is what a Service uses to decide whether to route to this Pod). A Pod can be in phase Running while its Ready condition is False — for example, the containers are executing, but a readiness probe is failing, so the Pod isn't yet added as a Service endpoint. This distinction, running but not ready, is one of the most common sources of "why isn't my Pod receiving traffic even though it shows Running" confusion.
Container-level states, within a Running Pod
Each individual container within a Pod also has its own state: Waiting (not yet running, for example still pulling its image, or blocked on a CrashLoopBackOff backoff timer), Running, or Terminated (exited, with a reason and exit code). kubectl describe pod shows each container's individual state separately. This is essential for multi-container Pods, where one container might be healthy while another is crash-looping.
When diagnosing a Pod problem, always look past the top-level phase. kubectl describe pod (conditions + events) and kubectl get pod -o yaml (full status detail, including per-container state) give the actual specific reason, and are the correct starting point for any of the common failure states covered in the observability/troubleshooting topic — CrashLoopBackOff, ImagePullBackOff, OOMKilled.