Troubleshooting
The largest domain on the CKA, troubleshooting tests your ability to diagnose failing Pods, nodes, control-plane components, and networking. This chapter organizes the standard investigative commands and the signals to look for in common failure states.
Diagnosing Pod problems
Start with kubectl get pods to see status, then kubectl describe pod to read the Events, which explain scheduling failures for Pending Pods (insufficient resources, unsatisfied selectors, untolerated taints). For a running or recently crashed container, kubectl logs shows output, and kubectl logs --previous shows the last terminated instance, which is essential for diagnosing CrashLoopBackOff.
Node and control-plane failures
A NotReady node usually means its kubelet is down or cannot reach the API server, so check systemctl status kubelet and its logs on the node. On kubeadm clusters the API server, scheduler, and controller manager run as static Pods, so connection-refused errors to the API server call for checking the kubelet and the component container logs via crictl rather than disruptive actions.
Safe maintenance with drain and cordon
To take a node out of service, kubectl cordon marks it unschedulable, and kubectl drain additionally evicts its Pods while honoring PodDisruptionBudgets, using --ignore-daemonsets for DaemonSet Pods. After maintenance, kubectl uncordon returns the node to service. These commands let you perform maintenance without abrupt disruption.