Open-data staff accidentally delete the control-plane static pod YAML files from /etc/kubernetes/manifests on a kubeadm node. What is the immediate operational risk?
Select an answer to reveal the explanation.
Short Explanation
Those manifests are the ignition key under kubelet's watch folder. Delete them and kubelet shuts off the control-plane static pods—no magic Helm undo for that path.
Full Explanation
Static pod manifests under /etc/kubernetes/manifests are the ignition keys kubelet watches on kubeadm nodes. If open-data staff accidentally delete those control-plane YAML files, kubelet stops the corresponding static pods—kube-apiserver, etcd, scheduler, or controller-manager as applicable—taking down those components immediately. There is no automatic Helm release undo that rewrites those host files for you. kubectl will not recreate the files from Helm release history for kube-apiserver; kubeadm static pods are file-watched by kubelet, not chart-reconciled that way. Deletion is not limited to Ingress resources; etcd and scheduler on kubeadm are typically static pods as well, not ordinary Deployments that keep running after manifests vanish from disk. Static manifest deletion is not ignored until the next upgrade window; kubelet reconciles the manifests directory continuously, so removal has immediate effect. Exam caveat: Recovery usually means restoring files from backup or regenerating with kubeadm phase commands—know that without manifests, the control plane stays down even if container images still exist locally on the node. Operational check: Use console or out-of-band SSH, restore manifests from a secure backup, ensure the disk is not full, watch static pods return with crictl and a restored API, and tighten who can modify /etc/kubernetes on city control-plane hosts.