誤刪節點或集羣怎麼辦？這裏有一顆後悔藥

本文來自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

一、在具備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

二、應用更新

將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，恢復的方法也很簡單，只須要編輯集羣，將「受權集羣訪問地址」修改爲禁用，保存集羣。而後再用相同的方法啓用 「受權集羣訪問地址」便可。

一、編輯集羣

二、禁用受權集羣訪問地址，保存

三、再次編輯集羣，啓用受權集羣訪問地址，保存

恢復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，集羣恢復成功。

總 結

從以上幾個場景的恢復操做能夠看出，大部分的恢復方案都依賴於集羣的備份，因此你們在生產環境中必定要作好定時備份，而且最好將備份文件上傳到遠端備份服務器，這樣能夠在災難狀況下保護您的數據。