kubeadm reset 用于尽力撤销 kubeadm init 或 kubeadm join 在本机做出的更改。它不是通用故障修复按钮，也不是完整卸载器。错误地在控制平面节点执行，可能移除本地 etcd 成员并造成集群中断。
一、什么情况下考虑 reset
1. 工作节点需要永久退出并重新初始化。
2. 节点加入了错误集群，需要清理后加入正确集群。
3. kubeadm 初始化失败，确认没有需要保留的状态后重新开始。
4. 节点操作系统或运行时配置将被重建。
如果只是 Pod 异常、kubelet暂时失败、证书或 CNI 故障，应先排查根因。reset 会破坏节点本地 Kubernetes 状态，不应作为第一反应。
二、工作节点下线前先迁移业务
先检查节点上的工作负载：
kubectl get pod -A \
--field-selector spec.nodeName=<NODE_NAME>
禁止调度并驱逐普通工作负载：
kubectl drain <NODE_NAME> \
--ignore-daemonsets \
--delete-emptydir-data
--delete-emptydir-data 会删除随 Pod 生命周期存在的本地临时数据。执行前确认应用可以重建，并检查 PDB、StatefulSet、本地卷和静态 Pod。
确认业务已迁移后，从 API 中删除 Node 对象：
kubectl delete node <NODE_NAME>
如果节点只是短期维护且还要原样返回，通常不需要 reset，完成维护后 uncordon 即可。
三、控制平面节点风险更高
控制平面节点可能运行 API Server、Scheduler、Controller Manager 和 stacked etcd。
kubeadm reset 在控制平面节点会尝试移除本地 etcd 成员。多控制平面集群必须先确认剩余成员仍有 quorum；单控制平面集群执行 reset，等同于破坏当前控制面。
操作前至少需要：
1. 已验证的 etcd 快照。
2. /etc/kubernetes 安全备份。
3. etcd 成员与控制面拓扑记录。
4. 负载均衡后端调整方案。
5. 明确的恢复或重新加入流程。
外部 etcd 不会被 kubeadm reset 自动清空，重新初始化时可能仍看到旧集群数据。
四、先做 dry-run
在目标节点确认即将执行的动作：
sudo kubeadm reset --dry-run
确认目标节点、CRI socket、证书目录和影响范围后，再执行实际重置：
sudo kubeadm reset
如果机器安装了多个容器运行时，可能需要显式指定正确的 --cri-socket。不要为了跳过所有检查就使用 --ignore-preflight-errors=all。
五、reset 不会清理所有内容
官方文档明确指出，kubeadm reset 是 best effort，并不会自动处理所有残留：
1. /etc/cni/net.d 中的 CNI 配置通常不会清理。
2. kube-proxy 写入的 iptables、nftables 或 IPVS 规则不会全部清理。
3. 用户家目录的 $HOME/.kube 不会清理。
4. external etcd 数据不会清理。
5. 业务数据、挂载卷和第三方组件状态不属于 kubeadm 的清理范围。
这些残留不一定都需要删除。应先检查和备份，再根据节点是否加入同一集群、是否更换 CNI、是否改作其他用途决定。
不要把 rm -rf /etc/cni/net.d、清空防火墙和删除整个 $HOME/.kube 写成无条件步骤。它们可能破坏其他网络配置或仍然有效的管理凭据。
六、重新加入前检查
节点重新加入前确认：
1. 主机名和节点身份符合规划。
2. 时间同步正常。
3. 容器运行时健康，CRI socket 正确。
4. kubeadm 与目标控制面版本符合版本偏差策略。
5. kubelet配置和 cgroup 驱动与运行时兼容。
6. 节点可以访问 API Server、镜像仓库和 DNS。
7. 旧 CNI 配置不会与新集群冲突。
8. 防火墙开放了当前架构真正需要的端口。
七、生成新的加入命令
在健康的控制平面节点生成短期加入命令：
sudo kubeadm token create --print-join-command
输出形式类似：
sudo kubeadm join \
<CONTROL_PLANE_ENDPOINT> \
--token <BOOTSTRAP_TOKEN> \
--discovery-token-ca-cert-hash sha256:<CA_HASH>
Bootstrap Token 属于敏感信息，默认有有效期。不要把真实 join 命令发布到博客、工单或代码仓库。使用后可以检查并删除不再需要的 Token。
在工作节点执行经过安全传递的 join 命令，然后在控制面验证：
kubectl get nodes -w
kubectl describe node <NODE_NAME>
八、重新加入后验证
1. Node 状态变为 Ready。
2. kube-system 中的 CNI、kube-proxy 或相应数据面正常。
3. 节点标签、污点和角色符合预期。
4. DNS 和 Service 网络可用。
5. CSI Node 插件与卷挂载正常。
6. 监控、日志、安全代理和 DaemonSet 已运行。
7. 调度测试 Pod 并验证网络和存储。
如果节点 Ready 但业务不能通信，重点检查 CNI 残留、NetworkPolicy、路由、MTU 和 kube-proxy/替代数据面。
九、常见问题
节点名称已存在：确认旧 Node 对象是否仍在 API 中，并核对证书和主机名，不要简单修改名称绕过问题。
Token 过期：重新生成短期 Token，不要使用 unsafe-skip-ca-verification 绕过 CA 校验。
CNI 初始化失败：检查 /etc/cni/net.d、CNI 二进制、节点路由、内核模块和 CNI DaemonSet 日志。
kubelet 无法注册：检查 API Server 连接、bootstrap kubeconfig、证书签发、CRI 和版本偏差。
控制平面重新加入失败：它还涉及 certificate-key、共享控制面端点、etcd 成员和证书分发，应使用高可用 kubeadm 官方流程，不能照搬工作节点命令。
总结
安全的节点重置流程是：确认真的需要 reset → 迁移工作负载 → 评估数据和控制面风险 → dry-run → 执行 reset → 有选择地处理残留 → 使用短期可信 Token 重新加入 → 验证网络、存储和系统代理。重置是破坏性操作，必须建立在备份和明确范围之上。
参考资料：
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-reset/
https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/adding-linux-nodes/
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/