NotReady表示控制平面40秒内未收到节点健康报告，需按五步排查：一查kubelet服务状态及日志；二测kubelet与APIServer网络连通性；三验CNI插件配置与二进制；四核br_netfilter模块、NTP时间同步及系统挂载状态；五析kubectl describe node中的Conditions与Events。

当Kubernetes节点状态显示NotReady时，该现象本身不直接指明是kubelet进程崩溃还是网络中断，而是表明控制平面在40秒（默认心跳超时）内未收到节点健康报告。以下是定位根本原因的多种独立排查路径：

一、验证kubelet服务运行状态

此步骤用于确认节点“大脑”是否仍在工作。若kubelet未运行或启动失败，节点将无法上报任何状态，直接导致NotReady。

1、执行systemctl status kubelet命令，检查服务当前状态是否为active (running)。

2、若状态为inactive或failed，使用journalctl -u kubelet -n 50 --since "10 minutes ago"查看最近日志，重点关注panic、certificate expired、failed to load config等关键词。

3、若发现证书过期错误，需重新生成kubelet证书并重启服务，不可仅重启kubelet进程。

4、若日志中出现"failed to run Kubelet: unable to load bootstrap kubeconfig"，说明bootstrap配置丢失或路径错误，应检查/etc/kubernetes/bootstrap-kubelet.conf是否存在且权限正确。

二、测试kubelet与APIServer的网络连通性

此步骤用于排除网络层阻断——即使kubelet正常运行，若其无法连接APIServer，仍会触发NotReady。关键端口为Master节点的6443（APIServer）和Node节点的10250（kubelet HTTPS端口）。

1、在Master节点上执行：nc -zv 问题节点IP 10250，验证kubelet监听端口是否可达。

2、在问题节点上执行：curl -k https://Master节点IP:6443/healthz，检查是否返回ok；若报SSL错误或connection refused，说明TLS信任链或网络策略异常。

3、若使用telnet替代nc，命令为：telnet 问题节点IP 10250，观察是否成功建立TCP连接。

4、若连通性失败，立即检查节点主机防火墙（firewalld/iptables）、云平台安全组、VMware NAT模式下端口转发规则。

三、检查CNI网络插件就绪状态

此步骤聚焦于kubelet内部健康判断逻辑。kubelet在启动后会等待CNI插件完成初始化，若超时未就绪，则主动将NodeCondition中的NetworkUnavailable置为True，并影响Ready整体状态。

1、执行ls -l /etc/cni/net.d/，确认存在非空的.conf或.conflist文件，如10-flannel.conflist。

2、若目录为空或仅有backup文件，说明CNI配置未正确分发至该节点，需手动复制或触发配置同步。

3、执行journalctl -u kubelet --no-pager | grep -i "networkpluginnotready\|cni config uninitialized"，捕获CNI初始化失败线索。

4、若日志中反复出现"failed to find plugin \"bridge\" in path [/opt/cni/bin]"，表示CNI二进制缺失，需检查/opt/cni/bin目录下是否有flannel、calico等对应插件文件。

四、核验系统级依赖模块与时间同步

此步骤识别常被忽略的底层支撑条件。br_netfilter内核模块缺失或系统时间偏差超过90秒，均会导致kubelet启动后无法通过TLS握手或CNI初始化校验，从而静默失败。

1、执行lsmod | grep br_netfilter，若无输出，需运行modprobe br_netfilter并写入/etc/modules持久化加载。

2、执行date命令，对比Master节点与问题节点的时间差；若偏差超过90秒，必须配置NTP服务并执行ntpd -gq强制校准，否则所有TLS通信将被拒绝。

3、检查sysctl net.bridge.bridge-nf-call-iptables值是否为1，若为0，执行sysctl -w net.bridge.bridge-nf-call-iptables=1并写入/etc/sysctl.conf。

4、运行mount | grep " / "，确认根文件系统未处于read-only状态；若显示ro，说明磁盘错误触发只读挂载，需先修复文件系统再重启kubelet。

五、分析节点Conditions与Events深层信息

此步骤利用Kubernetes原生诊断接口提取结构化线索，避免主观猜测。kubectl describe node输出中的Conditions字段是kubelet自检结果的权威映射，Events则记录集群控制器对节点异常的响应行为。

1、执行kubectl describe node 问题节点名称，定位Conditions区块末尾的Ready行，记录其type、status、reason与message字段。

2、若reason为KubeletNotReady且message含"PLEG is not healthy"，表明Pod生命周期事件监测器停滞，通常由容器运行时响应延迟或OOM引起。

3、若Conditions中NetworkUnavailable为True，但CNI配置检查无误，需进一步检查/run/flannel/subnet.env或/calico/node/config等运行时网络状态文件是否存在且内容有效。

4、滚动查看Events部分，寻找连续出现的NodeNotReady事件；若事件间隔恰好为40秒，高度提示kubelet心跳包未送达APIServer，应优先复核网络连通性与证书时效性。