After a control-plane disk fills, city operators find the API server unreachable and the kube-apiserver static pod missing under /etc/kubernetes/manifests. What should they recognize first?
Select an answer to reveal the explanation.
Short Explanation
On kubeadm, the apiserver is more like a sticky note on the node's fridge—the manifest in /etc/kubernetes/manifests—than a regular Deployment. Lose that file (disk fill can wipe or block it) and kubelet stops recreating the API.
Full Explanation
On kubeadm-based city clusters, kube-apiserver (and often etcd, controller-manager, scheduler) run as static pods whose pod manifests live under /etc/kubernetes/manifests. kubelet watches that directory and runs whatever YAML it finds. If disk-full conditions remove or prevent that apiserver manifest, kubelet will not recreate the apiserver static pod, and the API becomes unreachable—exactly the failure mode operators must recognize first. The apiserver is not a conventional Deployment in kube-system that you fix with kubectl scale; without an API you often cannot scale anything, and the lifecycle is static-pod based on kubeadm. Missing apiserver pods are not normal during etcd compaction; compaction may cause brief load but does not delete static manifests as a healthy routine. CoreDNS does not own apiserver lifecycle; restarting DNS cannot recreate a missing static pod manifest for kube-apiserver. Exam caveat: Disk pressure can also break etcd write-ahead logs or prevent image pulls; still, a missing file under manifests is the direct reason kubelet stops the static apiserver. Distinguish static pods from Deployments/DaemonSets on the exam. Operational check: On the control-plane node (console/SSH), list /etc/kubernetes/manifests, restore kube-apiserver.yaml from backup or kubeadm documentation, free disk space under /var/lib/etcd and container runtime graphs, confirm the static pod reappears via crictl/kubectl when the API returns, and add disk monitoring so city hall does not repeat the outage.