Troubleshooting

A Systematic Approach to Cluster and Application Failures

Troubleshooting carries the largest single weight on the exam, and the questions reward a repeatable method more than memorized facts. Start broad with cluster and node health, then narrow to the specific Pod, then read what that Pod's containers are actually saying in their logs. Almost every failure state has a small, recognizable signature once you know where to look for it.

Exam tip. Resist the urge to jump straight to logs. Confirm the Pod actually exists and is scheduled first with kubectl get pods and kubectl describe pod, since a Pod that never got scheduled has no container to produce logs from at all.

1. kubectl commands against a specific node's kubelet, such as kubectl logs, begin failing cluster wide with 'x509: certificate has expired or is not yet valid'. This started exactly one year after cluster installation. What is the most likely cause?

• A. The CoreDNS Corefile has an invalid TTL setting
• B. The etcd cluster lost quorum
• C. The kubelet's client certificate, or the control plane's certificates auto-generated with a 1 year default validity by kubeadm, has expiredcorrect
• D. The container runtime's CNI configuration expired

kubeadm generated certificates default to a 1 year validity period, so an x509 expired error exactly one year after install strongly points at expired kubelet or control plane certificates. The fix is kubeadm certs renew all, followed by restarting affected static pods, or kubeadm upgrade, which also renews certs. CNI configuration and CoreDNS TTLs are not certificate based, and etcd quorum loss produces a different class of error, connection refused or timeouts to etcd, not x509 expiry.

2. A container in a Pod has already restarted several times, and the administrator wants to see the log output from the crash that occurred two restarts ago, not the current running instance. What is the correct approach?

• A. Kubernetes only retains logs for the current and immediately previous container instance, so logs from two restarts ago are typically no longer available via kubectl logs --previouscorrect
• B. kubectl logs <pod-name> --previous=2
• C. kubectl logs <pod-name> --restart-count=2
• D. kubectl get events will show the full log output from every past restart

The kubelet only keeps the logs of the currently running container and, separately, the most recently terminated instance, accessible with --previous, it does not retain a full history across multiple restarts, so logs from two restarts ago are generally gone unless an external log aggregation system such as a cluster logging stack was capturing them. --previous does not accept a numeric count, that flag does not exist. kubectl logs also has no --restart-count flag. kubectl get events shows short lifecycle events like restarts and probe failures, not full container log output.

3. A Pod remains in the Pending state, and kubectl describe pod shows the event 0/4 nodes are available: 4 Insufficient cpu. What is the most likely fix?

• A. Reduce the pod's CPU resource request or add nodes with more available CPU capacitycorrect
• B. Delete and recreate the Pod with the same specification
• C. Restart the kube-scheduler pod
• D. Increase the Pod's CPU limit while leaving the request unchanged

The Insufficient cpu event means no node currently has enough allocatable CPU to satisfy the pod's CPU request, so the fix is to lower the requested CPU to something the cluster can accommodate, or to add capacity such as more or larger nodes. Simply deleting and recreating the pod with the same spec would hit the same scheduling constraint and fail again. Restarting kube-scheduler does not create additional cluster capacity. Raising the limit while leaving the request the same does not change what the scheduler evaluates, since scheduling decisions are based on requests, not limits.