K8S线上排查，实测排查Node节点NotReady异常状态

爱了！Alibaba内部出品“K8S+Docker攻略”，理论与实战左右开弓

两全其美！Alibaba架构师，纯手打Cloud+Boot微服务架构笔记

牛掰！“根底-中级-高档”Java程序员面试集结，看完献出我的膝盖

咱们好，本篇是关于在之前项目中，k8s线上集群中Node节点状况变成NotReady状况，导致整个Node节点中容器中止服务后的问题排查。

文章中所描绘的是自己在项目中线上环境实践处理的，那除了怎样处理该问题，更重要的是怎样去排查这个问题的原因。

关于Node节点不行用的NotReady状况，其时也是花了挺久的时刻去排查的。

在剖析NotReady状况之前，咱们首要须要了解在k8s中Pod的状况都有哪些。并且每个状况都表明什么含义，不同状况是很直观的显现出其时Pod所在的创立信息。

为了防止咱们对Node和Pod的概念混杂，先容易描绘下两者之间的联系（引证一张K8S官方图）。

从图中很直观的显现出最外面便是Node节点，而一个Node节点中是能够运转多个Pod容器，再深化一层便是每个Pod容器能够运转多个实例App容器。

因而关于本篇文章所论述的Node节点不行用，就会直接导致Node节点中一切的容器不行用。

毫无疑问，Node节点是否健康，直接影响该节点下一切的实例容器的健康状况，直至影响整个K8S集群。

那么怎样处理并排查Node节点的健康状况？不急，咱们先来聊聊关于关于Pod的生命周期状况。

Ping：该阶段表明现已被Kubernetes所承受，可是容器还没有被创立，正在被kube进行资源调度。

1：图中数字1是表明在被kube资源调度成功后，开端进行容器的创立，可是在这个阶段是会呈现容器创立失利的现象

Waiting或ContainerCreating：这两个原因就在于容器创立历程中镜像拉取失利，或许网络过错容器的状况就会产生改变。

Running：该阶段表明容器现已正常运转。

Failed：Pod中的容器是以非0状况（非正常）状况退出的。

2：阶段2或许呈现的状况为CrashLoopBackOff，表明容器正常发动可是存在反常退出。

Succeeded：Pod容器成功中止，并且不会再在重启。

上面的状况仅仅Pod生命周期中比较常见的状况，还有一些状况没有罗列出来。

这。。。状况有点多。歇息3秒钟

不过话又说回来，Pod的状况和Node状况是一回事吗？嗯。。。其实并不完全是一回事。

可是当容器服务不行用时，首要经过Pod的状况去排查是非常重要的。那么问题来了，假如Node节点服务不行用，Pod还能拜访吗？

答案是：不能。

因而排查Pod的健康状况的含义就在于，是什么原因会导致Node节点服务不行用，因而这是一项非常重要的排查目标。

因为自己的作业是和物联网相关的，暂时咱们假定4台服务器（假定不考虑服务器自身功能问题，假如是这个原因那最好是晋级服务器），其间一台做K8S-Master建立，别的3台机器做Worker作业节点。

每个worker便是一个Node节点，现在须要在Node节点上去发动镜像，一切正常Node便是ready状况。

可是过了一段时刻后，就成这样了

这便是咱们要说的Node节点变成NotReady状况。

这跑着跑着就变成NotReady了，啥是NotReady？

这都运转一段时刻了，你告诉我还没准备好？

好吧，那就看看为什么还没准备好。

再回到咱们前面提到问题，便是Node节点变成NotReady状况后，Pod容器是否还成正常运转。

图顶用红框标明的便是在节点edgenode上，此刻Pod状况现已显现为Terminating，表明Pod现已中止服务。

接下来咱们就剖析下Node节点为什么不行用。

（1）首要从服务器物理环境排查，运用指令df-m检查磁盘的运用状况

或许直接运用指令free检查

磁盘并没有溢出，也便是说物理空间满足。

（2）接着咱们再检查下CPU的运用率，指令为：top-c（大写P可倒序）

