誤刪節點或集群怎么辦？這里有一顆后悔藥

本文來自Rancher Labs

作者介紹

王海龍，Rancher中國社區技術經理，負責Rancher中國技術社區的維護和運營，擁有6年的云計算領域經驗，經歷了OpenStack到Kubernetes的技術變革，無論底層作業系統Linux，還是虛擬化KVM或是Docker容器技術都有豐富的運維和實踐經驗，

在實際使用Rancher程序中，偶爾會因為誤操作洗掉了System Workload、節點或集群, 導致集群狀態例外而無法訪問，如果用戶不了解恢復方法，通常會重新添加節或重新搭建集群，

本文將根據以下幾個場景來介紹如何恢復由于誤操作引起的Rancher集群故障：

• 如何恢復System Project Workload

• 如何恢復從Rancher UI或kubectl誤刪的節點

• 如何恢復執行過清理節點腳本的節點

• 如何恢復被洗掉的custom集群

重要說明

• 本檔案基于Rancher 2.4.x測驗，其他版本操作可能會略有不同

• 本文介紹的場景均是針對custom集群

• 如果您在此程序中遇到問題，則應該熟悉Rancher架構/故障排除

• 您應該熟悉單節點安裝和高可用安裝之間的體系結構差異

如何恢復System Project Workload

System Project中包含了一些保證該集群能夠正常運行的一些workload，如果洗掉某些workload可能會對該集功能群造成影響，

通常情況下，通過RKE創建的custom集群應包括以下workload：

下面我們來分別介紹如果誤刪了這些workload之后應如何恢復，

恢復cattle-cluster-agent和cattle-node-agent

模擬故障

從System Project下洗掉 cattle-cluster-agent和cattle-node-agent

生成Kubeconfig和集群yaml

1.在Rancher UI上創建API token（用戶-> API & Keys）并保存Bearer Token

2.選擇集群后，在Rancher UI（格式為c-xxxxx）中找到其clusterid，并在地址欄中找到它，

3.根據步驟1-2獲取的變數替換：RANCHERURL、CLUSTERID、TOKEN（主機需要安裝curl和jq）

# Rancher URL
RANCHERURL="https://192.168.99.201"
# Cluster ID
CLUSTERID="c-v6mtr"
# Token
TOKEN="token-klt5n:2smg6n5cb5vstn7qm797l9fbc7s9gljxjw528r7c5c4mwf2g7kr6nm"
# Valid certificates
curl -s -H "Authorization: Bearer ${TOKEN}" "${RANCHERURL}/v3/clusterregistrationtokens?clusterId=${CLUSTERID}" | jq -r '.data[] | select(.name != "system") | .command'
# Self signed certificates
curl -s -k -H "Authorization: Bearer ${TOKEN}" "${RANCHERURL}/v3/clusterregistrationtokens?clusterId=${CLUSTERID}" | jq -r '.data[] | select(.name != "system") | .insecureCommand'

以上命令執行成功后，將回傳匯入集群的命令，請做好備份，命令如下：

curl --insecure -sfL https://192.168.99.201/v3/import/2mgnx6f4tvgk5skfzgs6qlcrvn5nnwqh9kchqbf5lhlnswfcfrqwpr.yaml | kubectl apply -f -

恢復cattle-cluster-agent和cattle-node-agent

1、在具有controlplane角色的節點上生成kubeconfig

docker run --rm --net=host -v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro --entrypoint bash $(docker inspect $(docker images -q --filter=label=io.cattle.agent=true) --format='{{index .RepoTags 0}}' | tail -1) -c 'kubectl --kubeconfig /etc/kubernetes/ssl/kubecfg-kube-node.yaml get configmap -n kube-system full-cluster-state -o json | jq -r .data.\"full-cluster-state\" | jq -r .currentState.certificatesBundle.\"kube-admin\".config | sed -e "/^[[:space:]]*server:/ s_:.*_: \"https://127.0.0.1:6443\"_"' > kubeconfig_admin.yaml

2、應用更新

將https://xxx/v3/import/dl75kfmmbp9vj876cfsrlvsb9x9grqhqjd44zvnfd9qbh6r7ks97sr.yaml 替換為生成Kubeconfig和集群yaml步驟中生成的yaml連接,本例為https://192.168.99.201/v3/import/2mgnx6f4tvgk5skfzgs6qlcrvn5nnwqh9kchqbf5lhlnswfcfrqwpr.yaml

docker run --rm --net=host -v $PWD/kubeconfig_admin.yaml:/root/.kube/config --entrypoint bash $(docker inspect $(docker images -q --filter=label=io.cattle.agent=true) --format='{{index .RepoTags 0}}' | tail -1) -c 'curl --insecure -sfL https://xxx/v3/import/dl75kfmmbp9vj876cfsrlvsb9x9grqhqjd44zvnfd9qbh6r7ks97sr.yaml | kubectl apply -f -'

驗證

接下來通過Rancher UI或kubectl可以看到 cattle-cluster-agent和cattle-node-agent 已經恢復，

恢復kube-api-auth

默認情況下，RKE 集群會默認啟用授權集群端點，這個端點允許您使用 kubectl CLI 和 kubeconfig 檔案訪問下游的 Kubernetes 集群，RKE 集群默認啟用了該端點，

如果誤刪kube-api-auth，恢復的方法也很簡單，只需要編輯集群，將“授權集群訪問地址”修改成禁用，保存集群，然后再用相同的方法啟用 “授權集群訪問地址”即可，

1、編輯集群

2、禁用授權集群訪問地址，保存

3、再次編輯集群，啟用授權集群訪問地址，保存

恢復nginx-ingress-controller、canal、coredns、metrics-server組件

