Kubernetes集群Pod全NotReady故障排查从日志分析到服务恢复实战凌晨三点运维工程师小李的钉钉突然炸出一连串报警——刚用Sealos部署的K8s生产环境所有节点集体罢工监控大屏上刺眼的NotReady状态像多米诺骨牌般蔓延。这种场景对刚接触容器编排的新手而言无异于噩梦开局但事实上90%的类似故障都能通过系统化的日志分析找到突破口。1. 故障现象速诊NotReady背后的信号链当kubectl get nodes返回清一色的NotReady状态时新手常会陷入两种极端要么盲目重启整个集群要么在搜索引擎里机械地尝试各种解决方案。专业排障的第一步是建立症状与系统的映射关系# 查看节点基础状态重点关注Conditions字段 kubectl describe nodes | grep -A 10 Conditions:典型输出中需要警惕的信号包括NetworkUnavailabletrue网络插件异常MemoryPressure/DiskPressuretrue资源不足KubeletNotReady节点代理服务异常注意NotReady是表象而非根因就像发烧是症状而非疾病本身。直接跳转到解决方案而跳过诊断环节是故障复发的温床。2. 日志深潜从kubelet到containerd的调用链追踪现代容器编排系统的精妙之处在于其分层日志体系就像剥洋葱般逐层暴露问题本质。以下是关键日志采集点及其解读方法2.1 kubelet日志中的黄金线索# 实时追踪kubelet日志-u指定服务单元 journalctl -u kubelet -f --no-pager | grep -E error|fail|not ready当看到类似Container runtime network not ready和cni plugin not initialized的报错时说明故障已定位到容器运行时层。这两个错误的组合出现通常意味着网络插件未就绪CNI配置缺失或插件崩溃容器运行时异常containerd/docker服务无响应组件通信故障kubelet与CRI接口握手失败2.2 containerd服务状态检查容器运行时如同K8s的心脏其状态直接影响整个集群的供血能力。快速诊断命令包括# 检查服务活跃状态 systemctl is-active containerd # 查看详细服务日志重点关注最近5分钟 journalctl -u containerd -S 5 minutes ago --no-pager常见异常模式对照表症状可能原因验证命令服务未运行启动失败或崩溃systemctl status containerd套接字无响应文件权限问题ls -l /run/containerd/containerd.sock镜像挂载失败存储驱动异常dmesg | grep overlayCRI接口超时资源不足free -h; df -h3. 精准打击containerd服务重启的艺术当确认问题根源在容器运行时层时systemctl restart containerd看似简单的操作背后藏着多个需要关注的细节3.1 安全重启操作指南# 优雅重启流程避免正在运行的容器被强制终止 sudo systemctl stop kubelet sudo systemctl restart containerd sudo systemctl start kubelet # 验证容器运行时健康状态 sudo ctr version3.2 重启后的连锁反应处理容器运行时重启会触发一系列连锁反应需要按顺序验证CNI网络重建检查Calico/Flannel等网络组件的Pod状态kubectl -n kube-system get pods -l tiernodePod恢复进度观察原有工作负载的重调度watch -n 1 kubectl get pods -A -o wide节点心跳恢复等待节点状态更新周期默认1分钟经验提示生产环境中建议在维护窗口期操作避免批量Pod重建导致服务中断4. 防御性运维构建故障预防体系解决当次故障只是开始构建防御体系才能避免重蹈覆辙。以下是三个关键防护层4.1 服务存活监控# 创建containerd服务监控探针Prometheus格式 metrics_path: /metrics static_configs: - targets: [localhost:9090] labels: service: containerd4.2 自动化恢复脚本#!/bin/bash # 自动检测并恢复containerd异常 if ! systemctl is-active --quiet containerd; then logger Containerd service down, attempting restart systemctl restart containerd sleep 5 if systemctl is-active --quiet containerd; then logger Containerd restarted successfully else logger Containerd restart failed, escalating exit 1 fi fi4.3 根因分析检查清单每次故障后应完成以下检查项[ ] 系统日志归档journalctl --vacuum-size100M[ ] 容器运行时版本检查containerd --version[ ] 内核参数审计sysctl -a | grep container[ ] 资源水位评估内存/IOPS/CPU压力在笔者经历过的数十次NotReady事件中有次发现某节点containerd每隔6小时就崩溃一次。最终定位到是某监控组件的内存泄漏逐渐挤占容器运行时资源。这提醒我们简单重启治标根因分析治本。