Read CrashLoopBackOff, ImagePull and Pending Like a Log

Why this matters

These three statuses cover most pod failures you will ever meet, and the exam distributes them generously because they test reading rather than recall. Each has exactly one evidence command and a short fix list; hesitation comes from treating them as one blurry problem instead of three sharp ones.

Concepts

CrashLoopBackOff means the container starts then dies, with backoff delays growing between tries. Evidence: kubectl logs <pod> --previous names the dying reason (exception, missing env, bad config, OOMKilled exit 137 in events). Fixes live in the app or its config: repair the cause, not the restart count. Never confuse the backoff delay with the disease.

ImagePullBackOff means the image never arrived. Causes in order: wrong name or tag, private registry without imagePullSecrets, registry unreachable, node disk pressure blocking pulls. Evidence: the event names it (401, not found, timeout). Fix the named cause; the kubelet retries alone once unblocked.

Pending means unscheduled or gated. Causes: no node fits (resources, affinity, taints), PVC unbound, init container stuck, image pull in progress. Evidence: kubectl describe pod events name the predicate (Insufficient cpu, unbound volumes, ErrImagePull). Fix per the predicate: scale resources, fix selectors, bind storage, repair the image.

Worked example

Three sick pods, three one-minute diagnoses:

# CrashLoop: previous log is the autopsy
kubectl logs api-xxx --previous | tail -20
# KeyError: PAY_API_V2 -> missing env, fix the deployment
# ImagePull: event is the diagnosis
kubectl describe pod worker-yyy | grep -A3 Events
# Failed to pull image "reg:5000/w:v9": unauthorized -> imagePullSecrets
# Pending: predicate is the diagnosis
kubectl describe pod cache-zzz | grep -A3 Events
# 0/3 nodes available: 3 Insufficient memory -> smaller request or bigger node

Each drill ends at its evidence command. The fix matches the evidence, never the status alone.

Exam notes

Exit 137 is OOMKilled until proven otherwise: check memory before code. ImagePullSecrets attach to service accounts or pod specs, and typos in secret names fail exactly like wrong passwords. And Pending with no events after minutes means the scheduler never saw it: check the pod actually exists in the right namespace first.