CKA Troubleshooting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Restart the kubelet with systemctl restart kubelet

  Why it's wrong here

  Restarting the kubelet with `systemctl restart kubelet` is a blind action that should only be taken after diagnosing the root cause. It may temporarily mask the symptom by forcing a fresh registration attempt, but if the underlying issue—such as a CNI misconfiguration, disk pressure, or an invalid kubelet config file—persists, the node will return to NotReady almost immediately. Additionally, restarting the kubelet clears its in-memory state and makes it harder to correlate with logs captured before the restart, losing valuable diagnostic context. Always consult the kubelet logs first.

• ✗

  Check the container runtime status

  Why it's wrong here

  Checking the container runtime status (e.g., `systemctl status containerd` or `crictl ps`) is a reasonable secondary step, but it is not the most direct way to diagnose a NotReady node. A running runtime does not guarantee that the kubelet's communication with the control plane or its internal pod lifecycle operations are healthy; the kubelet is what reports `NodeReady`, and its logs will reflect the specific failure—whether that is an unhealthy CRI, network plugin, or pressure condition. Runtime status alone often shows a healthy system even when the kubelet is unable to report readiness, making it an indirect and potentially misleading check.

• ✓

  Check kubelet logs with journalctl -u kubelet

  Why this is correct

  Checking kubelet logs with `journalctl -u kubelet` is the correct first diagnostic step because it provides the authoritative record of why the kubelet is reporting NotReady. The logs will show concrete errors such as failed CNI plugin execution, repeated API server connection timeouts, disk or memory pressure conditions (`eviction signals`), or Webhook errors, all of which directly explain the node's status. This is the most efficient way to pinpoint the failure rather than guessing, and it also gives you the timestamps to correlate with events from the control plane. Only after analyzing these logs should you decide whether a restart or other intervention is necessary.

• ✗

  Reboot the node

  Why it's wrong here

  Rebooting the node is a last-resort measure that introduces unnecessary downtime and often fails to resolve the root cause. If the NotReady condition stems from persistent issues like a full disk (`DiskPressure`) or a broken kubelet configuration, a reboot will simply bring the node back to the same unhealthy state. Worse, a reboot resets runtime state and clears ephemeral logs, making it harder to investigate the incident after the fact. The correct procedure is to gather diagnostics—such as kubelet logs, runtime status, and system metrics—and only reboot if the problem is clearly a transient kernel or network hang that can't be fixed otherwise.

Go deeper

Related to this question