Kubernetes · Orchestration under pressure
How do you debug a pod that will not start?
Short answer
Check pod status, describe events, and read current and previous container logs. Match the symptom to a cause: Pending, ImagePullBackOff, CrashLoopBackOff or readiness failures.
Start with kubectl get pod and describe. The status and events usually identify the layer: scheduling, image pull, container start or probe failure. Then read logs, including previous logs after a restart. For a running but broken pod, exec or an ephemeral debug container lets you test from inside the same network namespace.
- Pending often means insufficient resources, unsatisfied affinity, or an unbound PVC
- ImagePullBackOff means bad image reference, registry auth, or network policy
- CrashLoopBackOff means the process exits; read previous logs and exit codes
- CreateContainerConfigError often means a missing ConfigMap or Secret key
- Readiness failures keep the pod out of endpoints even if it is running
kubectl get pod api-7c9d8f6b5-abcde -n production
kubectl describe pod api-7c9d8f6b5-abcde -n production
kubectl logs api-7c9d8f6b5-abcde -n production --previous
kubectl debug -it api-7c9d8f6b5-abcde -n production --image=busybox --target=apiDescribe output and events are time-ordered and often more useful than logs for start failures. If events have expired, check the ReplicaSet and Deployment status, node conditions and admission webhooks. For networking issues, test DNS and connectivity from a debug container rather than guessing.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What does CrashLoopBackOff tell you?
- 2How do you debug a pod stuck in Pending?
- 3When would you use kubectl debug instead of exec?
- 4How do you inspect logs from a previous container instance?
Say it in the interview
I start with get and describe because status and events point to the failing layer, then read logs including the previous instance after a restart. Pending is usually scheduling or storage, ImagePullBackOff is registry access, and CrashLoopBackOff is the process exiting. For a running but broken pod I use exec or an ephemeral debug container. I also check readiness and endpoints, since Running does not mean serving.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.