緊急！誤執行kubeadm reset后如何從etcd備份恢復K8s集群？完整避坑指南

作者：牛梓安 2025-10-22 08:03:34

誤執行 kubeadm reset 雖會導致集群癱瘓，但只要具備有效的 etcd 備份并嚴格遵循恢復流程，集群仍可搶救回來。本次恢復過程涉及控制平面重建、證書更新、節點重加入等多個關鍵環節，每一步都需嚴謹操作，尤其要注意參數一致性和時序依賴。

1.背景說明

場景：單Master架構的K8s集群，etcd以單節點形式運行在集群內。因誤操作執行kubeadm reset -f導致集群癱瘓，需基于已有的etcd備份恢復。

核心難點：

? 需同時恢復etcd數據、重建控制平面、重新加入節點

? 證書/令牌/配置文件的時序依賴關系復雜

2.前置檢查：etcd 備份有效性驗證

（此步驟建議在事故前定期執行，關鍵時刻能救命！）

#查看備份狀態及元數據
ETCDCTL_API=3 etcdctl --write-out=table snapshot status etcdbackup.db

? 關鍵指標：Hash值、總Key數量、備份時間戳

3.Master 節點恢復全流程

1）據搶救性備份（即使已誤刪！），防止進一步丟失重要信息

#打包殘留數據（可能含未被覆蓋的文件）
timestamp=$(date +%Y%m%d%H%M%S)
tar -zcvf /tmp/k8s_rescue_${timestamp}.tar.gz \
  /etc/kubernetes \
  /var/lib/kubelet \
  /var/lib/etcd 2>/dev/null

2）重建Master控制平面

#使用原參數初始化（務必與歷史參數一致！）
kubeadm init \
  --pod-network-cidr=<network-cidr> \
  --apiserver-advertise-address=<master-ip> \
  --control-plane-endpoint=<control-plane-endpoint>

?? 避坑點：

?若忘記歷史參數，檢查/etc/kubernetes/manifests/kube-apiserver.yaml殘留

? 初始化后切勿立即加入節點！

3）Etcd數據恢復實操

Step1 停止kube-apiserver等組件
mv /etc/kubernetes/manifests/ /etc/kubernetes/manifests_stop
Step2 還原etcd備份
ETCDCTL_API=3 etcdctl snapshot restore ./etcdbackup.db --skip-hash-check=true
Step3 替換數據目錄
rm -rf /var/lib/etcd/member
mv ./default.etcd/member /var/lib/etcd/member
Step4 重啟控制平面
mv /etc/kubernetes/manifests_stop /etc/kubernetes/manifests

4）證書/令牌更新關鍵操作

#強制更新所有證書
kubeadm certs renew all --force
#重啟核心組件Pod
for comp in apiserver controller-manager scheduler; do
  kubectl -n kube-system delete pod -l component=kube-${comp}
done
#需要生成一個新的 bootstrap-token
kubeadm init phase bootstrap-token
#生成新加入令牌（原token已失效）
kubeadm token create --ttl 2h --print-join-command

4.Node 節點重新接入指南

#所有Node執行
systemctl stop kubelet
kubeadm reset -f
rm -rf /var/lib/kubelet/pki/ /etc/kubernetes/pki/ /etc/kubernetes/kubelet.conf
rm -rf $HOME/.kube/config
#使用新token加入
kubeadm join <master-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<ca-cert-hash>

5.恢復后驗證清單

1）節點狀態

kubectl get nodes -o wide

2）核心Pod健康狀態

kubectl -n kube-system get pod | grep -E 'coredns|kube-proxy|etcd'

3）跨服務通信測試

kubectl run test-nginx --image=nginx
kubectl expose pod test-nginx --port=80
kubectl run test-curl --image=radial/busyboxplus:curl -it --rm -- \
  curl -v http://test-nginx.default.svc.cluster.local

4）檢查集群內域名解析

? 檢查pod對service的域名解析，如有問題需要重啟kube-proxy或coredns服務

5）恢復 Kubernetes Dashboard 或其他工具

? 如果使用了如 Kubernetes Dashboard 、kuboard等工具，需要重新安裝或重新配置它們

6.運維建議

1）定期驗證備份有效性

2）使用etcd災備工具(etcdbrctl)

3）生產環境至少部署3節點etcd集群

誤執行 kubeadm reset 雖會導致集群癱瘓，但只要具備有效的 etcd 備份并嚴格遵循恢復流程，集群仍可搶救回來。本次恢復過程涉及控制平面重建、證書更新、節點重加入等多個關鍵環節，每一步都需嚴謹操作，尤其要注意參數一致性和時序依賴。事后務必加強備份驗證與災備策略，推薦使用多節點 etcd 集群以提升容災能力。記住：定期驗證備份 + 規范運維流程 = 生產環境的救命稻草。

責任編輯：武曉燕來源：新鈦云服