incident-kubelet-hang

一次网络存储挂起导致 kubelet 与容器运行时同时卡死的复盘（匿名化合成案例）。

现象

某业务集群的一个节点变为 NotReady。节点上的 kubelet 进程仍然存在，systemctl status kubelet 甚至显示 active，但日志反复出现 PLEG is not healthy。crictl 命令长时间无输出，依赖该节点的 Pod 状态不再更新。其他节点正常，集群整体没有大面积故障。重启 kubelet 和 containerd 都没有恢复，重启命令本身有时也会卡住。

时间线

• T+0：节点心跳超时，kubectl get nodes 显示 NotReady，调度器停止向该节点分配新 Pod。
• T+4m：值班人员登录节点，看到 kubelet 服务是 active，日志提示 PLEG 不健康，判断是 kubelet 或 containerd 进程异常。
• T+7m：重启 kubelet，节点短暂没有变化；再重启 containerd，命令迟迟不返回，crictl ps 也超时。
• T+11m：怀疑节点磁盘满或资源压力，但本地根分区空间正常，free 也没有明显耗尽；检查工作负载挂载点时，stat 卡住。
• T+15m：ps 显示 kubelet、containerd 和 shim 相关进程处于 D 状态，wchan 停在网络文件系统等待路径；/proc/<pid>/stack 指向 NFS 调用栈。
• T+19m：确认只有一个网络存储端点不可达，节点其他网络正常；挂载参数为硬挂载，存储客户端没有及时返回错误。
• T+23m：将节点标记为不可调度，并在带外管理侧隔离节点，避免仍有容器向失效存储写入。
• T+28m：确认节点已隔离后，驱逐或删除相关 Pod，由其他节点重建副本；单副本有状态工作负载等待存储恢复后人工处理。
• T+32m：存储链路恢复，挂载点通过只读检查和数据一致性验证，允许有状态工作负载重新挂载。
• T+38m：节点通过带外方式重置并重建，旧节点对象被回收；所有工作负载恢复。
• T+46m：新节点加入并稳定运行，事件关闭。

影响面

故障范围被限制在一个节点，但该节点上的所有 Pod 都无法正常上报和停止。有多副本的在线服务在其他节点继续服务，容量相应下降；单副本有状态服务在节点隔离期间不可用。正在写入网络存储的数据是否完整，需要业务对账确认，不能因为节点恢复就假定没有损失。另有部分 Pod 因反亲和和资源约束短暂 Pending，节点替换后恢复。

误导线索

最直接的误导来自 kubelet 自己的日志：PLEG is not healthy 和容器运行时超时看起来都像 kubelet 或 containerd 的进程故障。服务状态又是 active，于是很容易陷入“重启服务—观察失败—再重启”的循环。但真正的证据是进程状态和内核等待点：kubelet 与 containerd 并没有退出，而是和 shim 一起卡在不可中断的存储等待上；这种情况下普通重启既无法清理进程，也无法让 CRI 恢复响应。

另一个误判是资源压力。最初只检查了根分区和内存，看到空间充足便排除了基础设施。后来对业务挂载点执行 stat 立即卡住，结合内核日志中的网络存储超时，才确认是特定挂载链路失效，而不是整机 CPU、内存或根盘问题。只有找到多个进程共同阻塞在同一个挂载或内核调用上，才能把 PLEG 报错从“根因”降级为“症状”。

根因

一个工作负载使用的网络存储端点失联，而该挂载采用硬挂载语义，存储客户端会持续重试，不会快速向上返回错误。同一时间，节点上使用该卷的 Pod 正在重建，容器清理时需要卸载挂载路径，shim 进入不可中断等待，containerd 的相关任务处理被拖住；kubelet 随后无法在超时内完成 CRI 调用和 PLEG 同步，节点心跳最终停止。重启 kubelet 或 containerd 不能解除内核中的挂载等待，因此看起来“服务能启动，但节点始终不恢复”。

