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.

• ✗

  Restart all containers on the node

  Why it's wrong here

  Restarting all containers on the node is not a diagnostic procedure; it merely disrupts running workloads and can exacerbate the problem by causing unnecessary pod restarts and downtime. Node NotReady is a kubelet-level condition that is not resolved or diagnosed by cycling containers, as the kubelet itself, not individual containers, is responsible for reporting readiness. This action yields no log output or state inspection to identify the underlying cause, making it an invalid first step in troubleshooting.

• ✓

  Check the kubelet service logs using 'journalctl -u kubelet'

  Why this is correct

  The kubelet is the component that reports Node status and manages pod lifecycle on each node; its logs often contain explicit error messages such as CNI failures, timeouts contacting the API server, or runtime issues. 'journalctl -u kubelet' allows you to view the kubelet's systemd journal, which is the authoritative source for why the kubelet has marked the node as NotReady. This is a direct, non-invasive diagnostic step that should be performed first when investigating node readiness problems.

• ✗

  Check the kube-apiserver logs on the control plane

  Why it's wrong here

  The kube-apiserver handles API requests and stores cluster state, but it does not determine or directly influence node readiness. Node conditions are set by the kubelet reporting to the API server, and the kubelet itself is the one that performs readiness checks; any API server connectivity issues would manifest in kubelet logs, not apiserver logs. Checking apiserver logs may reveal control plane health but will not explain why a specific node is NotReady, making it an indirect and ineffective diagnostic for this issue.

• ✗

  Check kube-proxy configuration

  Why it's wrong here

  kube-proxy is responsible for implementing service networking, including ClusterIP and load balancing, but it has no role in determining node readiness. Node readiness is evaluated by the kubelet using a set of checks, including whether the runtime is healthy and the CNI network plugin is functioning; kube-proxy misconfiguration could cause service connectivity problems but would not cause a node to be marked NotReady. Therefore, inspecting kube-proxy configuration is an irrelevant step for diagnosing a node-level condition like NotReady.

• ✓

  Verify the network plugin (e.g., Calico, Flannel) pods are running

  Why this is correct

  Node readiness depends on the kubelet successfully setting up pod networking via a CNI plugin such as Calico or Flannel; if the respective DaemonSet pods are not running or are unhealthy on that node, the kubelet may fail its network readiness probe, resulting in NotReady. Checking the status of network plugin pods tells you whether the required CNI components are running, and if they are crashing, that directly explains the node's condition. This is a targeted diagnostic that can quickly confirm whether a common cause of NotReady is present.

Go deeper

Related to this question