What kubeadm reset actually does¶

kubeadm reset reverts most of the changes kubeadm init/kubeadm join made to a node: it stops the kubelet, removes the node's local PKI/certificates and kubeconfig files (/etc/kubernetes/*), and attempts to unmount and clean up directories under /var/lib/kubelet. It does not:

• Remove the node object from the API server on other control-plane nodes (run kubectl delete node <name> from a still-healthy node/control plane first if the cluster is otherwise up).
• Reliably clean up CNI configuration or leftover iptables/ipvs rules on every CNI plugin — this is the most common source of a "reset but still broken networking" node.
• Uninstall kubelet, kubeadm, or container runtime packages — it only undoes cluster state, not package installation.

Dry run first¶

sudo kubeadm reset --force --dry-run

--dry-run prints exactly what actions reset would take (files removed, services stopped) without actually performing them — worth running first on anything other than a disposable lab node, since reset is destructive and has no undo.

--force skips the interactive "are you sure?" confirmation prompt, which matters for scripted/automated resets but means there's no safety pause on a real node.

Perform the reset¶

sudo kubeadm reset --force

Full teardown order (for a live cluster)¶

If the node being reset is currently part of a functioning cluster (rather than a fully broken lab node you're just wiping), do the following in order to avoid leaving stale state behind on other nodes:

1. Drain the node (from a control-plane node, while the target is still healthy): kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data
2. Delete the node object from the cluster: kubectl delete node <node-name>
3. Run kubeadm reset on the node itself, as above.
4. Clean up CNI leftovers — kubeadm reset often leaves CNI configuration and virtual interfaces behind. For most CNI plugins: sudo rm -rf /etc/cni/net.d sudo ip link delete cni0 sudo ip link delete flannel.1 # if using Flannel; adjust interface name for your CNI
5. Flush leftover iptables rules (safe on a node being wiped/rejoined, disruptive on anything else sharing the host): sudo iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X
6. Remove local kubeconfig if one was copied to a user's home directory for kubectl access on that node: rm -rf ~/.kube

Re-joining or re-initializing afterward¶

• To rejoin an existing cluster: generate a fresh join command from a control-plane node (kubeadm token create --print-join-command) and run it on the reset node — the old join token/certs were removed by reset and won't work again.
• To re-initialize as a new control plane: sudo kubeadm init as usual. If this is a control-plane node being rebuilt into the same cluster (not a fresh one), make sure any old etcd member entry for it has been removed first (etcdctl member remove <id>) or the new node can fail to join etcd cleanly.

Common gotchas¶

• Resetting a control-plane node in a multi-control-plane (stacked etcd) cluster without first removing its etcd member can leave the etcd cluster in a degraded/quorum-loss state — check etcdctl member list before and after.
• Forgetting the CNI/iptables cleanup step is the most common cause of "the node rejoined but pods can't reach each other" after a reset+rejoin cycle.
• kubeadm reset does not touch container images already pulled on the node or running containers outside of Kubernetes' own management — a full disk-space reclaim needs a separate crictl rmi $(crictl images -q) (or docker system prune, depending on runtime).