Kubernetes 节点 NotReady：从 Kubelet、网络到资源压力的排查清单

节点 NotReady 会导致 Pod 驱逐、流量下降和调度失败。先判断是单节点故障还是控制面、网络或基础设施的整体问题，再决定排障、隔离或替换节点。

一、从控制面观察

kubectl get nodes -o wide
kubectl describe node <NODE>
kubectl get events --all-namespaces --sort-by=.lastTimestamp | tail -100

重点查看 Ready 条件、最后心跳时间、MemoryPressure、DiskPressure、PIDPressure、NetworkUnavailable 和污点。若节点失联，不要立即重启，先确认承载的业务和可用副本。

二、检查节点基础状态

通过控制台进入节点：

uptime
free -h
df -hT
df -i
systemctl status kubelet containerd
journalctl -u kubelet --since '-30 minutes'

常见原因包括磁盘或 inode 满、内存不足、进程数耗尽、时间漂移、证书问题以及 Kubelet 或容器运行时异常。

三、检查控制面通信

nc -vz <APISERVER> 6443
curl -k https://<APISERVER>:6443/livez

检查节点到 API Server 的路由、防火墙、DNS、代理和证书。若大量节点同时 NotReady，应优先检查控制面、负载均衡和网络，而不是逐台重启节点。

四、检查容器运行时与 CNI

crictl info
crictl ps -a
systemctl status containerd
kubectl -n kube-system get pod -o wide

检查 containerd socket、镜像文件系统、CNI 配置、网络插件 DaemonSet 和节点网卡。运行时异常可能导致 Pod 管理失败，CNI 异常则常伴随 NetworkUnavailable。

五、安全处置

确认集群容量足够后可先执行：

kubectl cordon <NODE>
kubectl drain <NODE> --ignore-daemonsets --delete-emptydir-data

drain 会影响业务和本地数据，必须检查 PDB、副本数和有状态服务。修复完成后验证 Kubelet、网络和关键 DaemonSet，再 uncordon。

六、长期治理

监控节点心跳、Kubelet、运行时、磁盘、inode、证书、时间同步和 CNI；为节点故障准备容量冗余和自动替换；定期进行节点下线演练，验证 PDB 和调度策略。

总结

NotReady 排查遵循“条件与事件—节点资源—Kubelet—运行时—网络—控制面”的顺序。隔离节点前确认业务影响，恢复后也要验证 Pod 网络和实际流量，而不只是看 Ready 变绿。