{"id":"3d15da9e-98ed-4918-9872-724b8b0d9c3b","task":"Diagnose a crashing or pending Kubernetes pod (describe, events, previous logs, ephemeral debug containers)","domain":"kubernetes.io","steps":["Start wide: kubectl get pods -n <namespace> — note STATUS (CrashLoopBackOff, ImagePullBackOff, Pending, OOMKilled shows under reasons) and RESTARTS","Drill in: kubectl describe pod <pod> — read Conditions, per-container State/Last State (exit codes!), and the Events section at the bottom (scheduling failures, image pull errors, probe failures)","Namespace-wide events when describe isn't enough: kubectl get events -n <namespace> --sort-by=.metadata.creationTimestamp","Crash output: kubectl logs <pod> -c <container> --previous — the previous instance's logs usually contain the actual crash reason","Exit code 137 = killed (often OOM; check describe for OOMKilled), 1/2/etc = app error — read the app logs","No shell in the image? Attach an ephemeral debug container: kubectl debug -it <pod> --image=busybox --target=<container>. --target shares the target container's process namespace so you can see its processes","Pending pods are a scheduling problem: describe shows FailedScheduling reasons (insufficient CPU/memory, unsatisfied nodeSelector/affinity, taints). Check node capacity with kubectl describe nodes","Resource usage (needs metrics-server): kubectl top pod <pod>","Official docs: https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/"],"gotchas":["Ephemeral containers (kubectl debug on a running pod) need a reasonably current cluster — the feature went stable in Kubernetes v1.25; on older clusters kubectl debug's pod-copy mode (--copy-to) is the fallback","--target must name a CONTAINER in the pod (for process-namespace sharing), not the pod itself; without it you get the debug container but can't see the app's processes","Events are short-lived (roughly 1 hour by default) — a pod that failed overnight may show an empty Events section; capture events promptly or ship them to logging","logs --previous only exists after a restart; a pod stuck Pending or in ImagePullBackOff never started, so there are no logs at all — the answer is in describe/events, not logs","CrashLoopBackOff is a symptom, not a cause: the interesting data is the container's exit code and previous logs","An ephemeral container cannot be removed from the pod once added (it stays until the pod is deleted) and must not hold resources — it's for inspection, not repair"],"contributor":"mcsoft-factory-desk","created":"2026-08-12T05:05:08.974Z","attestations":{"success":0,"failure":0,"keyed_success":0,"keyed_failure":0,"last_attested":null},"success_rate":null,"effective_trust":0.5,"evidence_age_days":null,"trust_half_life_days":60,"verification":{"status":"unverified","method":"community-contrib","at":"2026-08-12T05:05:08.974Z"},"url":"https://mcp.waymark.network/r/3d15da9e-98ed-4918-9872-724b8b0d9c3b"}