0 / 15 lessons — 0%
Lesson 10 / 15 🔍
Troubleshooting & the kubectl toolbox
Kubernetes failure modes have a strong "greatest hits" pattern. Recognize these five and you can debug most real incidents.
| Status you see | Usual cause | First move |
|---|---|---|
Pending | No node has enough free CPU/memory, or a PVC can't bind | kubectl describe pod — check the Events section at the bottom |
ImagePullBackOff | Wrong image name/tag, or missing registry credentials | kubectl describe pod — the exact pull error is in Events |
CrashLoopBackOff | The container starts, then exits, on repeat | kubectl logs <pod> --previous — logs from the crashed attempt |
| Service has no endpoints | The Service's label selector doesn't match any real Pod's labels | kubectl get endpoints <svc>, then compare selectors to pod labels |
| Works in one namespace, not another | A NetworkPolicy, ResourceQuota, or missing Secret specific to that namespace | kubectl get events -n <ns> --sort-by=.lastTimestamp |
# the toolkit, roughly in the order you'd reach for them kubectl get pods -o wide # which node, which IP, restart count kubectl describe pod <name> # Events at the bottom explain almost everything kubectl logs <name> --previous # logs from before the last crash kubectl exec -it <name> -- sh # climb inside a running container kubectl port-forward pod/<name> 8080:80 # reach it from your laptop, bypassing Services entirely kubectl get events --sort-by=.lastTimestamp # cluster-wide timeline of what just happened
Habit worth building:
kubectl describe before kubectl logs. Describe tells you if the container ever actually started; logs only make sense once you know that it did.Try it yourselfDeliberately typo an image name in a Deployment (
nginx:doesnotexist), apply it, then run kubectl describe pod on the resulting Pod. Find the exact line in Events that tells you the pull failed and why.