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.

• ✗

  Reboot the node

  Why it's wrong here

  Rebooting the node is an unnecessarily disruptive operation that may temporarily restore the kubelet merely as a side effect of the system restart, which also takes down all running pods and workloads on that node. A NotReady node is often caused by a kubelet service that is stopped or failed; the correct, targeted remedy is to start the kubelet directly with systemctl, not to reboot the entire host. Reboot also prevents you from inspecting the kubelet's logs and status before acting, which could hide the real root cause.

• ✗

  Delete the node object from the cluster

  Why it's wrong here

  Deleting the Node object from the cluster only removes the API-side representation of the node; it does absolutely nothing to start or repair the kubelet process running on the host. When the kubelet is not running, it cannot register itself, so even if you delete the Node object, the node will either remain absent or reappear as NotReady once the kubelet eventually starts. This action is meant for permanently removing a node from the cluster or automating decommissioning, not for recovering a node whose kubelet has stopped.

• ✓

  Run 'systemctl start kubelet'

  Why this is correct

  Running 'systemctl start kubelet' is the correct first recovery action because Node NotReady status almost universally means the kubelet is not actively running or has failed to report its status. Starting the kubelet makes it contact the API server, renew its heartbeat, and re-register the node with its capacity and conditions, which allows the control plane to mark it Ready again. Before starting, you should verify the service status and check logs with 'journalctl -u kubelet', but the start command is the minimal and precise fix for a stopped kubelet daemon.

• ✗

  Reinstall the kubelet package

  Why it's wrong here

  Reinstalling the kubelet package is an extreme action that should not be your first response because the failure is likely a stopped service, not a corrupted binary. If the kubelet executable and its configuration files are intact, starting the service resolves the issue; reinstalling risks introducing a version mismatch with the control plane or wiping local kubelet configuration. Only consider reinstallation after verifying that the binary is missing or corrupt or that the service repeatedly fails to start due to a broken package—otherwise, it adds unnecessary downtime and complexity.

Go deeper

Related to this question