K8s节点NotReady故障排查实战手册12种典型场景与精准修复策略当集群监控大屏突然亮起红色告警某个节点状态赫然显示NotReady时作为运维负责人的你心跳是否漏了半拍别担心这份手册将带你像资深SRE一样快速锁定问题根源并实施精准修复。不同于常规理论文档我们直接从生产环境中最常见的12种故障模式切入每个案例都配有可立即执行的诊断命令和已验证的解决方案。1. 节点状态基础诊断框架在深入具体案例前我们需要建立系统化的排查路径。以下是每个NotReady节点都应该执行的基础检查流程第一步快速状态确认# 获取节点基础状态 kubectl get nodes -o wide # 查看详细事件记录 kubectl describe node 故障节点名称 | grep -A 20 Conditions:第二步核心组件健康检查# 检查kubelet运行状态节点上执行 systemctl status kubelet --no-pager -l # 查看最近50条kubelet日志 journalctl -u kubelet -n 50 --no-pager | grep -i error第三步资源瓶颈分析# 内存与交换分区检查 free -h # 磁盘空间分析重点关注/var分区 df -h | grep -v tmpfs # 进程资源占用排序 ps aux --sort-%mem | head -10提示将上述命令保存为node_check.sh并赋予执行权限可快速建立排查工具包关键指标阈值参考表指标类型正常范围危险阈值检查命令内存可用量总内存20%500MBfree -h根分区使用率80%90%df -h /CPU负载(5分钟)核心数×2核心数×4uptime节点时钟偏移100ms500msntpstat2. 网络连接类故障排查2.1 Case 1: use of closed network connection错误典型现象节点日志持续输出write tcp 127.0.0.1:37742-127.0.0.1:60443: use of closed network connectionkubelet与API Server的通信时断时续根本原因 这是Kubernetes处理HTTP/2连接时的一个已知问题当连接处于半关闭状态时kubelet仍尝试发送数据会导致此错误。该问题在以下版本中已修复v1.22.15v1.23.12v1.24.6应急处理方案# 重启kubelet服务 systemctl restart kubelet # 验证修复观察5分钟 watch -n 5 kubectl get nodes | grep 节点名长期解决方案 升级集群到已修复版本或应用以下补丁配置# kubelet配置片段 apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration http2MaxStreamsPerConnection: 100 # 默认250降低可减少连接竞争2.2 Case 2: etcd请求超时典型现象日志出现etcdserver: request timed out节点状态在Ready与NotReady间频繁波动排查步骤# 检查etcd集群健康状态 ETCDCTL_API3 etcdctl --endpointshttps://etcd-ip:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key endpoint health # 查看etcd存储性能 ETCDCTL_API3 etcdctl --write-outtable endpoint status常见修复方案存储空间优化# 获取当前修订版本 rev$(ETCDCTL_API3 etcdctl --endpoints... endpoint status | grep -oP revision:\s\K\d) # 执行压缩操作 ETCDCTL_API3 etcdctl --endpoints... compact $((rev-1000)) # 整理碎片 ETCDCTL_API3 etcdctl --endpoints... defrag性能调优参数# etcd启动参数建议 --quota-backend-bytes8589934592 # 8GB空间限制 --auto-compaction-retention24h # 24小时自动压缩 --enable-pproftrue # 开启性能分析3. 运行时与资源类故障3.1 Case 3: 容器运行时无响应典型现象日志显示container runtime status check may not have completed yetdocker ps或crictl ps命令卡死问题定位# 检查容器运行时进程状态 ps aux | grep -E dockerd|containerd # 强制清理卡死的容器进程 for pid in $(ps -ef | grep -E docker-containerd-shim|containerd-shim | awk {print $2}); do kill -9 $pid done根治方案# 重建容器运行时服务 systemctl stop kubelet systemctl stop docker rm -rf /var/lib/docker/containerd/* systemctl start docker systemctl start kubelet3.2 Case 4: 镜像文件系统异常典型现象事件日志出现Warning InvalidDiskCapacity invalid capacity 0 on image filesystem新Pod无法拉取镜像快速修复# 重启containerd服务 systemctl restart containerd # 验证修复 crictl images深度处理# 检查存储驱动配置 cat /etc/containerd/config.toml | grep -A 5 ^\[plugins\.\io\.containerd\.grpc\.v1\.cri\\.containerd\.runtimes\.runc\.options\] # 典型配置示例 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true4. 配置与系统类故障4.1 Case 5: 节点时间不同步典型现象日志中出现systemd: Time has been changed跨节点服务调用出现证书验证失败诊断与修复# 检查时间偏移量 chronyc tracking | grep -i skew # 强制立即同步 chronyc makestep # 检查NTP服务状态 systemctl status chronyd配置建议# /etc/chrony.conf 关键配置 pool 2.cn.pool.ntp.org iburst makestep 1.0 3 maxdistance 1.04.2 Case 6: cgroup驱动不一致典型现象日志报错cgroup driver cgroupfs is different from dockerkubelet启动后立即崩溃解决方案# 修改kubelet启动参数 sed -i s/--cgroup-driver.*/--cgroup-driversystemd/ /etc/systemd/system/kubelet.service.d/10-kubeadm.conf # 应用配置 systemctl daemon-reload systemctl restart kubelet验证方法docker info | grep -i cgroup kubelet --cgroup-driver | grep systemd5. 高级诊断工具与技术5.1 节点事件智能分析使用kubectl结合jq进行高级事件过滤# 提取最近1小时的关键警告事件 kubectl get events --field-selector typeWarning \ -o json | jq -r .items[] | select(.lastTimestamp $(date -d 1 hour ago -Ins --utc | sed s/0000/Z/)) | .message5.2 Prometheus监控集成关键监控指标示例# 节点就绪状态 kube_node_status_condition{conditionReady,statustrue} # PLEG健康检查 rate(kubelet_pleg_relist_duration_seconds_sum[5m]) 1 # 资源压力预测 predict_linear(node_memory_MemAvailable_bytes[1h], 3600) 05.3 自动化修复脚本示例#!/bin/bash NODE$1 function check_kubelet() { ssh $NODE systemctl is-active kubelet | grep -q active || { echo Restarting kubelet... ssh $NODE systemctl restart kubelet } } function check_docker() { ssh $NODE docker ps /dev/null 21 || { echo Restarting docker... ssh $NODE systemctl restart docker } } check_kubelet check_docker6. 最佳实践与经验总结在管理过数十个生产集群后我总结出以下节点稳定性保障原则预防性维护周期每周检查节点时钟同步状态每月验证etcd存储健康度每季度审计kubelet配置一致性关键配置清单- [ ] 确保所有节点使用相同的容器运行时版本 - [ ] 统一cgroup驱动配置推荐systemd - [ ] 设置合理的kubelet--node-status-update-frequency默认10s - [ ] 配置适当的--eviction-hard内存阈值建议memory.available500Mi故障演练建议定期模拟网络分区场景测试磁盘压力下的Pod驱逐行为验证kubelet自动恢复能力记住节点NotReady状态就像发烧症状关键是要快速找到真正的病因。掌握这12种典型案例的处理方法配合系统化的排查流程你就能在下次告警响起时从容应对。
K8s节点NotReady别慌！从12个真实Case看如何快速定位（附排查命令清单）
K8s节点NotReady故障排查实战手册12种典型场景与精准修复策略当集群监控大屏突然亮起红色告警某个节点状态赫然显示NotReady时作为运维负责人的你心跳是否漏了半拍别担心这份手册将带你像资深SRE一样快速锁定问题根源并实施精准修复。不同于常规理论文档我们直接从生产环境中最常见的12种故障模式切入每个案例都配有可立即执行的诊断命令和已验证的解决方案。1. 节点状态基础诊断框架在深入具体案例前我们需要建立系统化的排查路径。以下是每个NotReady节点都应该执行的基础检查流程第一步快速状态确认# 获取节点基础状态 kubectl get nodes -o wide # 查看详细事件记录 kubectl describe node 故障节点名称 | grep -A 20 Conditions:第二步核心组件健康检查# 检查kubelet运行状态节点上执行 systemctl status kubelet --no-pager -l # 查看最近50条kubelet日志 journalctl -u kubelet -n 50 --no-pager | grep -i error第三步资源瓶颈分析# 内存与交换分区检查 free -h # 磁盘空间分析重点关注/var分区 df -h | grep -v tmpfs # 进程资源占用排序 ps aux --sort-%mem | head -10提示将上述命令保存为node_check.sh并赋予执行权限可快速建立排查工具包关键指标阈值参考表指标类型正常范围危险阈值检查命令内存可用量总内存20%500MBfree -h根分区使用率80%90%df -h /CPU负载(5分钟)核心数×2核心数×4uptime节点时钟偏移100ms500msntpstat2. 网络连接类故障排查2.1 Case 1: use of closed network connection错误典型现象节点日志持续输出write tcp 127.0.0.1:37742-127.0.0.1:60443: use of closed network connectionkubelet与API Server的通信时断时续根本原因 这是Kubernetes处理HTTP/2连接时的一个已知问题当连接处于半关闭状态时kubelet仍尝试发送数据会导致此错误。该问题在以下版本中已修复v1.22.15v1.23.12v1.24.6应急处理方案# 重启kubelet服务 systemctl restart kubelet # 验证修复观察5分钟 watch -n 5 kubectl get nodes | grep 节点名长期解决方案 升级集群到已修复版本或应用以下补丁配置# kubelet配置片段 apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration http2MaxStreamsPerConnection: 100 # 默认250降低可减少连接竞争2.2 Case 2: etcd请求超时典型现象日志出现etcdserver: request timed out节点状态在Ready与NotReady间频繁波动排查步骤# 检查etcd集群健康状态 ETCDCTL_API3 etcdctl --endpointshttps://etcd-ip:2379 \ --cacert/etc/kubernetes/pki/etcd/ca.crt \ --cert/etc/kubernetes/pki/etcd/server.crt \ --key/etc/kubernetes/pki/etcd/server.key endpoint health # 查看etcd存储性能 ETCDCTL_API3 etcdctl --write-outtable endpoint status常见修复方案存储空间优化# 获取当前修订版本 rev$(ETCDCTL_API3 etcdctl --endpoints... endpoint status | grep -oP revision:\s\K\d) # 执行压缩操作 ETCDCTL_API3 etcdctl --endpoints... compact $((rev-1000)) # 整理碎片 ETCDCTL_API3 etcdctl --endpoints... defrag性能调优参数# etcd启动参数建议 --quota-backend-bytes8589934592 # 8GB空间限制 --auto-compaction-retention24h # 24小时自动压缩 --enable-pproftrue # 开启性能分析3. 运行时与资源类故障3.1 Case 3: 容器运行时无响应典型现象日志显示container runtime status check may not have completed yetdocker ps或crictl ps命令卡死问题定位# 检查容器运行时进程状态 ps aux | grep -E dockerd|containerd # 强制清理卡死的容器进程 for pid in $(ps -ef | grep -E docker-containerd-shim|containerd-shim | awk {print $2}); do kill -9 $pid done根治方案# 重建容器运行时服务 systemctl stop kubelet systemctl stop docker rm -rf /var/lib/docker/containerd/* systemctl start docker systemctl start kubelet3.2 Case 4: 镜像文件系统异常典型现象事件日志出现Warning InvalidDiskCapacity invalid capacity 0 on image filesystem新Pod无法拉取镜像快速修复# 重启containerd服务 systemctl restart containerd # 验证修复 crictl images深度处理# 检查存储驱动配置 cat /etc/containerd/config.toml | grep -A 5 ^\[plugins\.\io\.containerd\.grpc\.v1\.cri\\.containerd\.runtimes\.runc\.options\] # 典型配置示例 [plugins.io.containerd.grpc.v1.cri.containerd.runtimes.runc.options] SystemdCgroup true4. 配置与系统类故障4.1 Case 5: 节点时间不同步典型现象日志中出现systemd: Time has been changed跨节点服务调用出现证书验证失败诊断与修复# 检查时间偏移量 chronyc tracking | grep -i skew # 强制立即同步 chronyc makestep # 检查NTP服务状态 systemctl status chronyd配置建议# /etc/chrony.conf 关键配置 pool 2.cn.pool.ntp.org iburst makestep 1.0 3 maxdistance 1.04.2 Case 6: cgroup驱动不一致典型现象日志报错cgroup driver cgroupfs is different from dockerkubelet启动后立即崩溃解决方案# 修改kubelet启动参数 sed -i s/--cgroup-driver.*/--cgroup-driversystemd/ /etc/systemd/system/kubelet.service.d/10-kubeadm.conf # 应用配置 systemctl daemon-reload systemctl restart kubelet验证方法docker info | grep -i cgroup kubelet --cgroup-driver | grep systemd5. 高级诊断工具与技术5.1 节点事件智能分析使用kubectl结合jq进行高级事件过滤# 提取最近1小时的关键警告事件 kubectl get events --field-selector typeWarning \ -o json | jq -r .items[] | select(.lastTimestamp $(date -d 1 hour ago -Ins --utc | sed s/0000/Z/)) | .message5.2 Prometheus监控集成关键监控指标示例# 节点就绪状态 kube_node_status_condition{conditionReady,statustrue} # PLEG健康检查 rate(kubelet_pleg_relist_duration_seconds_sum[5m]) 1 # 资源压力预测 predict_linear(node_memory_MemAvailable_bytes[1h], 3600) 05.3 自动化修复脚本示例#!/bin/bash NODE$1 function check_kubelet() { ssh $NODE systemctl is-active kubelet | grep -q active || { echo Restarting kubelet... ssh $NODE systemctl restart kubelet } } function check_docker() { ssh $NODE docker ps /dev/null 21 || { echo Restarting docker... ssh $NODE systemctl restart docker } } check_kubelet check_docker6. 最佳实践与经验总结在管理过数十个生产集群后我总结出以下节点稳定性保障原则预防性维护周期每周检查节点时钟同步状态每月验证etcd存储健康度每季度审计kubelet配置一致性关键配置清单- [ ] 确保所有节点使用相同的容器运行时版本 - [ ] 统一cgroup驱动配置推荐systemd - [ ] 设置合理的kubelet--node-status-update-frequency默认10s - [ ] 配置适当的--eviction-hard内存阈值建议memory.available500Mi故障演练建议定期模拟网络分区场景测试磁盘压力下的Pod驱逐行为验证kubelet自动恢复能力记住节点NotReady状态就像发烧症状关键是要快速找到真正的病因。掌握这12种典型案例的处理方法配合系统化的排查流程你就能在下次告警响起时从容应对。
