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 fetches the Node object from the API server, which reflects the control plane's view of node readiness based on heartbeats and status reported by the kubelet. It will confirm that the node is indeed NotReady, but it provides no diagnostic details about why the kubelet failed to report ready status; the underlying fault could be in kubelet's communication with the container runtime, network issues, or resource pressure, all of which require inspecting logs on the node itself.

• ✗

  journalctl -u docker

  Why it's wrong here

  journalctl -u docker examines the systemd journal for the Docker daemon, which is the container runtime, not the kubelet. While a node being NotReady can be caused by the container runtime being unhealthy, Docker logs do not reveal the kubelet's own status reporting, registration, or heartbeat failures. Furthermore, many modern Kubernetes nodes use containerd or CRI-O, so Docker-specific logs may be entirely irrelevant if the cluster does not use Docker as the runtime.

• ✓

  journalctl -u kubelet

  Why this is correct

  journalctl -u kubelet is the correct first place to look because the kubelet is the component that actually reports NodeReady status to the API server and runs the node's static pods and system components. Kubelet logs will show concrete errors such as failed to GET /healthz, admission rejections, CNI plugin failures, or inability to connect to the API server, making this the most direct source of truth for diagnosing a NotReady node.

• ✓

  systemctl status kubelet

  Why this is correct

  systemctl status kubelet provides a concise snapshot of the kubelet's systemd service state: whether it is active, failed, or repeatedly restarting, along with the last few log lines and the process ID. This is a quick, time-efficient check to determine if the kubelet process has crashed, is in a crashloop, or is running but unhealthy. However, it only shows a short tail of logs, so for in-depth error diagnosis you would still need journalctl -u kubelet, which gives full journal access and can be filtered by time.

• ✗

  kubectl describe pod

  Why it's wrong here

  kubectl describe pod is meant for inspecting individual pod objects, including their events, scheduled node, containers, and recent state, which is useful for pod-level failures but useless for a node-level NotReady issue. Node readiness is a status recorded by the kubelet about the node's overall health (e.g., disk pressure, PID pressure, memory pressure, kubelet readiness probes), and no amount of pod introspection will reveal why the kubelet is failing to report a Ready status. The troubleshooting target should be the kubelet service on the affected node, not any particular pod.

Go deeper

Related to this question