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.

• ✗

  The kubelet is not running on the nodes.

  Why it's wrong here

  If the kubelet were not running on a node, the node would be marked NotReady in `kubectl get nodes` because the kubelet is responsible for posting node status and heartbeats to the control plane. A non-running kubelet would cause widespread pod failures and the node to disappear from scheduling, not merely a missing metrics response. The `kubectl top nodes` error specifically indicates that the cluster cannot serve the metrics API, which is a separate component (Metrics Server) that gathers data from kubelets. Thus, while a healthy kubelet is required for metrics collection, a failure of the kubelet would manifest with much more severe symptoms than this error.

• ✗

  The cluster is using an older version of Kubernetes.

  Why it's wrong here

  Kubernetes has supported the `metrics.k8s.io` API group since version 1.8, and `kubectl top` relies on this API regardless of cluster version. Even relatively old but still supported clusters can expose node metrics by installing the Metrics Server, a cluster add-on that aggregates resource usage. The command's failure is not due to version incompatibility because the API is part of the aggregation layer and can be provided by any metrics collection solution implementing it. Therefore, an older Kubernetes version alone would not cause the error unless the metrics-server itself is missing, which is the true underlying issue.

• ✗

  The nodes are under heavy load.

  Why it's wrong here

  Heavy node load does not prevent the kubelet from collecting metrics; the kubelet reads cgroup stats and periodically exposes them through the Summary API, and this local collection continues even when CPU or memory pressure is high. The Metrics Server scrapes these endpoints and aggregates the data, so a loaded node would simply report high utilization rather than an error. An overloaded Metrics Server pod might occasionally time out, but that would produce a different error message and is not a reliable explanation. The error from `kubectl top nodes` is about the availability of the metrics API, not about the measured load values.

• ✓

  The Metrics Server is not installed or not functioning.

  Why this is correct

  The Metrics Server is a cluster add-on that collects resource metrics from each kubelet and exposes them through the aggregated `metrics.k8s.io` API; `kubectl top nodes` queries this API to display usage figures. If the Metrics Server is not installed, or if its pods are failing to start (e.g., due to image pull issues or invalid configuration), the API is unavailable and the command returns an error such as 'metrics.k8s.io is not available' or 'the server is currently unable to handle the request.' Even when installed, it may need about 15 seconds to collect its first batch of metrics; if queried immediately after cluster startup, you might see an empty or error response. Checking for metrics-server pods in the `kube-system` namespace and verifying that the aggregated API is registered will confirm this root cause.

Go deeper

Related to this question