3.2 Pod Lifecycle and Phases

⏱️ ~6 min read

TL;DR: A pod moves through phases: Pending → Running → Succeeded/Failed. Each container inside has its own state too. Understanding both levels is how you debug 80% of pod problems.

Pod Phases

stateDiagram-v2
    [*] --> Pending : Pod accepted by API Server
    Pending --> Running : All containers started
    Running --> Succeeded : All containers exited 0
    Running --> Failed : At least one container exited non-zero
    Pending --> Failed : Image pull error / unschedulable
    Running --> Unknown : Node lost contact with control plane

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

Container States

Inside a running pod, each container has its own state — independent of the pod phase:

# Get container state details
kubectl get pod my-pod -o jsonpath='{.status.containerStatuses[0].state}'

Pod Conditions

Conditions give more granular status than phase. They’re how kubectl determines what to show in kubectl describe:

kubectl get pod my-pod -o jsonpath='{.status.conditions}' | python3 -m json.tool

The Critical Failure Modes

CrashLoopBackOff

The container keeps crashing. K8s restarts it, but adds an exponential back-off delay (10s, 20s, 40s… up to 5 min).

# Cause: check the logs from the PREVIOUS run
kubectl logs my-pod --previous

# Or describe to see restart count and last exit code
kubectl describe pod my-pod | grep -A5 "Last State:"

ImagePullBackOff / ErrImagePull

Kubernetes can’t pull the container image. Causes:

• Wrong image name / tag
• Private registry without credentials
• No internet connectivity on the node

# See the exact error
kubectl describe pod my-pod | grep -A5 "Events:"

OOMKilled

The container exceeded its memory limit and was killed by the kernel.

# Check exit code — OOMKilled shows exitCode: 137
kubectl get pod my-pod -o jsonpath='{.status.containerStatuses[0].lastState.terminated}'

Pending (stuck)

Pod can’t be scheduled. Causes:

• Not enough CPU/memory on any node
• Node selector or affinity rules don’t match any node
• Taint not tolerated

# See why it's stuck
kubectl describe pod my-pod | grep -A10 "Events:"

Restart Policies

restartPolicy controls what happens when a container exits:

spec:
  restartPolicy: OnFailure   # for Jobs
  containers:
  - name: worker
    image: my-batch-job

🔗 Docker Parallel: This is equivalent to restart: unless-stopped (Always), restart: on-failure (OnFailure), and no restart policy (Never) in Docker Compose.

Try It

# Create a pod that immediately crashes
cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: crasher
spec:
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "echo 'Starting...' && exit 1"]
  restartPolicy: Always
EOF

# Watch it crash and enter CrashLoopBackOff
kubectl get pod crasher -w

# See the logs from the crashed run
kubectl logs crasher
kubectl logs crasher --previous   # After it's restarted at least once

# See restart count and exit code
kubectl describe pod crasher | grep -A8 "Containers:"

# Cleanup
kubectl delete pod crasher

Expected progression:

NAME      READY   STATUS              RESTARTS   AGE
crasher   0/1     ContainerCreating   0          2s
crasher   0/1     Error               0          3s
crasher   0/1     CrashLoopBackOff    1          8s
crasher   0/1     Error               2          28s
crasher   0/1     CrashLoopBackOff    3          42s

Key Takeaways

✅ Quick Check

Q1: A pod is in Running phase but 0/1 READY. What does this mean?

Q2: Your pod has RESTARTS: 47 and status CrashLoopBackOff. What’s your first debugging step?

Q3: What’s the difference between a pod in Failed phase vs CrashLoopBackOff status?