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 / 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 — e.g., 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 — e.g., 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, which 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).