CPU的运用率也是在范围内，不管是在物理磁盘空间仍是CPU功能，都没有什么反常。那Node节点怎样就不行用了呢？并且服务器也是正常运转中。

这如同就有点为难了，这可咋整？

（3）不慌，还有一项能够作为排查的依据，那便是运用kube指令describe指令检查Node节点的详细日志。完好指令为：

kubectldescribenode节点称号，那么图中Node节点如图：

哎呀，如同在这个日志里边看到了一些信息描绘，首要咱们先看榜首句：Kubeletstopedpostingnodestatus，大致的意思是Kubelet中止发送node状况了，再接着Kubeletneverpostednodestatus意思为再也收不到node状况了。

剖析一下如同有点端倪了，Kubelet为什么要发送node节点的状况呢？这就抛出了关于Pod的另一个知识点，请耐性向下看。

依据咱们最终面剖析的景象，如同是node状况再也没有收到上报，导致node节点不行用，这就引申出关于Pod的生命健康周期。

PLEG全称为：PodLifecycleEventGenerator：Pod生命周期事情生成器。

容易了解便是依据Pod事情级别来调整容器运转时的状况，并将其写入Pod缓存中，来坚持Pod的最新状况。

在上述图中，看出是Kubelet在检测Pod的健康状况。Kubelet是每个节点上的一个看护进程，Kubelet会定时去检测Pod的健康信息，先看一张官方图。

PLEG去检测运转容器的状况，而kubelet是经过轮询机制去检测的。

剖析到这儿，如同有点方向了，导致Node节点变成NotReady状况是和Pod的健康状况检测有联系，正是因为超越默许时刻了，K8S集群将Node节点中止服务了。

那为什么会没有收到健康状况上报呢？咱们先检查下在K8S中默许检测的时刻是多少。

在集群服务器是上，进入目录：/etc/kubernetes/manifests/，检查参数：

–node-monitor-grace-period=40s（node驱赶时刻）–node-monitor-period=5s（轮询间隔时刻）

上面两项参数表明每隔5秒kubelet去检测Pod的健康状况，假如在40秒后仍然没有检测到Pod的健康状况便将其置为NotReady状况，5分钟后就将节点下一切的Pod进行驱赶。

官方文档中对Pod驱赶战略进行了容易的描绘，

kubelet轮询检测Pod的状况其实是一种很损耗功能的操作，特别跟着Pod容器的数量添加，对功能是一种严峻的损耗。

在GitHub上的一位小哥对此也表明有自己的观点，原文链接为：

到这儿咱们剖析的也差不多了，得到的定论为：

Pod数量的添加导致Kubelet轮询对服务器的压力增大，CPU资源严重

Kubelet轮询去检测Pod的状况，就必然受网络的影响

Node节点物理硬件资源约束，无法承载较多的容器

而因为自己其时硬件的约束，及网络环境较差的前提下，所以只改了上面了两项参数装备，延伸Kubelet去轮询检测Pod的健康状况。实践效果也的确得到了改进。

//须要重启dockersudosystemctlrestartdocker//须要重启kubeletsudosystemctlrestartkubelet

可是假如条件答应的状况下，个人主张最好是从硬件方面优化。

进步Node节点的物理资源

优化K8S网络环境

最终共享一些常用的K8S指令

kubectlgetpods-n

kubectlgetnodes

kubectldescribepod-n

kubectllogs-f-n

kubectlgetpod-n-oyaml

kubectlgetpod-lapp=-n

kubectl-ngetpods|grep|awk'{print$3}'

kubectldeletepod-n

kubectldeletedeployment-n

kubectldeletepod-n--force--grace-period=0

kubectlexec-it-n--sh

kubectllabelnodeapp=label

kubectlgetnode-l""

kubectlgetnode--show-labels=true

关于Node节点的NotReady状况其时也是排查了好久，对许多种状况也是猜想，并不能详细确认是什么原因。

网上关于这方面的内容也不是许多，只能是依据提示一步一步去排查问题的源头，并加以验证，最终也是在条件约束下处理了这个问题。