CKA Practice Question 10: API Server Static Pod Debugging
Certified Kubernetes Administrator (CKA) · Test 1 · question 10 of 10
On a kubeadm-built cluster, every kubectl command fails with The connection to the server 10.0.0.10:6443 was refused - did you specify the right host or port?.
You SSH to the control plane node. The kubelet service is active and running, and the node has not been rebooted. You suspect the API server container is failing to start after a recent edit to its configuration.
How should you investigate?
Show answer and explanation
Answer:
On a kubeadm cluster the control plane components run as static pods: the kubelet watches /etc/kubernetes/manifests/ and starts a container for each manifest it finds, with no involvement from the API server or any controller. That is what makes recovery possible here: with the API server down, you must work below it, talking to the container runtime directly. crictl ps -a shows exited containers as well as running ones, and crictl logs <container-id> reveals why the API server crashed, which is typically a syntax error or a bad flag in kube-apiserver.yaml from the recent edit.
Option A cannot work. kubectl logs is served by the API server, and the API server is exactly what is down; the same connection-refused error will come back.
Option B looks for a systemd unit that does not exist. Under kubeadm, only the kubelet is a systemd service; the API server is a container the kubelet manages, so there is nothing for systemctl or journalctl -u to report. (The kubelet's own journal, journalctl -u kubelet, is worth reading, as it logs failures to start the static pod.)
Option D misidentifies the workload type. There is no Deployment for kube-apiserver; static pods are managed entirely by the local kubelet, not by any controller. There is also no way to delete the pod through the API while the API server is unreachable; to restart a static pod you move its manifest out of the directory and back.
Reference: Troubleshooting Clusters