JuniorDebuggingCommonNot answered yet
A Pod is failing and prints no useful logs — which kubectl commands do you run, in order?
A Pod is not becoming Ready and kubectl logs prints nothing useful. Before guessing, what is the standard first-look sequence, and what does each command tell you?
$ kubectl get pod api-5f6
NAME READY STATUS RESTARTS AGE
api-5f6 0/1 Running 0 40s
$ kubectl logs api-5f6
(no output)Give the triage order and what you look for at each step.
Run kubectl describe pod first — it shows Events, Conditions, and each container's State/lastState with the exit code. If the process died, kubectl logs --previous reads its stdout; kubectl get events adds context. Guess only after describe.
- ✗Treating a
Runningstatus as proof the container is healthy - ✗Forgetting
logs --previousfor a container that already restarted - ✗Guessing at fixes before reading the
describeEvents
- →What does a container's
lastState.terminatedblock tell you that live logs cannot? - →When would you reach for
kubectl debuginstead oflogsanddescribe?
Contents
Solution
Triage order
$ kubectl describe pod api-5f6 # Events + Conditions + State/lastState (exit code)
$ kubectl logs api-5f6 --previous # stdout of the crashed container instance
$ kubectl get events --sort-by=.lastTimestamp # cluster context, newest lastkubelet did (pull, schedule, probe), and the container State/Last State gives the exit code and reason (Error, OOMKilled, Completed).
--previous reads the output of the prior, dead instance.
describeis the highest-signal step: theEventssection shows what thelogs --previous— if the container already restarted, live logs are empty;get events— the wider picture: evictions, scheduling failures, FailedMount.
For images with no shell, reach for kubectl debug with an ephemeral container (its own question).
Contents
