What’s your Kubernetes troubleshooting workflow: start with the pod or the cluster?

I usually go symptom-first: check whether the pod exists and is running, then inspect recent events, describe the pod, review current and previous container logs, and check probes, configuration, and exit codes. If the pod looks healthy, I move outward to the Service, endpoints, ingress, and network path. The key is to confirm the pod is actually alive before assuming the problem is in the application.

A quick first pass that works well for me is events sorted by time, followed by describe, then logs. Events often immediately reveal scheduling failures, image-pull errors, failed mounts, or node pressure. I also check node resource usage early, because several apparently unrelated pod failures may really be a capacity problem. Pod-first is efficient for isolated failures, but the scope should determine when you zoom out to the node or cluster.

Start by determining the blast radius. Ask whether it’s one pod, one workload, several namespaces, one node, or multiple nodes, and check whether anything changed recently. A single CrashLooping pod calls for pod events, previous logs, exit codes, probes, configuration, mounts, and dependencies. If unrelated workloads are failing on the same node, investigate node health and capacity. If many nodes or services are affected, look at cluster-wide dependencies such as DNS, the CNI, storage, the API server, admission webhooks, or cloud-provider components. The best workflow is hypothesis-driven: collect evidence, eliminate possibilities, and narrow the scope rather than following a fixed command checklist.