What they're testing
Whether you have a procedure, and know about --previous for reading a dead container's logs.
The short answer~30 seconds
The order I use: kubectl describe pod for Last State and Exit Code — 137 means OOM-killed, 143 means SIGTERM, 1 means the app exited itself. Then kubectl logs --previous to read the PREVIOUS run's output, because the current container may not have printed anything yet. Then separate the causes: configuration (a missing env var or secret), dependency (can't reach the database), OOM, or a liveness probe so aggressive it kills the container while it's still starting.
The long answer
The fourth cause deserves its own note because it's self-inflicted and routinely misdiagnosed: the app needs 40 seconds to start, the liveness probe has initialDelaySeconds: 10 and failureThreshold: 3, so it's killed before it's ever ready — forever. There are no errors in the logs and everyone goes hunting for a bug in the code. This is exactly why startupProbe exists: it defers liveness and readiness until the app reports it has started, so you don't choose between fast detection and slow startup.
For exit code 137, don't stop at "raise the memory limit". The next question is where the memory went. For a JVM in a container the classic culprit is a heap configured larger than the container limit — modern JVMs read the cgroup limit, but a hard-coded -Xmx ignores it and the kernel kills the process. Node has the same story with --max-old-space-size.
One operational detail worth knowing: BackOff means Kubernetes is increasing the delay between restarts, up to five minutes. So if you fix the configuration and the pod doesn't recover immediately, it may simply be waiting out the backoff — delete the pod to restart it now rather than doubting your fix.
kubectl describe pod $POD | sed -n '/Last State/,/Ready/p'
kubectl logs $POD --previous # log của lần chạy đã chết
kubectl get events --sort-by=.lastTimestamp | tail -20
kubectl debug $POD -it --image=busybox --target=app # khi image không có shellWhat they'll ask next
?What if the pod stays Pending?
That's a scheduling problem rather than an application one: no node has the resources, a PVC can't bind, or taints and tolerations don't match. kubectl describe states the reason in Events — one of the few cases where Kubernetes tells you plainly.
These lose points
- Running
kubectl logswithout--previousand concluding there are no logs. The current container hasn't lived long enough to print any. - Raising limits until it stops crashing. That masks a leak, and you'll meet it again with a larger bill.