共计 4141 个字符，预计需要花费 11 分钟才能阅读完成。
今天就跟大家聊聊有关 K8S 线上集群怎样排查 Node 节点 NotReady 异常状态，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
一，文章简述
k8s 线上集群中 Node 节点状态变成 NotReady 状态，导致整个 Node 节点中容器停止服务后的问题排查。
文章中所描述的是本人在项目中线上环境实际解决的，那除了如何解决该问题，更重要的是如何去排查这个问题的起因。
关于 Node 节点不可用的 NotReady 状态，当时也是花了挺久的时间去排查的。
二，Pod 状态
在分析 NotReady 状态之前，我们首先需要了解在 k8s 中 Pod 的状态都有哪些。并且每个状态都表示什么含义，不同状态是很直观的显示出当前 Pod 所处的创建信息。
为了避免大家对 Node 和 Pod 的概念混淆，先简单描述下两者之间的关系（引用一张 K8S 官方图）。
从图中很直观的显示出最外面就是 Node 节点，而一个 Node 节点中是可以运行多个 Pod 容器，再深入一层就是每个 Pod 容器可以运行多个实例 App 容器。
因此关于本篇文章所阐述的 Node 节点不可用，就会直接导致 Node 节点中所有的容器不可用。
毫无疑问，Node 节点是否健康，直接影响该节点下所有的实例容器的健康状态，直至影响整个 K8S 集群。
那么如何解决并排查 Node 节点的健康状态？不急，我们先来聊聊关于关于 Pod 的生命周期状态。
Pending：该阶段表示已经被 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？
这都运行一段时间了，你告诉我还没准备好？
好吧，那就看看为什么还没准备好。
4.1 问题分析
再回到我们前面说到问题，就是 Node 节点变成 NotReady 状态后，Pod 容器是否还成正常运行。
图中用红框标示的就是在节点 edgenode 上，此时 Pod 状态已经显示为 Terminating，表示 Pod 已经终止服务。
接下来我们就分析下 Node 节点为什么不可用。
（1）首先从服务器物理环境排查，使用命令 df - m 查看磁盘的使用情况
或者直接使用命令 free 查看
磁盘并没有溢出，也就是说物理空间足够。
（2）接着我们再查看下 CPU 的使用率，命令为：top -c（大写 P 可倒序）
CPU 的使用率也是在范围内，不管是在物理磁盘空间还是 CPU 性能，都没有什么异常。那 Node 节点怎么就不可用了呢？而且服务器也是正常运行中。
这似乎就有点为难了，这可咋整？
（3）不慌，还有一项可以作为排查的依据，那就是使用 kube 命令 describe 命令查看 Node 节点的详细日志。完整命令为：
kubectl describe node 节点名称，那么图中 Node 节点如图：
哎呀，好像在这个日志里面看到了一些信息描述，首先我们先看第一句：Kubelet stoped posting node status，大致的意思是 Kubelet 停止发送 node 状态了，再接着 Kubelet never posted node status 意思为再也收不到 node 状态了。
查看下 Kubelet 是否在正常运行，是使用命令：systemctl status kubelet，如果状态为 Failed，那么是需要重启下的。但如果是正常运行，请继续向下看。
分析一下好像有点眉目了，Kubelet 为什么要发送 node 节点的状态呢？这就抛出了关于 Pod 的另一个知识点，请耐心向下看。
五，Pod 健康检测 PLEG
根据我们最后面分析的情形，似乎是 node 状态再也没有收到上报，导致 node 节点不可用，这就引申出关于 Pod 的生命健康周期。
PLEG 全称为：Pod Lifecycle Event Generator：Pod 生命周期事件生成器。
简单理解就是根据 Pod 事件级别来调整容器运行时的状态，并将其写入 Pod 缓存中，来保持 Pod 的最新状态。
在上述图中，看出是 Kubelet 在检测 Pod 的健康状态。Kubelet 是每个节点上的一个守护进程，Kubelet 会定期去检测 Pod 的健康信息，先看一张官方图。
PLEG 去检测运行容器的状态，而 kubelet 是通过轮询机制去检测的。
分析到这里，似乎有点方向了，导致 Node 节点变成 NotReady 状态是和 Pod 的健康状态检测有关系，正是因为超过默认时间了，K8S 集群将 Node 节点停止服务了。
那为什么会没有收到健康状态上报呢？我们先查看下在 K8S 中默认检测的时间是多少。
在集群服务器是上，进入目录：/etc/kubernetes/manifests/kube-controller-manager.yaml，查看参数：
–node-monitor-grace-period=40s（node 驱逐时间）–node-monitor-period=5s（轮询间隔时间）
上面两项参数表示每隔 5 秒 kubelet 去检测 Pod 的健康状态，如果在 40 秒后依然没有检测到 Pod 的健康状态便将其置为 NotReady 状态，5 分钟后就将节点下所有的 Pod 进行驱逐。
官方文档中对 Pod 驱逐策略进行了简单的描述，https://kubernetes.io/zh/docs/concepts/scheduling-eviction/eviction-policy/
kubelet 轮询检测 Pod 的状态其实是一种很消耗性能的操作，尤其随着 Pod 容器的数量增加，对性能是一种严重的消耗。
在 GitHub 上的一位小哥对此也表示有自己的看法，原文链接为：
https://github.com/fabric8io/kansible/blob/master/vendor/k8s.io/kubernetes/docs/proposals/pod-lifecycle-event-generator.md
到这里我们分析的也差不多了，得到的结论为：
Pod 数量的增加导致 Kubelet 轮询对服务器的压力增大，CPU 资源紧张
Kubelet 轮询去检测 Pod 的状态，就势必受网络的影响
Node 节点物理硬件资源限制，无法承载较多的容器
而由于本人当时硬件的限制，及网络环境较差的前提下，所以只改了上面了两项参数配置，延长 Kubelet 去轮询检测 Pod 的健康状态。实际效果也确实得到了改善。
// 需要重启 docker
sudo systemctl restart docker
// 需要重启 kubelet
sudo systemctl restart kubelet
但是如果条件允许的情况下，个人建议最好是从硬件方面优化。
提高 Node 节点的物理资源
优化 K8S 网络环境
六，K8S 常用命令
最后分享一些常用的 K8S 命令
1，查询全部 pod（命名空间）
kubectl get pods -n namespaces
2，查询全部 node 节点
kubectl get nodes
3，查看 pod 详细信息和日志
kubectl describe pod podname -n namespaces
kubectl logs -f podname -n namespaces
4，查看 pod-yaml 文件
kubectl get pod podname -n namespaces -o yaml
5，通过标签查询 pod
kubectl get pod -l app= labelname -n namespaces
6，查询 pod 具体某一条信息
kubectl -n namespaces get pods|grep podname |awk {print $3}
7，删除 pod（或通过标签 -l app=）
kubectl delete pod podname -n namespaces
8，删除 deployment
kubectl delete deployment deploymentname -n namespaces
9，强制删除 pod
kubectl delete pod podname -n namespaces –force –grace-period=0
10，进入 pod 容器
kubectl exec -it podname -n namespaces — sh
11，给 node 打标签
kubectl label node nodename app=label
12，查看某一个 node 标签
kubectl get node -l labelname
13，查看全部 node 标签
kubectl get node –show-labels=true
看完上述内容，你们对 K8S 线上集群怎样排查 Node 节点 NotReady 异常状态有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。
