World K2: Trays & Orders

Pod states and their errors

You will learn: what Pending, CrashLoopBackOff, ImagePullBackOff and OOMKilled mean, and where to look first.

Checked with Kubernetes 1.37 on 31 Oct 2026

The problem

You are here: cluster kind-dev namespace default

~/shop $ kubectl get podsNAME     READY   STATUS             RESTARTS      AGEbig      0/1     Pending            0             45shungry   0/1     CrashLoopBackOff   3 (4s ago)    45soops     0/1     CrashLoopBackOff   3 (12s ago)   45stypo     0/1     ImagePullBackOff   0             45s

Four trays, four kinds of trouble. The words look scary. Each one has a plain meaning, and a first place to look.

Watch

Real error: . Plain words: the app starts, crashes, and Kubernetes waits longer before each retry. Tap through it.

Tap each point on the timeline.

Try it

Why does oops crash? Kubernetes cannot fix your app. Ask the tray: read its logs.

You are here: cluster kind-dev namespace default

dev-control-planeOpenManager

No trays here.

dev-workerOpen

oops·ht8mq↻3CrashLoopBackOff

dev-worker2Open

No trays here.

Time: +0s (sped up)

Hint

kubectl logs deployment/oops shows what the app printed.

Watch

You are here: cluster kind-dev namespace default

~/shop $ kubectl get pod bigNAME   READY   STATUS    RESTARTS   AGEbig    0/1     Pending   0          45s~/shop $ kubectl get events --field-selector reason=FailedScheduling -o jsonpath={.items[0].message}0/3 nodes are available: 1 node(s) had untolerated taint(s), 2 Insufficient cpu. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.

Real error: with Insufficient cpu. Plain words: no stall has room for this tray. It asks for 64 CPUs.

Predict

hungry may use 64Mi of memory. Its app keeps eating more. What happens?

Watch

You are here: cluster kind-dev namespace default

~/shop $ kubectl get pod hungry -o jsonpath={.status.containerStatuses[0].lastState.terminated.reason}OOMKilled~/shop $ kubectl get pod hungry -o jsonpath={.status.containerStatuses[0].lastState.terminated.exitCode}137

Real error: , exit code 137. Plain words: it used more memory than its limit. STATUS shows it for a moment, then CrashLoopBackOff.

Try it

Real error: . Plain words: the stall cannot fetch that image. Here the tag 1.299 is a typo. Ship nginx:1.30-alpine instead.

You are here: cluster kind-dev namespace default

Want3written on the order for shop

See43 ready

Do Remove 1Gaps fixed: 0

dev-control-planeOpenManager

No trays here.

dev-workerOpen

shop·2g4l2
shop·v62jm

dev-worker2Open

shop·fxdpqImagePullBackOff
shop·57nrg

Time: +0s (sped up)

Hint

kubectl set image deployment/shop web=nginx:1.30-alpine replaces the bad tag.

Check

Where do you look first? Sort each error.

Drag a card into a box. Or tap the card, then tap the box.

You did it!

You can now read the four classic pod errors and know where to look.

Go deeper (optional)

kubectl describe pod <name> tells the whole story: Last State, Reason, Exit Code and Events at the end. A crashing app’s last run is in kubectl logs <pod> --previous, if the kubelet still keeps it. World K5 teaches the full debug ladder.

Real rep (optional): on a throwaway cluster, run a pod with a wrong tag. Then read describe.