Explain the Kubernetes Pod Lifecycle Phases

intermediate|podsdevopssreCKACKAD

TL;DR

A Pod progresses through five phases: Pending (waiting to be scheduled), Running (at least one container is running), Succeeded (all containers exited with code 0), Failed (at least one container exited with a non-zero code), and Unknown (Pod status cannot be determined).

Detailed Answer

Every Pod in Kubernetes has a status.phase field that reflects its current lifecycle phase. Understanding these phases is essential for debugging and monitoring.

The Five Pod Phases

| Phase | Meaning | |-------|---------| | Pending | Pod accepted by the cluster but one or more containers aren't running yet. Includes scheduling time and image pulls. | | Running | Pod bound to a node and at least one container is running or starting/restarting. | | Succeeded | All containers terminated successfully (exit code 0) and won't be restarted. | | Failed | All containers terminated, and at least one exited with a non-zero code. | | Unknown | Pod state can't be determined — usually a node communication issue. |

Debugging by Phase

# Check Pod phase
kubectl get pod my-pod -o jsonpath='{.status.phase}'

# Get detailed conditions and container statuses
kubectl describe pod my-pod

# Check events for scheduling issues (Pending Pods)
kubectl get events --field-selector involvedObject.name=my-pod

Container States vs Pod Phases

Don't confuse Pod phases with container states. A Pod in Running phase can have containers in Waiting (e.g., CrashLoopBackOff), Running, or Terminated states. Always check container-level status when debugging.

Why Interviewers Ask This

This question tests whether you understand how Kubernetes manages workload state. Knowing the lifecycle phases is critical for debugging stuck or failed Pods.

Common Follow-Up Questions

What causes a Pod to stay in Pending state?

Common causes: insufficient cluster resources, unresolvable PVC, image pull errors, or node selector/affinity mismatches.

How do probes interact with the lifecycle?

Startup probes delay liveness/readiness checks. Liveness probe failures trigger container restarts. Readiness probe failures remove the Pod from Service endpoints.

What's the difference between Failed and CrashLoopBackOff?

Failed is a terminal Pod phase. CrashLoopBackOff is a container state within a Running Pod where the kubelet is repeatedly restarting a crashing container with backoff delays.

Key Takeaways

The five phases are Pending, Running, Succeeded, Failed, and Unknown.
A Pod in Running phase doesn't mean the app is healthy — check readiness probes.
Pending usually means a scheduling or resource issue.
CrashLoopBackOff is not a phase — it's a container restart state within the Running phase.