CKA Troubleshooting Practice Question
A node in your cluster is in the 'NotReady' state. You SSH into the node and run 'systemctl status kubelet' which shows the kubelet is active but not functioning correctly. Which command should you use to get detailed logs to troubleshoot the kubelet?
⚠ Common exam trap
A common mix-up: candidates confuse the kubelet (a systemd service) with a Kubernetes pod and incorrectly choose `kubectl logs`, not realizing that the kubelet is not managed by the Kubernetes API server and its logs must be accessed via the node's system journal.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
journalctl -u kubelet
`journalctl -u kubelet` retrieves the systemd journal logs specifically for the kubelet service, which is the standard way to access detailed, timestamped logs when the kubelet is running but malfunctioning. Since the kubelet is active (not stopped), its logs are captured by systemd and can be inspected without restarting the service, preserving the current state for troubleshooting.
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 describe node <node-name>
Why it's wrong here
While `kubectl describe node` is a useful first step to inspect high-level node conditions and events from the control plane, it cannot be run locally on the node if the API server is unreachable, nor does it provide the detailed, real-time systemd logs of the kubelet service itself. To diagnose deep root causes like configuration errors or runtime failures, you must inspect the actual service logs directly on the host.
- ✓
journalctl -u kubelet
Why this is correct
Because the kubelet typically runs as a systemd service on the host operating system rather than as a containerized pod, its logs are managed by systemd-journald. Running `journalctl -u kubelet` allows you to view the service's standard output and error streams directly on the node. This is the standard method for diagnosing startup failures, certificate issues, or connection timeouts to the control plane.
- ✗
kubectl logs kubelet -n kube-system
Why it's wrong here
The `kubectl logs` command is designed exclusively to retrieve logs from containerized workloads managed by the Kubernetes API server. Since the kubelet is a system daemon running directly on the host OS bare-metal or VM layer, it does not run as a standard pod in the `kube-system` namespace. Consequently, attempting this command will result in an error indicating that no such pod exists.
- ✗
systemctl restart kubelet
Why it's wrong here
Although restarting the service with `systemctl restart kubelet` might temporarily resolve transient issues, it is an action rather than a diagnostic tool. Executing this command blindly without checking the logs first can overwrite valuable historical error context in the journal. Furthermore, if there is a persistent configuration error, restarting the service will simply cause it to crash again without revealing why.
Go deeper
Related to this question
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.