Kubernetes节点NotReady全链路排查指南：从存储异常到网络插件故障
当你发现Kubernetes集群中的节点突然变成NotReady状态时，那种感觉就像在高速公路上突然爆胎——系统还在运转，但关键功能已经瘫痪。作为经历过数十次类似故障的老兵，我深知这种时刻需要的是系统化的排查思路，而非盲目尝试。本文将带你建立一套完整的诊断框架，覆盖从存储容量异常到网络插件故障的完整排查路径。
1. 节点NotReady的故障图谱：从表象到根源
节点NotReady从来不是单一问题，而是系统发出的求救信号。根据多年运维经验，90%的NotReady状态可归为以下四类：
- 存储子系统异常：包括
invalid capacity 0 on image filesystem等磁盘容量问题 - 网络插件故障：CNI插件未初始化或配置错误
- 容器运行时崩溃：containerd/docker服务异常
- 资源耗尽：CPU、内存或PID等关键资源触顶
诊断黄金法则：永远从kubelet日志开始。执行以下命令获取实时日志：
journalctl -u kubelet --since "10 minutes ago" | grep -i error典型错误日志与对应故障类型的映射关系：
| 错误特征 | 可能原因 | 紧急程度 |
|---|---|---|
invalid capacity 0 | 镜像存储挂载异常 | 高 |
NetworkPluginNotReady | CNI插件配置问题 | 高 |
Container runtime not ready | containerd/docker服务异常 | 紧急 |
PLEG is not healthy | 节点资源不足 | 中 |
2. 存储容量类故障深度解析
当看到invalid capacity 0 on image filesystem这类报错时，背后的故事往往比表面更复杂。最近在处理某金融客户的生产环境时，就遇到了这个经典问题——表面看是存储异常，实际却是多重因素叠加。
2.1 存储异常的三层诊断法
第一层：基础检查
df -h /var/lib/kubelet lsblk -f mount | grep kubelet重点关注：
- 挂载点是否存在
- 文件系统是否正常
- 磁盘空间是否耗尽
第二层：kubelet配置验证检查/var/lib/kubelet/config.yaml中的关键参数：
imageGCHighThresholdPercent: 85 imageGCLowThresholdPercent: 80第三层：内核事件审计
dmesg | grep -i error cat /var/log/messages | grep storage2.2 典型场景解决方案
案例1：LVM卷组扩容后未刷新
pvresize /dev/sdb1 lvextend -r -l +100%FREE /dev/mapper/vg_kubelet-lv_data案例2：XFS文件系统损坏
xfs_repair /dev/sdc1 mount -o remount,rw /var/lib/kubelet关键提示：存储问题修复后必须重启kubelet服务才能重新注册容量信息
3. 网络插件故障的精准打击
"Network plugin returns error: cni plugin not initialized"这条报错信息背后，可能隐藏着从配置错误到版本不兼容的各种问题。上个月某电商大促期间，我们就因CNI插件版本冲突导致整个集群网络瘫痪。
3.1 网络诊断四步法
- 插件状态检查
ls /etc/cni/net.d/ ps aux | grep cni- IP分配情况
ip addr show ip route list- 插件日志分析
journalctl -u kubelet | grep -A 10 cni- 连通性测试
nsenter -t $(pgrep -o kubelet) -n ping 8.8.8.83.2 常见修复方案对比
| 故障类型 | 检测方法 | 修复方案 | 风险等级 |
|---|---|---|---|
| 配置文件缺失 | ls /etc/cni/net.d/ | 重新部署CNI插件 | 中 |
| 二进制权限问题 | ls -l /opt/cni/bin/ | chmod +x加执行权限 | 低 |
| 版本不兼容 | kubectl version --short | 降级或升级CNI插件 | 高 |
| IPAM耗尽 | kubectl get ip | 扩展IP池或回收IP | 紧急 |
最稳妥的恢复流程：
systemctl stop kubelet rm -rf /var/lib/cni/ systemctl restart containerd systemctl start kubelet4. 容器运行时故障的快速响应
当容器运行时崩溃时，节点上的所有Pod都会变成"无主"状态。去年我们曾因containerd的bug导致整个集群的节点批量失联，最终通过以下方案化险为夷。
4.1 运行时健康检查清单
服务状态：
systemctl status containerd --no-pager -l套接字检测：
ss -lnp | grep containerd版本验证：
containerd --version ctr version核心功能测试：
ctr images pull docker.io/library/nginx:alpine
4.2 高级调试技巧
内存泄漏检测：
cat /sys/fs/cgroup/memory/system.slice/containerd.service/memory.usage_in_bytes性能分析：
containerd-debug.sh collect数据重置方案（最后手段）：
systemctl stop kubelet rm -rf /var/lib/containerd/ systemctl restart containerd kubeadm reset -f5. 资源耗尽类问题的预防体系
NotReady状态有时只是资源耗尽的表象。建立预防体系比事后抢救更重要。
5.1 关键监控指标
# 内存压力 cat /proc/pressure/memory # IO阻塞 cat /proc/pressure/io # PID耗尽 ps -eLf | wc -l5.2 自动化防护方案
动态回收策略：
apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration evictionHard: memory.available: "500Mi" nodefs.available: "10%"早期预警系统：
watch -n 60 'kubectl top node | grep -v NAME'在真实的生产环境中，节点NotReady往往不是单一因素导致。最近处理的一个案例就同时涉及存储容量告警、CNI插件超时和containerd内存泄漏三重问题。这种情况下，必须建立清晰的排查优先级——先恢复网络连通性，再解决存储问题，最后处理运行时异常。
