误删节点或集群怎么办？这里有一颗后悔药

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

总 结

从以上几个场景的恢复操做能够看出，大部分的恢复方案都依赖于集群的备份，因此你们在生产环境中必定要作好定时备份，而且最好将备份文件上传到远端备份服务器，这样能够在灾难状况下保护您的数据。