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.

• ✗

  systemctl status docker and tail -f /var/log/syslog

  Why it's wrong here

  This option targets the wrong daemon: in modern Kubernetes, Docker is not the container runtime kubelet uses—containerd (or another CRI-compliant runtime) is the default, and the kubelet process itself is independent of the Docker daemon. Running `systemctl status docker` only tells you about the Docker service, not the kubelet. Additionally, `tail -f /var/log/syslog` is unreliable because kubelet logs are typically written to the journal, not syslog, and many distros route them through `journald`; you might see unrelated entries and miss the actual failure.

• ✗

  kubectl get nodes and kubectl describe node <node>

  Why it's wrong here

  These commands inspect the node from the control plane's perspective, but they do not directly query the local systemd service on the worker. `kubectl get nodes` shows the node's Ready condition, which is updated by kubelet heartbeats; if kubelet died, the node would eventually become NotReady, but that state can also result from network partitions or API server issues. `kubectl describe node <node>` gives conditions, capacity, and events, but none of this verifies whether the kubelet process is actually running or why it stopped—you need to log into the node and check the unit directly.

• ✗

  systemctl restart kubelet and journalctl -u containerd

  Why it's wrong here

  This is an intervention, not a diagnosis: `systemctl restart kubelet` will simply start the process again and may hide the root cause, especially if the failure is due to a misconfiguration or a crash loop. Worse, `journalctl -u containerd` reads logs from the container runtime, not the kubelet; while runtime issues can affect kubelet indirectly, they won't show the kubelet's own errors, such as a failed TLS bootstrap or a stuck volume mount. The correct first step is to inspect the kubelet unit's status and its journal, not to restart it or look at a different service.

• ✓

  systemctl status kubelet and journalctl -u kubelet

  Why this is correct

  This is the standard diagnostic pair for a systemd-managed kubelet. `systemctl status kubelet` shows whether the unit is active (running), failed, or inactive, and gives the last few log lines plus the main process PID; it also returns a non-zero exit code when the service is not running, which is useful for scripting. `journalctl -u kubelet` retrieves the full journal for the kubelet unit, allowing you to see startup errors, crashed state, or repeated restarts—critical for identifying why the kubelet stopped, such as a bad kubelet config, certificate expiry, or a missing CSI driver.

Go deeper

Related to this question