Troubleshooting
Troubleshooting
This domain tests a layered method: inspect object status, events, logs, and node conditions before changing anything. The exam presents symptoms such as Pending, CrashLoopBackOff, ImagePullBackOff, NotReady, and failing Service calls.
Layered method
Start with kubectl get and kubectl describe; the Events section often names the cause. Use kubectl logs, --previous for restarted containers, and kubectl exec for in-container checks. For nodes, kubectl describe node shows conditions, pressure, and taints. Control-plane issues may require checking static Pod manifests and container runtime logs on the node.
Common signatures
Pending usually means unschedulable: insufficient CPU or memory, nodeSelector or affinity mismatch, untolerated taint, or unbound PVC. ImagePullBackOff means registry auth, image name, or network. CrashLoopBackOff means the process exits; check exit code, config, and probes. NotReady often means CNI or runtime failure. A Service with no endpoints points to selector or readiness.
Worked example
A Pod stays Pending after a deployment. kubectl describe pod shows FailedScheduling: 0/3 nodes are available: 3 Insufficient cpu. The Pod requests 4 CPU; nodes have 2 allocatable. Reduce the request to 2 or add capacity. If the event said node(s) had untolerated taint, add a toleration or remove the taint. The scheduler reports all filter failures; read the event rather than guessing.
Traps
Do not read application logs for scheduling failures; they do not exist yet. Deleting a Pod managed by a controller only recreates it. CrashLoopBackOff is a symptom, not a root cause. kubectl get events is namespace-scoped unless -A is used.