"Pod's in CrashLoopBackOff, but kubectl logs is empty" — sound familiar?
The logs are empty because you're looking at the freshly restarted container, which hasn't written anything yet. The real cause of the crash is in the logs of the previous, already-dead instance. And you pull them with one flag many people don't know about:
kubectl logs -p -n myapp
In the new article (part 12) I've collected the essential debugging toolkit — and one idea worth remembering forever: almost any problem in Kubernetes unwinds along the chain events → describe → logs.
I cover:
• kubectl logs with -f, --previous, --since, --tail and the multi-container trap;
• kubectl describe pod and reading the Events block from the bottom up;
• why CrashLoopBackOff and ImagePullBackOff are NOT pod phases (the phase stays Pending) but status fields assembled by kubectl;
• port-forward and exec to check the app from the inside (and kubectl debug for distroless with no shell);
• k9s — the whole cluster in one window;
• the three pillars of observability and an honest warning: don't drag a full Prometheus stack into local.
Read it and stop fearing red statuses: https://dorokhovich.com/blog/local-k8s-debugging-and-observability?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-debugging-and-observability
Top comments (0)