反过来看，kubelet 不是最先损坏的组件。它是整条依赖链末端的观察者和受害者：存储不可达导致运行时调用挂起，运行时挂起导致 PLEG 失败，PLEG 失败导致节点 NotReady。

修复

先保留现场，避免不断重启制造更多线索丢失。以下命令中凡是可能访问故障挂载的操作都应加 timeout，防止诊断命令本身被卡死：

kubectl get nodes -o wide
kubectl describe node <node> | grep -A20 -i 'Conditions:'
kubectl get pods -A -o wide --field-selector spec.nodeName=<node>
systemctl status kubelet --no-pager
journalctl -u kubelet --since '-20 min' --no-pager | tail -100
journalctl -u containerd --since '-20 min' --no-pager | tail -100
ps -eo pid,ppid,stat,wchan:32,comm,args | grep -E '[k]ubelet|[c]ontainerd|[s]him'
timeout 5 crictl info; echo "crictl_exit=$?"
timeout 5 crictl ps -a | head
dmesg -T | tail -100
mount | grep -E 'nfs|<storage-endpoint>'
timeout 5 stat -f <mountpoint>

如果具备 root 权限，可对 D 状态进程查看 /proc/<pid>/stack，确认阻塞在哪个内核路径；该接口并非所有内核配置都可用，不能作为唯一依据。处理顺序应为：先 kubectl cordon <node> 阻止新调度，再通过带外管理或网络隔离 fence 节点，确认工作负载无法继续写入后，才驱逐或删除 Pod。不要在未隔离时对有状态 Pod 执行强制删除，否则旧容器可能仍在写同一份数据。

节点恢复通常需要带外重置或重建。普通 reboot 可能因为挂载等待而卡在关机阶段，不能一直等待。新节点加入后检查 CNI、kubelet、运行时和存储挂载，再逐步恢复工作负载。若存储侧已经恢复，仍需验证挂载可读、应用一致性后再允许写入。

预防

• 对网络存储使用专门的健康检查，监控挂载点可用性、RPC 超时和重传；不要把“挂载还在”当成“存储可用”。
• 与存储团队评估挂载超时和恢复语义。硬挂载能避免静默写入错误，但可能造成长时间阻塞；是否改用较短的超时或其他客户端策略，要结合数据安全评估，不能简单改成 soft。
• 容器状态目录和 kubelet 数据目录应放在本地可靠磁盘，不要放在网络文件系统上。
• 节点侧增加 PLEG、CRI 调用超时和 D 状态进程告警。当多个关键进程同时阻塞在一个挂载点时，自动 cordon 并告警，而不是自动重启循环。
• 为单副本有状态服务设计明确的故障域恢复流程，验证节点隔离、Pod 重建和存储一致性检查，而不是只演练进程重启。
• 部署 Node Problem Detector 或等价组件，补充内核和运行时层信号；但不要让它替代对存储链路的监控。
• 缩短故障发现时间：节点心跳、PLEG 和关键容器状态同时异常时，应直接升级为节点级故障处理。

相关命令

• kubelet — 节点代理的配置与运行机制
• containerd — 容器运行时和 shim 行为
• crictl — CRI 调用与容器状态检查
• node-notready — 节点不可用的通用排查路径
• kubelet-not-ready — PLEG 与运行时故障的基础处理
• journalctl — 查看 kubelet 和运行时日志
• systemctl — 判断服务状态与重启行为
• dmesg — 检查内核存储和网络错误
• mount — 查看挂载点和挂载参数

参考链接

• Kubernetes 节点状态与管理
• 使用 crictl 调试 Kubernetes 节点
• Kubernetes 节点问题检测
• Node Problem Detector

读完自测

合上页面，先回答，再展开对照。

1. 为什么 kubelet 服务显示 active，节点仍可能已经不可用？
2. 哪些证据说明问题不在 kubelet 本身，而在底层挂载？
3. 节点隔离和强制删除 Pod 的正确顺序是什么？