Pod Lifecycle & Common Failure States

In one line

CrashLoopBackOff, ImagePullBackOff, and OOMKilled are specific, recognizable failure states with specific causes — learning to read them by name is the fastest path from 'something's wrong' to 'I know exactly what's wrong.'

0/4 · 0%

Key ideas

01
A pod moves through a defined set of PHASES over its life: Pending (accepted by the API server, not yet fully scheduled/running), Running (scheduled, at least one container started), Succeeded (every container exited successfully — normal for a Job, Topic 1.4), Failed (every container exited, at least one unsuccessfully), and within Running, individual containers have their own more granular STATUS reasons — this is where the specific, recognizable failure states actually live.
02
CrashLoopBackOff means a container is starting, crashing, and being restarted repeatedly, with Kubernetes waiting progressively LONGER between each restart attempt (exponential backoff) — the container image and scheduling are fine; the APPLICATION ITSELF is crashing shortly after starting, almost always diagnosable from kubectl logs --previous (Phase 0.4), which shows exactly what it printed right before dying.
03
ImagePullBackOff (and its precursor, ErrImagePull) means the node couldn't successfully pull the specified container image — most commonly a typo'd image name or tag, a private registry the node isn't authenticated against, or genuinely non-existent image entirely. kubectl describe pod shows the EXACT pull error in its Events section, almost always immediately revealing which of these it actually is.
04
kubectl events -n <namespace> (or the older kubectl get events --sort-by=.lastTimestamp) lists recent events for the whole namespace in time order, which shows scheduling failures, image pulls, probe failures, OOM kills and evictions across every pod at once. Events expire after about an hour, so capture them early in an incident.
05
OOMKilled (Out Of Memory Killed) means the container exceeded its configured memory LIMIT (Phase 4.1) and was forcibly terminated — the fix is either raising the memory limit (if the usage is genuinely legitimate) or finding and fixing a real memory leak/inefficiency in the application itself; kubectl describe pod shows the exit reason directly, and comparing kubectl top pod history against the configured limit confirms whether this is a one-time spike or a persistent, growing problem.
06
Pending (a pod stuck, never reaching Running at all) most commonly means the SCHEDULER can't find any node with enough available resources to satisfy the pod's requests (Phase 4.1), or a node affinity/taint rule (Phase 4.2) that no available node actually satisfies — kubectl describe pod shows the scheduler's own specific reasoning in its Events, exactly naming which constraint couldn't be satisfied.
07
The single most valuable habit for troubleshooting ANY pod problem: kubectl describe pod <name>, read top to bottom, ending with its EVENTS section — this one command surfaces the overwhelming majority of the information needed to diagnose exactly which of these named failure states you're actually looking at, before reaching for logs or exec at all.

Code & diagrams

FailureStateDecisiondiagram

The name of the failure state tells you almost exactly where to look first.

Rendering diagram…

diagnose-failures.shmarkdown

The one command that resolves the overwhelming majority of pod problems, applied to each named state.

# Always start here, regardless of which failure state you're seeing
kubectl describe pod <pod-name>
# read the Events section at the very bottom first

# CrashLoopBackOff — what did it print right before dying?
kubectl logs --previous <pod-name>

# ImagePullBackOff — the exact reason is in describe's Events, e.g.:
# "Failed to pull image ... manifest unknown" (typo'd tag)
# "unauthorized" (private registry, missing imagePullSecret)

# OOMKilled — confirm via describe, then check real usage trend
kubectl describe pod <pod-name> | grep -A3 "Last State"
# State: Terminated, Reason: OOMKilled
kubectl top pod <pod-name>   # compare against the configured memory limit

# Pending — the scheduler's own exact reasoning
kubectl describe pod <pod-name> | grep -A5 Events
# "0/3 nodes are available: 3 Insufficient memory"
# or: "didn't match Pod's node affinity/selector"

Explain it without notes

A pod shows CrashLoopBackOff. What does this tell you the problem is NOT, and what's the single most useful command to find out what it actually IS?

Why does kubectl describe pod's Events section, rather than kubectl logs, tend to be the better first place to look for an ImagePullBackOff or Pending pod specifically?

Practice

Deliberately create a pod with a typo'd image tag and confirm it shows ImagePullBackOff, then use kubectl describe pod to find the exact pull error in its Events.

Deliberately create a pod whose command exits immediately with a non-zero code, confirm it shows CrashLoopBackOff, and use kubectl logs --previous to see what it printed.

Trade-offs

↔
Recognizing these failure states BY NAME is a genuine time-saver during real incidents, but it's still just the first step — knowing 'this is OOMKilled' tells you WHERE to look, not automatically WHY the memory usage is actually that high or whether raising the limit is the right fix versus finding and fixing a real leak; the named states narrow the investigation dramatically, but don't replace it entirely.

Done when you can

I can recognize CrashLoopBackOff, ImagePullBackOff, and OOMKilled by name and know what each specifically means.
I know kubectl describe pod's Events section is the right first stop for failures before a container ever starts running.
I know kubectl logs --previous is the right tool for a container that's already crashed and restarted.