Sealos部署K8s集群后Pod全NotReady？别慌，先检查containerd服务状态-编程实验室

Kubernetes集群Pod全NotReady故障排查：从日志分析到服务恢复实战

凌晨三点，运维工程师小李的钉钉突然炸出一连串报警——刚用Sealos部署的K8s生产环境所有节点集体罢工，监控大屏上刺眼的NotReady状态像多米诺骨牌般蔓延。这种场景对刚接触容器编排的新手而言无异于噩梦开局，但事实上，90%的类似故障都能通过系统化的日志分析找到突破口。

1. 故障现象速诊：NotReady背后的信号链

当kubectl get nodes返回清一色的NotReady状态时，新手常会陷入两种极端：要么盲目重启整个集群，要么在搜索引擎里机械地尝试各种解决方案。专业排障的第一步是建立症状与系统的映射关系：

# 查看节点基础状态（重点关注Conditions字段） kubectl describe nodes | grep -A 10 "Conditions:"

典型输出中需要警惕的信号包括：

NetworkUnavailable=true（网络插件异常）
MemoryPressure/DiskPressure=true（资源不足）
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 overlay`
CRI接口超时	资源不足	`free -h; df -h`

3. 精准打击：containerd服务重启的艺术

当确认问题根源在容器运行时层时，systemctl restart containerd看似简单的操作背后藏着多个需要关注的细节：

3.1 安全重启操作指南

# 优雅重启流程（避免正在运行的容器被强制终止） sudo systemctl stop kubelet sudo systemctl restart containerd sudo systemctl start kubelet # 验证容器运行时健康状态 sudo ctr version

3.2 重启后的连锁反应处理

容器运行时重启会触发一系列连锁反应，需要按顺序验证：

CNI网络重建：检查Calico/Flannel等网络组件的Pod状态
```
kubectl -n kube-system get pods -l tier=node
```
Pod恢复进度：观察原有工作负载的重调度
```
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: 'containerd'

4.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 fi