Debugging a Pod in CrashLoopBackOff

What's really being asked

CrashLoopBackOff means a container starts, exits, and Kubernetes keeps restarting it with increasing back-off delays. The interviewer checks whether you gather evidence before acting.

The full answer

First, kubectl describe pod POD_NAME. This surfaces the Events section, the container's restart count, its Last State (often Terminated with an exit code and Reason), and any image-pull or scheduling problems. Second, kubectl logs POD_NAME, and importantly kubectl logs POD_NAME --previous. Because the current container instance may have already died, --previous retrieves stdout and stderr from the prior crashed instance, which usually contains the actual stack trace or error message.

The mistakes people make

Deleting the Pod to force a fresh start, which throws away the failing container's history. Restarting the whole Deployment blindly. Only checking kubectl get pods, which shows the status but not the cause.

What usually comes next

What exit code suggests an out-of-memory kill? 137, meaning the container was SIGKILLed, often by the OOM killer when it exceeded its memory limit. How would you debug if logs are empty? Exec into a sidecar or use an ephemeral debug container. How does back-off timing work? Delays grow exponentially up to a cap.

A concrete example

A service crashes on boot. kubectl describe pod shows Reason: Error and exit code 1, plus an event noting the restart count climbing. kubectl logs --previous reveals a fatal error reading a missing environment variable. The fix is adding the variable via a ConfigMap, not restarting the Pod.