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.

• ✗

  kubectl get nodes

  Why it's wrong here

  kubectl get nodes queries the Kubernetes API server for the Node objects' status conditions, specifically the Ready condition reported by the kubelet's periodic heartbeats (nodeStatusUpdateFrequency). If the kubelet is down, the controller-manager's node lifecycle controller eventually marks the node NotReady, but this is an indirect, delayed symptom, not the live service state. The command is also limited to the control plane's view, so it cannot distinguish between a stopped kubelet, a network partition, or a kubelet that is crashing and restarting. It provides cluster-level readiness, not the actual status of the systemd unit on the worker node.

• ✓

  systemctl status kubelet

  Why this is correct

  systemctl status kubelet is the definitive, node-local command for inspecting the kubelet's systemd service state. It directly queries systemd's unit properties, showing whether the unit is active (running), failed, activating, or inactive, along with the main process ID (MainPID) and recent journal entries. This is the first step when the kubelet is suspected of malfunctioning because it immediately confirms whether the process is alive and healthy from the init system's perspective, without relying on the Kubernetes API or network latency. It also reveals the exit code or last status change, which is essential for diagnosing crashes or manual stops on the node itself.

• ✗

  kubectl describe node <node-name>

  Why it's wrong here

  kubectl describe node <node-name> fetches a comprehensive Node resource from the API server, including capacity, allocatable resources, taints, labels, conditions, and events. While it shows the NodeReady condition and may include a condition message like 'Kubelet stopped posting node status,' this information is a status report maintained by the controller-manager, not a direct query of the kubelet service. It will not tell you whether the kubelet systemd unit is currently active, what its PID is, or whether it is in a crash loop — those details exist only on the node's local system. Thus, it is useful for observing the effect of a suspected kubelet issue, but it is the wrong tool for verifying the service's actual operational state.

• ✗

  journalctl -u kubelet

  Why it's wrong here

  journalctl -u kubelet streams or prints the kubelet's logs from the node's journal (systemd's logging facility), which is invaluable for understanding why the kubelet failed or what it is doing. However, the mere presence of logs — even recent ones — does not tell you the current service status; a crashed process may have last written logs minutes ago, and an oom-killed kubelet will have a final log lines but be non-running. Unlike systemctl status, journalctl does not query the unit's active state, PID, or exit code, so it cannot replace a direct status check. It is a diagnostic complement, not a status verification tool.

Go deeper

Related to this question