烂泥：k8s集群恢复过程详解

本文由ilanniweb微信公众号提供友情赞助，首发于烂泥行天下

jenkins技术分享QQ群：571981257

本篇文章没有任何截图，只记录k8s集群在恢复过程中的思路和具体操作步骤，而且这些思路和操作不一定都是对的。

分享出来的目的，就是为了后续如有小伙伴在k8s实际的使用过程遇到类似的情况，提供一个思路和参考方向。

下面我会以时间为节点，分享k8s集群挂掉的起因，以及处理过程。

时间：20200505 上午

起因：

通过zstack的web管理界面(192.192.123.249:5000)批量创建vm，其中一个vm的IP地址分配为192.192.123.249，导致zstack的web管理界面无法连接。

处理方式：

在192.192.123.0/24网段下的windows机器登陆192.192.123.249:5000，删除分配IP地址为192.192.123.249的vm，同时需要在防火墙上清除192.192.123.249绑定的MAC地址。

引申：

为了后续不再出现新建的vm被分配192.192.123.249的IP地址情况，在zstack的web管理界面192.192.123.249:5000，删除zstack预留的IP地址段(192.192.123.231-192.192.123.250)，使其预留的IP地址段不包含192.192.123.249这个IP地址。

就是因为上述删除zstack的预留的IP地址段，导致k8s集群的master(etcd)节点、nfs存储服务器以及部分node节点的vm的网卡被删除，由此引起整个开发测试环境的k8s集群挂掉。

集群挂掉表现现象为：

1.kubectl命令提示无法连接到k8s的api-server服务器

2.日志中A pod提示无法连接另外的B pod

3.jenkins salve pod无法生成

注意：k8s容器的master(etcd)的IP地址分别为192.192.123.231(master)、192.192.123.232(master+etcd)、192.192.123.233(master+etcd)、192.192.123.230(etcd)

k8s集群恢复处理过程：

1.首先恢复3个master节点、nfs存储服务器和其他node节点的网卡，并为其分配对应的IP地址

2.逐个重启master节点、nfs存储服务器

3.master重启完毕后，发现3个etcd节点，其中2个是有问题的，192.192.123.230(etcd)正常，另外两个etcd节点经过多次删除、添加etcd节点，发现问题依旧

4.使用etcd的相关命令查看etcd的节点，发下3个etcd节点都是不健康状态，由此可以判断该etcd集群已经损坏

5.经过步骤4后，大致可以判断etcd集群损坏，那就只能通过etcd的备份数据，恢复etcd节点数据，其中备份数据使用192.192.123.232(master+etcd)的备份数据(半个月之前的备份)

6.etcd节点正常后，发现4个master节点中的两个是有问题的192.192.123.231(master)、192.192.123.232(master+etcd)

7.删除192.192.123.231(master)、192.192.123.232(master)，发现90%的node节点显示为NotReady状态，然后逐个重启状态为NotReady的node节点，最后node节点显示Ready状态(出现这个现象，怀疑是由于node节点的IPtables规则，在etcd恢复备份术后，出现大批量更新导致)

8.集群的master(2个节点)和etcd(2个节点)恢复正常服务后，把192.192.123.231(master+etcd)、192.192.123.232(master+etcd)加入集群，然后删除192.192.123.230(etcd)

9.集群恢复正常后，部分应用出现无法访问redis、mongodb、mysql等中间件服务的现象，把未重启的node节点全部重启一遍，应用连接中间件恢复正常

10.集群恢复正常后，部分应用出现无法解析其他应用svc-name的情况，重启coredns的pod，恢复正常

11.集群恢复正常后，部分应用出现前端域名无法访问的情况，重启ingress的pod，恢复正常

12.测试少量应用发布正常，然后通知钉钉k8s集群恢复正常

时间：20200506 上午

问题：

1.开发测试人员反馈部分应用无法访问

2.jenkins无法发布新应用

3.k8s集群被删除的pod，无法生成新的pod

4.dev5环境的apollo pod被删除后，新的pod没有生成

处理过程：

1.根据上述表现现象初步怀疑是etcd有问题导致新的pod无法生成，随使用etcd命令检查etcd集群状态，以及节点健康情况，发现都是正常的

2.etcd集群和节点都是正常的，那就很可能是openkruise引起的（openkruise是阿里云开源的一个crd，可以支持pod的原地升级，减少pod的创建时间等）

3.因为怀疑是openkruise导致，所以首先选择的是重启openkruise的deployment，重启之后发现问题依旧

4.因为重启openkriuse的deployment无效，那就使用k8s集群原生的deployment进行部署。于是删除openkruise，删除之后，发现jenkins无法生成新的slave pod节点以及被删除的pod也无法生成新的pod

5.etcd正常，但是pod还是无法生成，所以最终还是怀疑openkriuse导致，于是重新安装openkruise，但是只是启用了openkriuse的cloneset功能，上述问题消失(怀疑是20200825恢复的etcd数据中，有关openkruise使用原来的脏数据导致)

反思：

1.后续所有的操作只要牵涉k8s集群的master和etcd节点，必须先进行备份

2.对于任何的k8s集群，必须熟悉其部署架构和高可用架构，而且必须对其做灾难的恢复测试

3.有关etcd方面的知识要加强

4.对于openkriuse的研究要更深入

5.k8s集群备份策略调整

6.对于zstack的任何网络操作，必须慎重慎重再慎重

未经允许不得转载：烂泥行天下 » 烂泥：k8s集群恢复过程详解