节点notready本质是kubelet无法向控制平面正常上报健康状态，需按api层→kubelet→容器运行时→cni→系统资源逐层排查；先查kubectl describe node的conditions（如kubeletnotready）和events，再验kubelet服务、日志、证书、containerd、cni配置及磁盘/内存/inode等资源。
节点 NotReady 本质是 kubelet 无法向控制平面正常上报健康状态，不是单一故障，而是结果。核心思路是：先确认现象层级，再逐层向下排查——从 API 层反馈，到 kubelet 运行态，再到容器运行时、系统资源与内核支撑。
看 node describe 的 Conditions 和 Events
这是最快定位方向的入口：
-
Conditions 中 Ready=False 的 Reason 字段直接给出线索，比如
KubeletNotReady（kubelet 异常）、NetworkPluginNotReady（CNI 未就绪）、ContainerRuntimeNotReady（containerd 或 dockerd 不可用） - Events 区域最后几条记录常含关键提示，如 “NodeConditionChanged”、“Failed to update node status”、“failed to get node info” 等
- 注意 Taints 是否含
node.kubernetes.io/not-ready:NoExecute，这是自动打上的保护标记，不是原因而是结果
查 kubelet 服务与日志
kubelet 是节点健康的核心代理，90% 的 NotReady 源于它：
- 执行
systemctl status kubelet确认是否 active（running），若为 activating 或 failed，说明进程未正常启动 - 用
journalctl -u kubelet --no-pager -n 100查最近日志，重点搜索：
•x509: certificate has expired→ 执行kubeadm certs renew并重启 kubelet
•use of closed network connection→ 多见于 v1.18–v1.22，临时可重启 kubelet，长期建议升级到 v1.23+ - 检查 kubelet 进程是否卡住：
ps aux | grep kubelet，再看其打开文件数上限：cat /proc/$(pidof kubelet)/limits | grep "Max open files"，若接近硬限制（如 1048576），可能因 PLEG 轮询超载导致失联
验容器运行时与网络插件
kubelet 依赖底层运行时和 CNI 正常工作：
- 确认运行时服务状态：
systemctl status containerd（或docker），并查其日志：journalctl -u containerd --no-pager -n 50 - 用
crictl ps -a验证能否与运行时通信；若报错 “connection refused”，说明 socket 文件路径不对或服务未监听 - CNI 插件未就绪常见于新节点加入或网络配置变更后：
• 检查/etc/cni/net.d/下是否有有效配置文件（非空、格式正确）
• 查看 kubelet 日志中是否出现cni plugin not initialized或failed to load plugins
扫系统资源与内核状态
资源耗尽或内核异常会静默拖垮 kubelet：
- 磁盘空间：
df -h关注/、/var、/var/lib/containerd，特别是/var/log/journal可能被日志撑满 - 内存与负载：
free -h+uptime，若 Load Average > CPU 核数 × 3，且top显示大量 D 状态进程，可能是 I/O 卡死或内核 hang - 文件描述符与 inodes：
lsof | wc -l和df -i，inode 耗尽会导致新建文件失败，影响镜像拉取与 Pod 启动 - 检查内核日志：
dmesg -T | tail -30，留意 OOM killer 杀掉 kubelet、ext4 错误、硬件故障等硬性报错
不复杂但容易忽略
