KubernetesCXVIII · Kubernetes Troubleshooting MethodologyTroubleshooting methodology
Inspect object → events → logs — the evidence-gathering arc
What you'll learn
- Inspect a Kubernetes object with kubectl get and kubectl describe
- Read the events and identify the Warning vs Normal types
- Read the logs with --previous and --tail for the application-level narrative
- Identify the failure modes that the evidence-gathering arc catches
Prerequisites
Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16
The evidence-gathering arc is the cluster’s way of telling the operator what happened. The arc is: inspect the object, read the events, read the logs. The arc converts a symptom into a candidate cause; the discipline is to follow every step.
Step 3: Inspect the object
The object is the Kubernetes resource that is misbehaving. The
inspection is kubectl get and kubectl describe.
kubectl get pod billing-7d8f-abcde -n prod -o wide
kubectl describe pod billing-7d8f-abcde -n prod
The output is the object’s spec, status, conditions, and events. The output is the input to step 4.
flowchart TD
A[kubectl get] --> B[Spec, status, conditions]
B --> C[kubectl describe] --> D[Events, references]
D --> E[Output]
The kubectl get -o yaml is the canonical first command. The
YAML output is the source of truth; the describe output is
the human-readable summary.
Step 4: Events
The events are the cluster’s history of the object. Events
are time-ordered, scoped to the namespace, and have a type
(Normal, Warning) and a reason. The events are the
narrative of how the object got to its current state.
kubectl get events -n prod --sort-by=.lastTimestamp \
--field-selector involvedObject.name=billing-7d8f-abcde
The output is a list of events:
LAST SEEN TYPE REASON OBJECT MESSAGE
2m Warning FailedScheduling pod/billing-7d8f-abcde 0/12 nodes are available: 3 Insufficient memory, 9 Insufficient cpu.
3m Normal Scheduled pod/billing-7d8f-abcde Successfully assigned billing-7d8f-abcde to node-03
3m Normal Pulling pod/billing-7d8f-abcde Pulling image "billing:1.2.3"
3m Normal Pulled pod/billing-7d8f-abcde Successfully pulled image "billing:1.2.3"
3m Normal Created pod/billing-7d8f-abcde Created container billing
3m Warning CrashLoopBackOff pod/billing-7d8f-abcde Back-off restarting failed container
The events are the cluster’s memory. They are the input to step 5.
Step 5: Logs
The logs are the container’s history. The logs are ordered by line, scoped to the container, and contain the application’s output. The logs are the narrative of how the container got to its current state.
kubectl logs -n prod billing-7d8f-abcde -c billing --previous
kubectl logs -n prod billing-7d8f-abcde -c billing --tail=200
The --previous flag is the key: it shows the logs of the
previous container instance, which is the one that crashed
before the current restart. The --tail=200 flag limits the
output to the last 200 lines.
The logs are the application’s memory. They are the input to step 6.
Why the arc is in this order
The arc is in this order because each step’s output is the next step’s input:
kubectl getshows the object’s current state. The state is the what.kubectl describeshows the events and references. The events are the how (the cluster’s view).kubectl logsshows the application’s output. The logs are the why (the application’s view).
The three views are different lenses on the same object. The operator who reads all three converges on the candidate cause faster than the operator who reads one.
Failure modes of the arc
The most common failure modes:
- Skipping
kubectl describe. The operator reads the logs and begins to interpret the application’s view. The interpretation is incomplete; the events are the cluster’s view of the same object. - Skipping
--previous. The operator reads the current logs of the running container. The current logs are the application starting up; the previous logs are the application crashing. - Reading the wrong container. A Pod can have multiple
containers; the operator reads the wrong container’s logs.
The
-cflag is the remediation.
Production discipline
The evidence-gathering arc is the cluster’s way of telling the operator what happened. The discipline is to run the arc in order, never skip a step, and use the same commands every time. The arc’s output is the input to step 6.
- Use
--previousfor CrashLoopBackOff. The failing container is the previous one. - Use
-cfor multi-container Pods. The wrong container is a common failure mode. - Use
-o yamlfor the canonical view. The describe is the summary; the YAML is the source of truth.
Quiz
Knowledge check · 4 questions
Q1. Which of the following is the correct order of the evidence-gathering arc?
Q2. Reading the current logs of a running container is sufficient for diagnosing a CrashLoopBackOff.
Q3. An operator is running the arc on a Pod in CrashLoopBackOff. The `kubectl describe` shows the events. The logs of the current container show the application starting. What should the operator do?
The Pod is `billing-7d8f-abcde` in namespace `prod`. The workload is a 6-replica Deployment. The Pod has restarted 12 times in 5 minutes. The events show `Back-off restarting failed container billing`. The current logs show the application starting.
Q4. Name three flags that change the kubectl inspection behaviour and explain what each one does.
Passing score: 75%. Answers are checked in this browser.