Kubernetes interview question · Most asked
A pod is in CrashLoopBackOff. How do you debug it?
Summary
The container starts and exits repeatedly, and Kubernetes backs off between restarts. Check kubectl describe pod (exit code, last state, events), kubectl logs <pod> --previous (logs from the crashed container), and then the usual causes: application error at startup, missing configuration or secret, wrong command, failing liveness probe, or OOMKilled.
Longer Answer
Exit codes help: 137 is SIGKILL (often OOMKilled, or a liveness failure), 143 is SIGTERM, 1 is an application error, 127 is command not found. If the container exits too quickly to inspect, run it with an overridden command (sleep infinity) or use kubectl debug to start an ephemeral debug container or a copy of the pod. Compare with the last working version: what changed in the image, config or dependencies?
Key Points
- describe + logs --previous.
- Exit codes: 137, 143, 1, 127.
- Config, command, probes, OOM.
- kubectl debug / override command to inspect.
More most-asked Kubernetes questions
- ConfigMaps and Secrets: how do they differ, and how should secrets really be handled?
- How does the scheduler place pods? Explain resource requests, node affinity, taints and tolerations.
- Describe the Kubernetes architecture: what runs on the control plane and what runs on the nodes?
- How do rolling updates work in a Deployment, and how do you roll back?
- Explain the Service types: ClusterIP, NodePort, LoadBalancer, ExternalName and headless.
- What happens, step by step, when you run kubectl apply for a Deployment?
- Deployment, StatefulSet, DaemonSet, Job and CronJob: when do you use each?
- What is the difference between resource requests and limits, and what are the QoS classes?