k8s 节点的NotReady是什么导致的？NotReady会导致什么问题？ https://komodor.com/learning-center/
k8s节点NotReady 导致的原因有多种
可以用 kubectl describe node <节点名称> 查看node节点信息。
1. kubelet 资源没有做单独预留导致，kubelet 不可用。
哎呀，好像在这个日志里面看到了一些信息描述，首先我们先看第一句：Kubelet stoped posting node status，大致的意思是 Kubelet 停止发送 node 状态了，再接着Kubelet never posted node status意思为再也收不到 node 状态了。
查看下 Kubelet 是否在正常运行，是使用命令：
systemctl status kubelet，如果状态为 Failed，那么是需要重启下的。但如果是正常运行，请继续向下看
根据我们最后面分析的情形，似乎是 node 状态再也没有收到上报，导致 node 节点不可用，这就引申出关于 Pod 的生命健康周期。
PLEG全称为：Pod Lifecycle Event Generator：Pod 生命周期事件生成器。
简单理解就是根据 Pod 事件级别来调整容器运行时的状态，并将其写入 Pod 缓存中，来保持 Pod 的最新状态。
在上述图中，看出是 Kubelet 在检测 Pod 的健康状态。Kubelet 是每个节点上的一个守护进程，Kubelet 会定期去检测 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 的健康状态。实际效果也确实得到了改善。
为什么它会阻止节点运行 Pod
节点必须有足够的磁盘空间、内存和处理能力来运行 Kubernetes 工作负载。
如果节点上的非 Kubernetes 进程占用资源过多，或者节点上运行的进程过多，控制平面可以将其标记为NotReady.
如何诊断
运行kubectl describe node并查看条件部分以查看节点上是否缺少资源：
内存压力——节点内存不足。
磁盘压力—node 磁盘空间不足。
PID压力—node 运行的进程太多。
kubelet 问题
为什么它会阻止节点运行 Pod
kubelet 必须在每个节点上运行才能使其参与集群。如果 kubelet 在某个节点上崩溃或停止，它将无法与 API 服务器通信，并且该节点会进入未就绪状态。
如何诊断
运行kubectl describe node [name]并查看条件部分——如果所有条件都未知，则表明 kubelet 已关闭。
kube-proxy 问题
为什么它会阻止节点运行 Pod
kube-proxy 在每个节点上运行，负责调节节点与集群内外其他实体之间的网络流量。如果 kube-proxy 因任何原因停止运行，节点将进入未就绪状态。
如何诊断
运行kubectl get pods -n kube-system以显示属于 Kubernetes 系统的 pod。
连接问题
为什么它会阻止节点运行 Pod
即使一个节点配置完美，但它没有网络连接，Kubernetes 也会将该节点视为未就绪。这可能是由于网络电缆断开、无法访问 Internet 或机器上的网络配置错误。
如何诊断
运行kubectl describe node [name]并查看条件部分 - 如果NetworkUnavailable标志为True，则表示节点存在连接问题。
解决节点未就绪问题
解决系统资源不足的问题
以下是解决节点上系统资源问题的几种方法：
- 确定节点上正在运行哪些非 Kubernetes 进程。如果有，请关闭它们或将它们减少到最低限度以节省资源。
- 运行恶意软件扫描——可能存在占用系统资源的隐藏恶意进程。
- 升级节点。
- 检查硬件问题或配置错误并解决它们。
解决 kubelet 问题
要解决 kubelet 问题，请通过 SSH 进入节点并运行命令 systemctl status kubelet
查看 Active 字段的值：
active (running)表示 kubelet 实际可以运行，在别处寻找问题。active (exited)表示 kubelet 已退出，可能是错误的。重新启动它。>inactive (dead)表示 kubelet 崩溃了。要确定原因，请运行命令journalctl -u kubelet并检查 kubelet 日志。
解决 kube-proxy 问题
尝试查看以下位置以确定 kube-proxy 的问题：
- 使用失败的 kube-proxy pod 的名称运行命令
kubectl describe pod，并检查输出中的 Events 部分。 - 运行命令
kubectl logs [pod-name] -n kube-system以查看失败的 kube-proxy pod 的完整日志。 - 运行命令
kubectl describe daemonset kube-proxy -n kube-system查看 kube-proxy 守护进程的状态，该守护进程负责确保在每个 Kubernetes 节点上运行 kube-proxy。
请注意，这些过程可以帮助您收集有关问题的更多信息，但可能需要其他步骤来解决问题。如果上述快速修复之一不起作用，您将需要进行更复杂的非线性诊断过程，以确定 Kubernetes 环境的哪些部分导致节点未就绪问题并解决它。
https://komodor.com/learning-center/