nginx-ingress-controller、canal、coredns、metrics-server 這些workload都是通過kube-system命名空間下的各種job來創建的，所以如果要重建這些workload只需要重新執行對應的job即可，

本例使用nginx-ingress-controller做演示，其他workload的恢復步驟可以參考此恢復方案，

模擬故障

從System Project下洗掉 kube-system 下的default-http-backend和nginx-ingress-controller

執行恢復

1. 從kube-system命名空間下洗掉rke-ingress-controller-deploy-job（如果不洗掉對應的job，更新集群后，不會重新觸發job重新執行）

2. 為了觸發集群更新，可以編輯集群，修改NodePort范圍，然后保存，

驗證

集群更新成功后，回到System Project下確認default-http-backend和nginx-ingress-controller已經重新創建，

如何恢復從Rancher UI或kubectl誤刪的節點

當節點處于“活動”狀態，從集群中洗掉節點將觸發一個行程來清理節點，如果沒有重啟服務器，并不會完成所有的清除所有非持久化資料，

如果無意中將節點洗掉，只需要使用相同的引數再次添加節點即可恢復集群，

比如我的環境有兩個節點，分別具有全部和Worker角色

從Rancher UI或kubectl將節點rancher2洗掉，此時集群中只剩下一個rancher3節點，由于集群中缺少Etcd和Control角色，所以集群提示：Waiting for etcd and controlplane nodes to be registered

接下來，編輯集群，并且設定相同的節點引數，這地方要注意，一定要設定和之前添加節點時相同的節點引數，

復制添加節點命令在rancher2的SSH終端運行，

過一會，再回到集群集群主機串列頁面，可以看到rancher2節點已經恢復

如何恢復執行過清理節點腳本的節點

中文官網提供了一個清理節點的腳本，這個腳本會清理節點上的容器、卷、rancher/kubernetes目錄、網路、行程、iptables等，

如果由于誤操作，在正確的節點上執行了清理腳本，針對這種場景，只有在rancher中創建過備份的集群才可以恢復，

創建集群備份參考中文官網：

https://rancher2.docs.rancher.cn/docs/cluster-admin/backing-up-etcd/_index

在我的環境中，demo集群有rancher2和rancher3兩個節點，

創建備份

在Rancher UI上創建集群快照，稍后恢復集群的時候會用的到，

然后導航到全域->demo->工具->備份查看已經創建的ETCD備份，從備份創建時間可以看出，剛才創建的備份名稱為c-v6mtr-ml-klt5n，

備份檔案存到了etcd（rancher2）節點對應的/opt/rke/etcd-snapshots目錄下，

清理節點

在rancher2節點執行中文官網節點清理腳本，清理理完之后，不出所料，集群崩了，

恢復集群

節點清理腳本并不會將/opt/rke目錄洗掉，只是使用mv /opt/rke /opt/rke-bak-$(date +"%Y%m%d%H%M")做了個備份，接下來可以將快照備份恢復到默認的/opt/rke目錄下，

mv /opt/rke-bak-202007060903 /opt/rke

接下來，編輯集群重新添加節點，這地方要注意，一定要設定和之前添加節點時相同的節點引數，

運?完命令之后，可以看到rancher agent已經正常作業起來了，

接下來，選擇之前的備份記錄，保存，開始恢復集群，

現在集群的狀態變成了Updating，已經開始使用之前創建的快照進行恢復集群了

稍等片刻，可以看到kubernetes組件全部運行起來，

集群狀態也變為了Active，此時，集群已經成功恢復

業務應用檢查

之前部署的名為nginx的nginx應?依舊存在，且運行正常，

如何恢復被洗掉的custom集群

在Rancher UI中誤刪自定義的集群，如果要恢復該集群，必須需要有Rancher local集群和自定義集群的備份才可以恢復，

備份集群

備份custom集群

參考 https://rancher2.docs.rancher.cn/docs/cluster-admin/backing-up-etcd/_index 備份custom集群，備份成功后，可以導航到集群->工具->備份查看備份，

備份local集群

參考 https://rancher2.docs.rancher.cn/docs/backups/_index 備份local集群，備份成功后，將在本地生成一個tar.gz檔案，

模擬故障

備份custom集群

參考 https://rancher2.docs.rancher.cn/docs/cluster-admin/backing-up-etcd/_index 備份custom集群，備份成功后，可以導航到集群->工具->備份查看備份，

備份local集群

備份local集群可參考：

https://rancher2.docs.rancher.cn/docs/backups/_index

備份成功后，將在本地生成一個tar.gz檔案，

模擬故障

接下來可以在Rancher UI上將集群洗掉來模擬故障，

恢復local集群

恢復local集群，可參考：

https://rancher2.docs.rancher.cn/docs/backups/restorations/_index

local恢復成功后，重新登錄Rancher UI，可以看到剛才被洗掉的custom集群又重新顯示了，但狀態是Unavailable

恢復custom集群

接下來，可以根據之前創建的custom集群快斬訓復custom集群，

恢復custom集群參考：

https://rancher2.docs.rancher.cn/docs/cluster-admin/restoring-etcd/_index

恢復后，集群狀態變為Updating，稍等片刻，可以看到集群狀態又變為Active，集群恢復成功，

總 結

從以上幾個場景的恢復操作可以看出，大部分的恢復方案都依賴于集群的備份，所以大家在生產環境中一定要做好定時備份，并且最好將備份檔案上傳到遠端備份服務器，這樣可以在災難情況下保護您的資料，

標籤：其他

上一篇：ServerlessDays China：無服務器的未來

下一篇：青云QingCloud與陜中二院聯手打造智慧醫院范本