烂泥: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集群恢复过程详解

赞 (59) 打赏

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

支付宝扫一扫打赏

微信扫一扫打赏