CrashLoopBackOff isn't an error in itself — it's Kubernetes telling you a container keeps starting, crashing, and getting restarted, so it's backing off between attempts. The status is a symptom; the real error is in the logs of the container that just died.
1. Describe the pod
kubectl describe pod <pod> shows the Events and the last state, including the exit code. Two codes are worth memorising: 137 = killed (OOM — bump memory limits), and 1/2 = the app threw on startup (go read its logs).
2. Read the crashed container's logs
kubectl logs <pod> # current attempt kubectl logs <pod> --previous # the instance that just crashed <-- the gold
--previous is the key flag: the current container may be too young to have logged anything, but the one that crashed left the stack trace behind.
3. Match the cause
- App error on boot — missing env var, bad config, can't reach a dependency. Fix the config/Secret/ConfigMap.
- OOMKilled (137) — raise the container's memory
limits, or fix the leak. - Failing liveness probe — the app is fine but the probe is too aggressive or points at the wrong path; tune
initialDelaySeconds/path. - Bad command/image — wrong entrypoint or an image that isn't what you think; verify the tag.
4. Apply and watch
Fix the manifest, kubectl apply -f deployment.yaml, then kubectl get pods -w to watch it roll. A healthy pod moves to Running and stays there with restart count stable.
Practise container incidents
Crashlooping pods and crashed containers are incidents in the simulator. Work them in a full incident response shift, or automate recovery with Ansible.