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

33次阅读

共计 5567 个字符,预计需要花费 14 分钟才能阅读完成。

本文来自 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-agentcattle-node-agent

模仿故障

从 System Project 下删除 cattle-cluster-agentcattle-node-agent

生成 Kubeconfig 和集群 yaml

1. 在 Rancher UI 上创立 API token(用户 -> API & Keys)并保留Bearer Token

2. 抉择集群后,在 Rancher UI(格局为 c -xxxxx)中找到其 clusterid,并在地址栏中找到它。

3. 依据步骤 1 - 2 获取的变量替换:RANCHERURLCLUSTERIDTOKEN(主机须要装置 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-agentcattle-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-agentcattle-node-agent 曾经复原。

复原kube-api-auth

默认状况下,RKE 集群会默认启用受权集群端点。这个端点容许您应用 kubectl CLI 和 kubeconfig 文件拜访上游的 Kubernetes 集群,RKE 集群默认启用了该端点。

如果误删 kube-api-auth,复原的办法也很简略,只须要编辑集群,将“受权集群拜访地址”批改成 禁用 ,保留集群。而后再用雷同的办法 启用“受权集群拜访地址”即可。

1、编辑集群

2、禁用受权集群拜访地址,保留

3、再次编辑集群,启用受权集群拜访地址,保留

复原 nginx-ingress-controllercanalcorednsmetrics-server 组件

nginx-ingress-controllercanalcorednsmetrics-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-backendnginx-ingress-controller曾经从新创立。

如何复原从 Rancher UI 或 kubectl 误删的节点

当节点处于“流动”状态,从集群中删除节点将触发一个过程来清理节点。如果没有重启服务器,并不会实现所有的革除所有非长久化数据。

如果无心中将节点删除,只须要应用雷同的参数再次增加节点即可复原集群。

比方我的环境有两个节点,别离具备 全副 Worker角色

从 Rancher UI 或 kubectl 将节点 rancher2 删除,此时集群中只剩下一个 rancher3 节点,因为集群中短少 EtcdControl角色,所以集群提醒:Waiting for etcd and controlplane nodes to be registered

接下来,编辑集群,并且设置雷同的节点参数,这中央要留神,肯定要设置和之前增加节点时雷同的节点参数。

复制增加节点命令在 rancher2 的 SSH 终端运行。

过一会,再回到集群集群主机列表页面,能够看到 rancher2 节点曾经复原

如何复原执行过清理节点脚本的节点

中武官网提供了一个清理节点的脚本,这个脚本会清理节点上的容器、卷、rancher/kubernetes 目录、网络、过程、iptables 等。

如果因为误操作,在正确的节点上执行了清理脚本。针对这种场景,只有在 rancher 中创立过备份的集群才能够复原。

创立集群备份参考中武官网:

https://rancher2.docs.rancher…

在我的环境中,demo集群有 rancher2rancher3两个节点。

创立备份

在 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… 备份 custom 集群,备份胜利后,能够导航到集群 -> 工具 -> 备份查看备份。

备份 local 集群

参考 https://rancher2.docs.rancher… 备份 local 集群,备份胜利后,将在本地生成一个 tar.gz 文件。

模仿故障

备份 custom 集群

参考 https://rancher2.docs.rancher… 备份 custom 集群,备份胜利后,能够导航到集群 -> 工具 -> 备份查看备份。

备份 local 集群

备份 local 集群可参考:

https://rancher2.docs.rancher…

备份胜利后,将在本地生成一个 tar.gz 文件。

模仿故障

接下来能够在 Rancher UI 上将集群删除来模仿故障。

复原 local 集群

复原 local 集群,可参考:

https://rancher2.docs.rancher…

local 复原胜利后,从新登录 Rancher UI,能够看到方才被删除的 custom 集群又从新显示了,但状态是Unavailable

复原 custom 集群

接下来,能够依据之前创立的 custom 集群快照复原 custom 集群。

复原 custom 集群参考:

https://rancher2.docs.rancher…

复原后,集群状态变为Updating,稍等片刻,能够看到集群状态又变为Active,集群复原胜利。

总 结

从以上几个场景的复原操作能够看出,大部分的复原计划都依赖于集群的备份,所以大家在生产环境中肯定要做好定时备份,并且最好将备份文件上传到远端备份服务器,这样能够在劫难状况下爱护您的数据。

正文完
 0