Kubernetes排错(十五)：节点NotReady故障排查处理
在Kubernetes生产集群中，节点突然变成NotReady状态是运维团队最常遇到的紧急故障之一。本文将分享一套经过实战检验的排查流程，并附上生产环境专用诊断命令。
一、快速诊断三板斧（5分钟定位问题）
1. 基础状态速查
# 查看所有节点状态（重点关注READY列）
kubectl get nodes -o wide# 获取节点详细事件（核心排查入口）
kubectl describe node <节点名> | grep -A 15 'Conditions'
2. 黄金三指标
- 网络连通性：API Server可达性
# 从故障节点测试控制面连通性 curl -k https://<API-Server-IP>:6443/healthz - kubelet状态：进程是否存活
# 检查kubelet服务状态（生产环境常见问题源） systemctl status kubelet -l | grep Active - 容器运行时：CRI是否正常
# Containerd运行时检查 ctr containers list
二、深度排查七步走
步骤1：kubelet日志分析
# 实时追踪kubelet日志（重点关注ERROR级别）
journalctl -u kubelet -f | grep -E 'error|fail'
常见日志模式：
PLEG is not healthy→ 容器运行时异常Failed to update node status→ 证书过期或APIServer连接问题
步骤2：资源瓶颈检查
# 磁盘空间（/var/lib分区是关键）
df -h /var/lib/docker /var/lib/kubelet# 内存压力（可用<10%需警惕）
free -m | awk 'NR==2{printf "%.1f%%\n", $3*100/$2}'# 进程级资源监控
top -p $(pgrep kubelet) -p $(pgrep containerd)
步骤3：网络诊断
# 检查CNI插件状态（Calico示例）
calicoctl node status# 关键端口连通性测试
nc -zv <API-Server-IP> 6443 # 控制面通信
nc -zv <其他节点IP> 8472 # Flannel VXLAN
步骤4：证书有效性验证
# 检查kubelet客户端证书
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -dates
⚠️ 证书过期是生产环境常见陷阱
步骤5：内核日志审查
# 查看系统级错误（OOM、硬件故障等）
dmesg -T | grep -iE 'oom|error|fail'
步骤6：容器运行时检测
# Containerd健康检查
ctr version && ctr namespaces list# 容器进程树分析
pstree -ap | grep -E 'containerd|kubelet'
步骤7：节点自检工具
# 使用官方检查脚本
curl -sSL https://raw.githubusercontent.com/kubernetes-sigs/kubespray/master/contrib/validate/validate-cluster.sh | bash
三、高频故障场景处理指南
场景1：PLEG不健康（生产环境TOP1问题）
现象：
PLEG is not healthy: pleg was last seen active 3m0s ago
解决方案：
# 重启容器运行时（Containerd示例）
systemctl restart containerd
# 清理残留容器
ctr containers list | awk '{print $1}' | xargs -I{} ctr containers delete {}
场景2：证书过期
特征：
- kubelet日志出现
x509: certificate has expired or is not yet valid
修复流程：
rm -f /var/lib/kubelet/pki/kubelet-client-*
systemctl restart kubelet
场景3：磁盘爆满
应急处理：
# 快速定位大文件
du -h /var/lib/docker/overlay2 | sort -rh | head -20# 清理dead容器
docker system prune -af
四、生产环境防护体系
1. 预防性监控配置
# Prometheus告警规则示例
- alert: NodeNotReadyexpr: kube_node_status_condition{condition="Ready",status="true"} == 0for: 5mlabels:severity: critical
2. 节点健康检查机制
# kubelet配置示例（/etc/kubernetes/kubelet.conf）
healthzBindAddress: 0.0.0.0:10248
healthzPort: 10248
3. 自动化恢复方案
# 自动驱逐Pod脚本（谨慎使用）
kubectl get pods --all-namespaces -o wide | grep <故障节点> | awk '{print $1,$2}' | xargs -n2 kubectl delete pod -n
五、专家级调试技巧
-
动态日志级别调整：
# 临时开启kubelet调试日志 curl -X PUT -d "4" http://localhost:10248/debug/flags/v -
内核参数调优：
# 解决文件句柄耗尽问题 sysctl -w fs.inotify.max_user_watches=1048576 -
APIServer审计分析：
kubectl logs -n kube-system kube-apiserver-<pod> | grep <节点IP>
六、避坑指南
- 勿盲目重启节点：可能导致状态不一致
- 慎用force delete：可能引发数据卷残留
- 监控时区统一：确保所有节点时间同步
- 版本兼容性检查：kubelet与控制面版本差异不超过2个minor版本
通过系统化的排查流程和预防措施，运维团队可以将节点NotReady的平均恢复时间（MTTR）缩短70%以上。建议将核心检查步骤沉淀为自动化脚本，并建立多维监控体系，实现从"被动救火"到"主动防御"的转变。