A city SRE accidentally runs kubeadm init a second time on a node that still has leftover cluster state from a prior attempt. What should they do before a clean re-initialization?
Select an answer to reveal the explanation.
Short Explanation
Trying to init twice on a dirty node is like pouring a new foundation over rubble—you’re asking for cracks. Reset the node first (kubeadm reset, plus any leftover CNI/iptables mess), then init on a clean slate. Skipping reset is how you get half-dead certificates and confused etcd directories.
Full Explanation
When a city SRE accidentally runs kubeadm init on a node that still has leftover cluster state, they must run kubeadm reset (and clean residual CNI/iptables state as needed) before a clean re-initialization. Pouring a new foundation over rubble invites cracks—reset first, then init on a clean slate so PKI, static pods, and etcd directories are coherent. Only restarting containerd does not remove prior PKI and etcd data; kubeadm init is not guaranteed to overwrite a dirty bootstrap safely in place. Deleting /etc/kubernetes/manifests alone without reset leaves conflicting certificates and etcd data that break the new control plane. There is no supported --force-reinit that merges two control planes on one host; that approach invents split-brain risk. Exam caveat: Dirty nodes need reset before re-init; partial cleanup is a common outage pattern. Operational check: kubeadm reset, clean CNI interfaces/iptables remnants per runbook, verify /etc/kubernetes is clear as expected, then kubeadm init and confirm control-plane Pods become Ready. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services.