记一次现场故障分析总结k8s节点NotReady题目

手机游戏开发者 · 2024-9-15 18:28:36

配景

某现场19年摆设一套k8s集群，docker版本1.12 ，k8s版本1.8.6，现网k8s资源池规模，生产环境58台物理机，灰环境60台虚机（厥后才知道用的一套k8s资源池，通过标签区分)，生产环境实例数2000左右，灰度环境实数900左右
征象

某现场在夜晚做业务升级的时间，批量更新业务包（由于微服务架构，而拆分并不完全，批量更新了十个中央的代码）同时启动副本为1的实例，再通过批量扩容的方式拉起2000左右的实例，出现现场大面积的k8s-node节点not Ready,以至于业务无法全部启动乐成。
故障定位流程

由于之前现场出现过此题目，并只是伴有几个node的notReady题目，现场并没有第一时间接洽我们，7点左右接洽到我，我们第一时间拉取专家团队进行故障分析定位，由于早上8点必要业务，以是我在熟悉现场环境的环境下，并隐隐知道这个题目与启动或扩容多个实例个数有关，再简朴看了非常的节点的kubelet 日记和docker日记，快速备份节点日记后。发起现场优先规复生产，发起先将业务应用的实例数先镌汰至1，保障全部业务都运行，再通过人工的方式，逐一对应用增长副本数。
一开始应该之前就曾有过这个环境（现场版本比力老，docker 1.12 k8s 1.8.6），以是将题目引向bug,但无法阐明此次出现大面积的瘫痪。node节点的event:

拿到kubelet 日记，体系日记和docker日记以后，发现日记有以下题目

按照网上修复发起，以为是systemd的版本题目导致，但查抄发现，现场的cgroup的版本还是用的cgroupfs 。
然后开始又开始翻找日记，同时在现场的测试过程中发现，容器在不利用端口映射的方式的环境下扩容并未引起节点的失联。现场采取的并不是NodePort的方式，而是hostPort方式并改动源代码可以大概随机在宿主机启动映射端口，也就是说每启动一个都会通过docker的方式生产iptables规则。一开始的方向以为大概代码题目，但运行了靠近3年，才出现属实说不外去。
真实缘故原由定位：
在docker 日记中查到，有进程相互锁住，但是没查出具体的什么缘故原由：
essage.txt:May 13 10:27:47 paas-10-239-40-157 dockerd: is currently holding the xtables lock; waiting (47s) for it to exit...\nAnother app is currently holding the xtables lock; waiting (49s) for it to exit...\nAnother app is currently holding the xtables lock; waiting (51s) for it to exit...\nAnother app is currently holding the xtables lock; waiting (53s) for it to exit...\nAnother app is currently holding the xtables lock; waiting (55s) for it to exit...\nAnother app is currently holding the xtables lock; waiting (57s) for it to exit...\n"然后我在远程连线现场服务器时，检察top的时间发现有个进程cpu进程100%

检察服务的父进程发现是kube-proxy，查抄kube-proxy的日记发现大量的进程互锁。

根本能判断由于改写了源码，容器在启动时必要映射端口由docker去修改iptables规则，
kube-proxy同时实行修改规则，导致互锁。由于互锁时间长，docker出现了过载或没有相应时间过长，导致kublet去接洽docker时接洽不上。从而node节点报ContainerGcFailed的题目

就此根源题目根本排查出来了。
但针对现场另有个题目也必要排查，就是该题目应该在一开始就存在，而且之前都是几台出现，这次出现忽然大面积的题目。docker发起端口映射时，采取的方式是docker -P的方式随机指定端口，它必要遍历iptables规则树获取可用端口，再写入，在iptables的规则多的环境下，这个时间耗时越来越长。大批量启动pod的时间就出现docker和kube-proxy的服务争抢iptables。其时查抄iptables的规则条目有3万多

总结

导致的缘故原由是，kube-proxy的革新战略时间是2小时，在业务进程全停全启动时，原来的iptables规则未失效，docker遍历时间长。同时，现场3月份做了一套灰度环境，但为了节流资源，采取的是同一套k8s资源池，灰度环境的服务也启动了700多个pod，导致iptables到达瓶颈。以是再同时启动多pod的环境下，docker占用的时间延伸，导致kubelet通讯不到，才节点出现NotReady。这也表明白服务启动完成后就不会再出现这类环境。
发起

1.将灰度环境单独一套k8s资源池处理惩罚，办理当前iptables过大的的题目2.应用匀称分布，在中央之间无相互影响的环境下，发起不打标签，使批量启动pod的时间不会只落在某几台上，导致docker寻址时间加长，从而kublet接洽超时，而NotReady3.拆分资源池，镌汰资源池内的pod运行数目。4.取消采取该种端口映射的方式，可采取NodePort的方式，但必要修改和拆分应用设置。5.不采取端口映射，通过ingress寻址，但会影响微服务的优雅停机和负载战略。跋文

从现场看，已经开始实行新版本的建设，如今实在简朴的方式，就是拆灰度环境为单独k8s集群，然后现网增长node节点，既可以大概保障当前的业务承载量也可以大概镌汰该故障的发生。
对了，为啥要用端口映射，实在就是由于容器上云的相互之间的调用不全部在容器内，也有在表面的。然后采取NodePort的方式，一个应用一台宿主机起一个pod，10台宿主机只能是10个。假如还要多，那只能复制多个应用出来，好比应用01、应用02，实在也不影响利用，影响体系的分类和拓扑。也就是我第四条提到的方法

记一次现场故障分析总结k8s节点NotReady题目

所属分类: 问答交流

新帖推荐: 30日

推荐作品