K8s节点NotReady别慌！从12个真实Case看如何快速定位与恢复（附排查命令清单）
Kubernetes节点NotReady故障排查实战：12个高频问题与快速恢复指南
凌晨三点，刺耳的告警声划破运维室的宁静——生产集群中三个节点突然陷入NotReady状态。这不是教科书里的理论场景，而是每个Kubernetes管理员都可能遭遇的真实危机。本文将基于数百个真实故障案例提炼出12类最高频的节点故障模式，提供可直接套用的诊断路径和修复命令，帮助您在分秒必争的故障现场快速恢复业务。
1. 诊断工具箱：必须掌握的排查命令
在深入具体案例前，我们需要装备好基础排查工具。以下命令组合能覆盖90%的节点故障初步诊断：
# 获取节点基础状态 kubectl get nodes -o wide kubectl describe node <故障节点名> # 检查核心组件日志 journalctl -xu kubelet --no-pager -n 100 journalctl -xu docker --no-pager -n 50 || journalctl -xu containerd --no-pager -n 50 # 资源检查三板斧 free -h && uptime # 内存与负载 df -h # 磁盘空间 ss -tulnp | grep kube # 端口监听 # 高级诊断（需节点SSH访问） crictl ps -a # 容器运行时状态 cat /proc/$(pidof kubelet)/limits # 检查文件描述符限制典型输出解析要点：
kubectl describe node中Conditions段的Ready字段会显示"False"及具体原因Events区域最后10条事件往往包含关键线索kubelet日志中搜索"Error"或"Failed"关键词
提示：建议将上述命令保存为
node_check.sh脚本，故障时一键执行并重定向输出到日志文件
2. 网络类故障：从连接拒绝到etcd超时
2.1 Case 1: "use of closed network connection"
现象：
- 节点状态间歇性抖动
- kubelet日志持续输出
Post https://[API-SERVER]: write tcp: use of closed network connection
根因： HTTP/2连接半关闭状态处理缺陷，多出现在Kubernetes 1.18-1.22版本
修复方案：
# 临时方案 systemctl restart kubelet # 永久方案 升级到Kubernetes 1.23+版本或打补丁： https://github.com/kubernetes/kubernetes/pull/1044442.2 Case 2: etcd请求超时
现象：
- 控制平面节点NotReady
- 日志出现
etcdserver: request timed out或failed to update lease
诊断步骤：
# 检查etcd集群健康状态 ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key endpoint health # 检查存储空间 ETCDCTL_API=3 etcdctl --write-out=table endpoint status修复方案：
| 问题类型 | 操作命令 | 注意事项 |
|---|---|---|
| 空间不足 | etcdctl compact+etcdctl defrag | 需在非业务高峰操作 |
| 节点失联 | 重启异常etcd实例 | 确保剩余节点数 > N/2 |
| 证书过期 | 更新证书后重启 | 检查kube-apiserver连接配置 |
3. 运行时异常：从Docker僵死到cgroup冲突
3.1 Case 3: 容器运行时无响应
现象：
- 节点状态为Ready但无法创建新Pod
- 出现
container runtime status check may not have completed yet告警
快速检测：
# Docker运行时检查 timeout 10 docker ps > /dev/null || echo "Docker unresponsive" # Containerd运行时检查 crictl stats > /dev/null || echo "Containerd unresponsive"恢复流程：
- 尝试重启运行时服务
systemctl restart docker || systemctl restart containerd - 清理卡死容器进程
# 查找异常进程 ps aux | grep -E 'docker|containerd' | grep -v grep kill -9 <异常PID> - 检查运行时日志
journalctl -xu docker --no-pager -n 100 | grep -A 10 -B 10 "panic"
3.2 Case 4: cgroup驱动不一致
现象：
- 新加入节点始终NotReady
- kubelet日志报
cgroup driver "cgroupfs" is different from docker
解决方案：
# 修改kubelet配置 sed -i 's/cgroup-driver=.*/cgroup-driver=systemd/' /var/lib/kubelet/config.yaml # 重启服务 systemctl daemon-reload && systemctl restart kubelet配置验证：
ps -ef | grep kubelet | grep cgroup-driver docker info | grep -i cgroup4. 资源耗尽：从OOM到磁盘压垮
4.1 Case 5: 内存耗尽触发OOM
现象：
- 节点突然NotReady
- 系统日志出现
System OOM encountered, victim process: xxx
应急处理：
# 释放缓存（生产环境慎用） echo 1 > /proc/sys/vm/drop_caches # 快速定位内存大户 ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -n 10长期方案：
- 调整kubelet驱逐阈值：
# /var/lib/kubelet/config.yaml evictionHard: memory.available: "500Mi" nodefs.available: "10%" - 为关键Pod设置资源限制：
resources: requests: memory: "256Mi" limits: memory: "512Mi"
4.2 Case 6: 镜像存储异常
现象：
- 节点NotReady伴随
invalid capacity 0 on image filesystem告警 df -h显示/var/lib/containers挂载点异常
修复步骤：
# 检查存储驱动 docker info | grep "Storage Driver" lsblk -f | grep var # 重启容器运行时 systemctl restart containerd && systemctl restart kubelet5. 系统配置类问题
5.1 Case 7: 时间不同步
现象：
- 节点与API Server通信异常
- 日志出现
x509: certificate has expired or is not yet valid
诊断命令：
# 检查时间偏移 chronyc tracking | grep "System time" date && kubectl get --raw='/readyz?verbose' | grep lease修复方案：
# 强制时间同步 chronyc makestep && systemctl restart chronyd # 验证时间一致性 kubectl get nodes -o wide | awk '{print $1,$2,$6}'5.2 Case 8: 文件描述符耗尽
现象：
- Docker/kubelet服务崩溃
- 日志出现
too many open files
解决方案：
# 临时提高限制 ulimit -n 65535 # 永久修改 echo "* soft nofile 1048576" >> /etc/security/limits.conf echo "* hard nofile 1048576" >> /etc/security/limits.conf # 检查进程实际限制 cat /proc/$(pidof kubelet)/limits | grep "Max open files"6. 高级诊断技巧
6.1 PLEG健康检查失败
现象：
- 周期性节点NotReady
PLEG is not healthy: pleg was last seen active 5m ago
根因分析： PLEG(Pod生命周期事件生成器)负责检测Pod状态变化，当其超时会导致节点状态异常。
排查路径：
- 检查容器运行时响应延迟
crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps - 分析kubeletCPU使用率
pidstat -p $(pidof kubelet) 1 5 - 检查磁盘IO延迟
iostat -xmdz 1 | grep -E 'Device|sd[a-z]'
6.2 节点状态未知（NodeStatusUnknown）
处理流程：
- 检查kubelet心跳间隔
grep -i "node-status-update-frequency" /var/lib/kubelet/config.yaml - 验证API Server连通性
curl -k https://localhost:6443/healthz - 检查网络插件状态
kubectl get pods -n kube-system | grep -E 'flannel|calico|cilium'
7. 预防性运维策略
监控指标配置建议：
| 指标名称 | 告警阈值 | 检测命令示例 |
|---|---|---|
| kube_node_status_condition | Ready=False > 1m | kubectl get --raw='/metrics' |
| node_memory_MemAvailable_bytes | < 10%总内存 | free -h |
| node_filesystem_avail_bytes | < 15%分区大小 | df -h /var/lib/containers |
| kubelet_runtime_operations_latency | 创建容器>5s | kubectl top nodes |
定期维护脚本：
#!/bin/bash # 节点健康检查脚本 check_list=( "kubelet status::systemctl is-active kubelet" "container runtime::crictl ps -q | wc -l" "disk space::df -h /var/lib/containers | awk 'NR==2{print \$5}'" ) for item in "${check_list[@]}"; do name=${item%%::*} cmd=${item#*::} echo "[检查项] $name => $(eval $cmd)" done8. 典型案例复盘
某电商大促期间故障处理：
现象：
- 凌晨2点10个节点同时NotReady
- 监控显示内存使用率>95%
诊断过程：
# 快速定位问题Pod kubectl get pods -A -o wide --field-selector spec.nodeName=<故障节点> | grep -v Running # 分析内存使用 kubectl top pods -A --sort-by=memory | head -n 10根本原因：
- 促销活动Pod未设置内存限制
- HPA策略失效导致副本数激增
解决方案：
# 紧急扩容节点 kubectl scale --replicas=5 deployment/promotion-service # 批量设置资源限制 kubectl get deploy -n promotion -o name | xargs -I{} kubectl patch {} \ -p '{"spec":{"template":{"spec":{"containers":[{"name":"main","resources":{"limits":{"memory":"2Gi"}}}]}}}}'
9. 命令速查表
故障恢复命令大全：
| 故障类型 | 关键命令 |
|---|---|
| 证书过期 | openssl x509 -noout -dates -in /etc/kubernetes/pki/apiserver.crt |
| 网络插件故障 | kubectl logs -n kube-system <CNI_POD> --tail=100 |
| Kubelet注册失败 | `journalctl -xu kubelet |
| 持久卷挂载失败 | `mount |
| 内核参数问题 | `sysctl -a |
10. 版本特异性问题
各Kubernetes版本常见陷阱：
| 版本范围 | 典型问题 | 解决方案 |
|---|---|---|
| 1.18-1.20 | dockershim内存泄漏 | 升级或迁移到containerd |
| 1.21-1.23 | etcd存储碎片化 | 定期执行etcdctl defrag |
| 1.24+ | CRI v1默认启用 | 确认容器运行时兼容性 |
| 1.26+ | Seccomp默认开启 | 为旧工作负载添加seccompProfile: RuntimeDefault |
11. 自动化修复方案
使用Kured实现自动重启：
- 部署Kured守护进程集：
kubectl apply -f https://github.com/kubereboot/kured/releases/latest/download/kured.yaml - 配置重启条件：
# kured-config ConfigMap data: REBOOT_SENTINEL_FILE: /var/run/reboot-required PROMETHEUS_URL: http://prometheus-operated.monitoring:9090 ALERTFILTER: 'kube_node_status_condition{condition="Ready",status="false"}==1'
12. 终极恢复手段
当所有常规手段失效时，按此流程操作：
节点隔离：
kubectl cordon <故障节点> kubectl drain <故障节点> --ignore-daemonsets --delete-emptydir-data彻底重置：
kubeadm reset --force rm -rf /etc/cni/net.d /var/lib/kubelet /var/lib/etcd重新加入集群：
kubeadm join <控制平面IP>:6443 --token <token> \ --discovery-token-ca-cert-hash sha256:<hash>
记得在办公桌抽屉里备好这份清单——下次凌晨三点的告警响起时，您会感谢现在的准备。真正的专家不是从不犯错，而是能用最短的时间把集群从悬崖边拉回来。