A Kubernetes worker node, named wk8s-node-0 is in state NotReady. Investigate why this is the case, and perform any appropriate steps to bring the node to a Ready state, ensuring that any changes are

Question

Explanation

Kubernetes Node Troubleshooting: NotReady State

Overall Goal

A NotReady node means the control plane has lost communication with the node's kubelet - the primary agent that runs on every worker node, registers it with the cluster, and manages pod lifecycles. The most common cause in exam scenarios is that the kubelet service has stopped and is no longer running (or was never configured to start on boot). The fix is to restart it and make that restart permanent via systemd.

Step-by-Step Procedure

Step 1 - Set the correct context

kubectl config use-context k8s

Why: CKA exams run multiple clusters. Every task starts by switching context, otherwise all your kubectl commands hit the wrong cluster. Skipping this is the most common reason exam answers fail silently.

Step 2 - Confirm the node's status from the control plane

kubectl get nodes

Then get more diagnostic detail:

kubectl describe node wk8s-node-0

Why: The Conditions section in describe output will show messages like:

Ready   False   ...   KubeletNotReady   kubelet stopped posting node status

This tells you the kubelet stopped reporting. It also rules out other causes (network plugin failure, disk pressure, etc.) and confirms you're looking at the right node.

What if you skip this: You might SSH to the wrong node or misdiagnose the problem (e.g., wasting time on the container runtime when the real issue is kubelet).

Step 3 - SSH into the failed node

ssh wk8s-node-0

Why: Node-level issues cannot be fixed from the control plane. The kubelet is a systemd service on the OS itself, so you must access the node directly.

Step 4 - Elevate privileges

sudo -i

Why: Managing systemd services (systemctl start/enable) requires root. Without this, all subsequent commands fail with permission errors. sudo -i gives you a full root shell (sets PATH, working directory, etc.), which is cleaner than prefixing every command with sudo.

Step 5 - Check the kubelet service status

systemctl status kubelet

Why: This confirms the kubelet is indeed stopped (inactive (dead) or failed). If it shows active (running), the problem is something else entirely (e.g., container runtime, CNI plugin), and you need to pivot your investigation.

You can also inspect recent logs:

journalctl -u kubelet --no-pager | tail -30

Step 6 - Start the kubelet

systemctl start kubelet

Why: This restarts the kubelet process immediately. Without this, the node stays NotReady regardless of what else you do. After ~30–60 seconds, the kubelet re-registers with the API server.

Step 7 - Enable the kubelet to survive reboots (the "permanent" requirement)

systemctl enable kubelet

Why: start only runs the service for the current boot session. The question explicitly says "ensuring any changes are made permanent" - this is enable. It creates a systemd symlink so the kubelet starts automatically on every reboot.

What if you skip this: The node recovers now, but after the next reboot it goes NotReady again. In an exam, this is a partial answer and may receive no credit because the permanence requirement was stated explicitly.

Step 8 - Verify recovery from the control plane

Exit back to the original node and check:

kubectl get nodes

wk8s-node-0 should transition from NotReady → Ready within a minute.

What Goes Wrong If Steps Are Out of Order

Memory Aid

Think of it as S-S-S-S-E:

1. Switch context
2. SSH in
3. Sudo up
4. Start kubelet
5. Enable kubelet

Or just remember the two-command fix and why each matters:

start = now, enable = forever

No community discussion yet for this question.