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.

• ✓

  Network plugin (e.g., Calico) is not functioning

  Why this is correct

  The kubelet determines node readiness by reporting conditions such as Ready, and one key condition the kubelet watches is the status of the container network interface (CNI). If the network plugin (e.g., Calico, Flannel, Cilium) fails to install routes, pods, or the CNI binaries, the kubelet cannot set up pod networking, causing the Ready condition to become False. The kubelet may also have its own network readiness checks (like the NodeStatus condition for network) that fail, and the node will stay NotReady until the CNI plugin is restored. This is why a healthy kubelet and Kubernetes control plane can still show a node as NotReady when the overlay network is broken.

• ✗

  A pod is in CrashLoopBackOff

  Why it's wrong here

  CrashLoopBackOff is a pod-level condition reported by the kubelet on a specific pod whose containers keep terminating, but the kubelet itself remains healthy and capable of reporting node status. Node readiness is a separate, health-based aggregate that the kubelet computes from its own runtime and network checks, not from the state of individual workloads. Even if every pod on a node is crashing, the node can still be Ready as long as the kubelet, container runtime, and required node conditions are satisfied. Therefore, a CrashLoopBackOff pod is a symptom of a workload problem, never a direct cause of node-level NotReady.

• ✓

  kubelet service is stopped

  Why this is correct

  The kubelet is the agent that runs on each node and is responsible for executing the node's periodic status updates, including the Ready condition sent to the control plane via NodeStatus. If the kubelet service is stopped (e.g., systemctl stop kubelet), it no longer reports heartbeats or updates the Node object, so the controller-manager marks the node NotReady after the node-monitor-grace-period (default 40s). Without a running kubelet, the node cannot even perform basic health checks on the container runtime or manage pods, let alone declare itself ready for scheduling. Thus, a stopped kubelet is a direct and definitive cause of NotReady.

• ✓

  Disk pressure on the node

  Why this is correct

  Disk pressure is one of the node conditions (along with MemoryPressure, PIDPressure, etc.) that the kubelet evaluates based on eviction thresholds set via kubelet flags like --eviction-hard. When the node's filesystem usage exceeds those thresholds, the kubelet sets the DiskPressure condition to True, and because a node with DiskPressure is not Ready for new scheduling, the NodeReady condition is set to Unknown or False. The kube-apiserver and controller-manager then propagate this status, and existing pods may be evicted to relieve the pressure. Disk pressure is a resource-level condition that is independent of the network plugin or the kubelet's running state, making it a distinct cause of NotReady in the list.

• ✗

  The API server is overloaded

  Why it's wrong here

  The API server is the front-end for all Kubernetes control-plane communication, but node readiness is not determined by the API server's availability or load. The kubelet periodically posts NodeStatus updates to the API server, and the external cloud-controller-manager or the node controller monitors those heartbeats; if the API server is overloaded, it may respond slowly, but the node status itself is still reported or already stored. Even during an API server outage, existing node conditions remain whatever the kubelet last reported, and the node controller's logic depends on the last heartbeat timestamp, not on the API server's current throughput. Therefore, an overloaded API server can cause client timeouts or degraded control-plane operations, but it does not actively flip a node to NotReady.

Go deeper

Related to this question