K8S Master 誤執行 reset，雪崩解決過程

來源：K8S中文社區
node

概述：因爲不當心在K8S惟一的master上誤執行kubeadm reset產生的一系列問題。
web

背景：

公司準備遷移一個K8S集羣，當前集羣是kubeadm+外部etcd的架構，準備把若干原來的虛擬機節點和etcd，移到新買的高配物理機上。

首先：遷移etcd

因爲沒有足夠的機器，打算用恢復快照的方式起新etcd。遷移並不順利，用恢復快照的方式發現配置項kubeadmin-config數據有誤，（時間緊迫沒有深追緣由）只好經過把整個文件/var/lib/etcd拷貝還有證書（server、server-key、ca）到新機器上，而後在啓動選項中加入--initial-cluster-state=new強行啓動etcd服務。

第二：把舊master的etcd指向新etcd

發現僅在配置中更換etcd的地址不能成功，由於原etcd自簽證書並不包括新機器IP，因此重簽證書，而後下發到舊master上，而後修改/etc/kubernetes/manifests/kube-apiserver.yaml中etcd地址爲新IP

第三： 添加新master到現有集羣

join master的方式

首先在舊master上生成token、cert和它們的hash值

kubeadm init phase upload-certs --upload-certs

獲得--certificate-key的hash值

kubeadm token create --print-join-command

獲得token和 --discovery-token-ca-cert-hash值

完整命令

kubeadm join <API_HA_IP:6443> --token <TOKEN> --discovery-token-ca-cert-hash <TOKEN-HASH> --certificate-key <certificate-key> control-plane

（以上操做其實失敗，還在摸索緣由）

中間在執行的過程當中，出了幾回麻煩，因此會時不時執行kubeadm reset操做重置節點。忽然不當心在舊master上執行了reset，崩潰！這下新master還沒進來，惟一的舊master被重置，apiserver失去通信。。。整個k8s至關於掛了。

緊急補救措施：

所幸etcd在外部，而且正常運行，這意味着只要恢復master和apiserver，那集羣的數據應該還在

首先，在舊master所在的機器上從新初始化

但是初始化後，kubectl get node 發下只有master在線，其餘節點所有notready

分析半天日誌發現是flannel認證失敗

把已有的flannel相關資源所有刪除（serviceaccount、configmap、daemonsets）

用官方的yaml文件從新生成flannel

而後，每一箇舊worker節點執行reset並再次join到集羣，這波操做後貌似正常了

可是次日發現全部proxy、coredns、flannel都crash，集羣仍是垮的

這時發現新狀況以下：

flannel報鏈接： 10.0.96.1 time out

1.說明apiserver的service訪問超時

2.apiserver由kube-proxy建立的endpoint不存在

3.kube-proxy報認證失敗 Failed to list *v1.Service: Unauthorized

認證失敗的緣由是：etcd保存的serviceaccount產生的secret數據是舊master的ca，而新master的ca已經變化，因此認證失敗

解決辦法：

1.刪除全部現有proxy、cordns的serviceaccount

kubectl get sa -n kube-system|grep -E "kube-proxy|coredns"|awk '{print "kubectl delete sa",$1,"-n kube-system"}'|/bin/bash

2.從新初始化master，讓K8S自動生成和ca匹配的serviceaccount和secret，該secret是proxy的認證依據。

yes|kubeadm reset

kubeadm init --config <yourconfig.yaml>

3.刪除全部舊flannel資源

kubectl delete -f <kube-fannel.yaml>

4.從新生成flannel

kubectl applay -f <kube-fannel.yaml>

5.從新reset其餘節點再jion

yes|kubeadm reset

kubeadm join <API_HA_IP:6443> --token <TOKEN> --discovery-token-ca-cert-hash <CERT-HASH>

所有操做後，proxy、coredns、flannel均正常運行了，繼續觀察中

其中有個statefulset一直報錯，查看日誌，發現仍是認證失敗

經查，也是由於啓用了serviceaccount致使etcd保存的secret仍是舊值，刪除該secret

該pod終於正常了

kubect get pod -A -o wide | more

檢查全部pod所有正常

以上，集羣終於所有恢復

結語：此次故障最萬幸的是採起了外部etcd，而且etcd正常遷移了。若是是默認kubeadm捆綁式etcd，那master被reset後，從新搭建集羣事小，關鍵是全部配置還得從新創建，損失就大了.

後臺回覆「加羣」，帶你進入高手如雲交流羣api

推薦閱讀：bash

一次成功的ARP黑客欺騙攻擊
微信

幾個使用GitHub的正確姿式
網絡

從理論到實踐，全方位認識 DNS架構

淺談互聯網那些防不勝防的人肉搜索技巧
併發

阿里雙11，億級流量高併發是怎麼抗住的？app

9 個問題進一步熟悉 HTTPSide

一文看懂DevOps，再不懂來打我

Linux 下 4 種實時監控日誌文件的方法

一文理解TCP、UDP協議及二者的區別

爲何 TCP 創建鏈接須要三次握手

▼

喜歡，就給我一個「在看」

10T 技術資源大放送！包括但不限於：雲計算、虛擬化、微服務、大數據、網絡、Linux、Docker、Kubernetes、Python、Go、C/C++、Shell、PPT 等。在公衆號內回覆「1024」，便可免費獲取！！

本文分享自微信公衆號 - Linux雲計算網絡（cloud_dev）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。