A teammate reports that their application running on Kubernetes is broken. Walk through the kubectl commands you run, in what order, and what each one rules in or out.

## Why order matters Under time pressure the value of a triage sequence is that each step **eliminates a class of causes**, so you never wander. The spine is: confirm where you are, read the object's summary state, read what the cluster did to it, read what the application said, then read the exact object, then widen to the neighbourhood. ## Step 0 — context and namespace `kubectl config current-context` and `kubectl config view --minify` answer "which cluster", and `-n <ns>` or `kubectl config set-context --current --namespace=<ns>` answer "which namespace". Most "the pod doesn't exist" confusion is a wrong namespace or a wrong cluster, and acting in the wrong cluster is the one triage mistake that causes a second outage. Keep kubectl within one minor version of the API server; skew produces odd missing-field behaviour. ## Step 1 — kubectl get pods -o wide Six columns answer most of the question: - **STATUS** — `Pending` (not scheduled or image not yet pulled), `ContainerCreating`, `Running`, `Completed`, `Error`, `Terminating`, or a backoff reason. - **READY** — `0/1` while `Running` means the readiness probe is failing, so the pod exists but takes no Service traffic; `1/2` in a sidecar pod points at which container is unhealthy. - **RESTARTS** — with the "(x ago)" suffix in modern kubectl, tells you both how often and how recently. - **AGE** — distinguishes "never worked since the deploy 3 minutes ago" from "worked for 12 days and just broke". - **NODE** (from `-o wide`) — if every unhealthy pod is on one node, the problem is that node, not the app. Add `-w` to watch transitions live, `-A` to search across namespaces. ## Step 2 — kubectl describe pod `describe` renders the object plus the Events referring to it. Read bottom-up: Events tell you what the scheduler, kubelet and image puller actually did and when. Above them, check `State` and `Last State` for the current and previous container run (with exit code and reason), the `Conditions` block (`PodScheduled`, `Initialized`, `ContainersReady`, `Ready`), the resolved image and image ID, the probe definitions, and the requests and limits. `describe` also shows `Controlled By`, which is how you find the owning ReplicaSet, Job or StatefulSet. ## Step 3 — kubectl logs What the application itself said. `-c` for a specific container, `--previous` for the instance that died, `--since=15m` and `--tail=200` to bound the volume, `--timestamps` to correlate with the Events you just read. Absence of logs is information too — a pod that never started produces none. ## Step 4 — kubectl get -o yaml When describe's summary is ambiguous, read the API object: `status.containerStatuses[].lastState.terminated` (exitCode, reason, finishedAt), `status.conditions`, the fully resolved `spec` including injected sidecars, env from ConfigMaps and Secrets, volumes, and `metadata.ownerReferences`. This is also the copy you attach to an incident ticket, since it is exact rather than formatted. ## Step 5 — widen If the pod looks healthy, the problem is around it. `kubectl get events --sort-by=.lastTimestamp -n <ns>` for cluster-level activity such as evictions or scaling; `kubectl get deploy,rs` to see whether a rollout is stuck or an old ReplicaSet is still serving; `kubectl get svc,endpointslices` to see whether the pod is actually a backend; `kubectl get nodes` for node conditions; `kubectl top pod` and `kubectl top node` for live resource usage. ## Habits that make triage repeatable Capture before you mutate: `kubectl get pod -o yaml`, `describe`, and `logs --previous` into files or the incident channel *before* deleting or restarting anything, because deleting a pod deletes its logs and its status. Prefer read-only commands until the cause is understood. State findings as eliminations — "the pod is Running and Ready, so this is not a scheduling problem" — because narrowing is the whole point of the sequence.