Stage 7 · Master
CKA — Certified Kubernetes Administrator
Troubleshooting (30%)
Node failures, pod failures, control-plane debugging, logs, and events — the largest CKA domain.
Node Issues
Node issues are common on the CKA exam. A node may become NotReady, run out of resources, or have kubelet problems. Systematic diagnosis starts with kubectl describe node.
# Check node status
kubectl get nodes
kubectl describe node <node-name>
# Check kubelet on the node
ssh <node-name>
systemctl status kubelet
journalctl -u kubelet -f --lines=100
# Check node resources
kubectl top node
kubectl describe node <node-name> | grep -A 5 "Allocated resources"A NotReady node usually has kubelet issues. Check kubelet status, logs, and certificate expiration. The most common causes are kubelet crash, certificate expiry, or disk pressure.
Pod Issues
Pod issues are the most common troubleshooting scenario. A Pod may be in Pending, CrashLoopBackOff, ImagePullBackOff, or other error states. Each state has specific causes and solutions.
| Pod State | Common Causes | Solution |
|---|---|---|
| Pending | No nodes available, resource limits, taints | Check events, resource quotas, taints |
| CrashLoopBackOff | Application crash, bad command, missing config | Check logs, fix configuration |
| ImagePullBackOff | Wrong image name, missing pull secret | Check image, registry access, pull secret |
| ErrImagePull | Registry unreachable, rate limiting | Check network, use different registry |
| OOMKilled | Memory limit too low | Increase memory limits |
# Check pod status and events
kubectl describe pod my-pod
# View logs
kubectl logs my-pod
kubectl logs my-pod --previous # Previous container logs (for crashes)
kubectl logs my-pod -c my-container # Specific container in multi-container pod
# Debug with exec
kubectl exec -it my-pod -- /bin/sh
kubectl exec -it my-pod -c my-container -- /bin/sh
# Check pod events
kubectl get events --field-selector involvedObject.name=my-pod --sort-by=.lastTimestampAlways check events first — they often contain the root cause. The --previous flag shows logs from a crashed container. The -c flag selects a specific container in multi-container Pods.
Control Plane Debugging
Control plane components run as static Pods on the control plane node. If the API server, scheduler, or controller manager is down, check the static Pod manifests and kubelet logs.
# Check control plane pods
kubectl get pods -n kube-system
# Check static pod manifests
ls /etc/kubernetes/manifests/
# Check kubelet status
systemctl status kubelet
journalctl -u kubelet --lines=50
# Check API server health
kubectl get --raw /healthz?verbose
curl -k https://localhost:6443/healthzControl plane components run as static Pods managed by kubelet. If kubelet is down, the control plane components are also down. Start with kubelet, then check individual components.
Service Issues
Service issues typically involve missing endpoints, wrong selectors, or port mismatches. The Service exists but traffic does not reach the Pods.
# Check service and endpoints
kubectl describe svc my-service
kubectl get endpoints my-service
# Check if selector matches pod labels
kubectl get pods -l app=my-app
# Test connectivity from inside the cluster
kubectl run test --image=busybox --rm -it -- wget -qO- http://my-service:80
# Check DNS resolution
kubectl run test --image=busybox --rm -it -- nslookup my-serviceIf Endpoints are empty, the Service selector does not match any Pod labels. If Endpoints exist but traffic fails, check Network Policies and Pod readiness probes.
Logs and Events
Logs and events are your primary debugging tools. Events are cluster-level records of what happened. Logs are application-level output. Use both together to build a complete picture.
# All events sorted by time
kubectl get events --sort-by=.lastTimestamp
# Events for a specific namespace
kubectl get events -n my-namespace
# Events filtered by reason
kubectl get events --field-selector reason=FailedScheduling
# Warning events
kubectl get events --field-selector type=Warning -A
# Container logs
kubectl logs my-pod --tail=100
kubectl logs my-pod -f # Follow logs
kubectl logs my-pod --since=1h # Logs from last hourThe --field-selector flag filters events by reason, type, or involved object. The --tail flag limits output. The --since flag filters by time range.
Networking Debugging
Networking issues can be DNS failures, NetworkPolicy blocks, or CNI plugin problems. Systematic testing from inside a Pod helps isolate the issue.
# Test DNS
kubectl run test --image=busybox --rm -it -- nslookup kubernetes.default
# Test connectivity
kubectl run test --image=busybox --rm -it -- wget -qO- --timeout=5 http://my-service:80
# Check network policies
kubectl get networkpolicies -n my-namespace
# Check CNI plugin status
kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get pods -n kube-system -l k8s-app=cilium
# Check ingress
kubectl get ingress -A
kubectl describe ingress my-ingressWhen debugging networking, start with DNS. If DNS works, check connectivity. If connectivity fails, check Network Policies and CNI configuration.
Troubleshooting is 30% of the CKA exam. Practice kubectl describe, kubectl logs, kubectl get events, and kubectl exec until they are second nature. The exam will present broken Pods, services, and nodes that you need to diagnose and fix.
Key Commands
kubectl describe <resource> <name> # Detailed resource info
kubectl logs <pod> --previous # Previous container logs
kubectl exec -it <pod> -- /bin/sh # Interactive shell
kubectl get events --sort-by=.lastTimestamp # Recent events
kubectl get events --field-selector reason=FailedScheduling
kubectl top pods # Resource usage
kubectl get pods --field-selector=status.phase=RunningThese commands are your toolkit for every troubleshooting scenario. Memorize them and practice them until they are automatic.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.