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

本文來自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，集群恢復成功。

總 結

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