Containerd容器终止问题深度分析与解决方案

作者：技术专家视角

问题现象

在Kubernetes集群中频繁进行Pod的创建和删除操作时（特别是批量操作50个Pod的场景），部分Pod会长期停留在Terminating状态。通过containerd日志可观察到持续的StopContainer failed错误，典型日志如下：

StopContainer for \"256a18...\" failed: wait container: context deadline exceeded
ExecSync failed: cannot exec in a stopped container: unknown

技术背景

Containerd作为容器运行时，其停止容器流程包含三个关键阶段：

1. 向容器发送停止信号（默认SIGTERM）
2. 等待容器进程退出（默认30秒超时）
3. 强制终止（SIGKILL）并清理资源

当第二阶段出现超时或上下文取消时，会导致容器状态不一致——虽然容器进程已停止，但containerd内部状态未更新，进而引发后续操作失败。

根因分析

通过社区讨论和代码审查，发现该问题涉及多个层面的交互：

1. 状态同步问题（核心）

   • Containerd 1.7.15版本存在状态同步缺陷，当waitContainerStop()超时后，未能正确触发cleanupUnknownContainer()流程
   • 导致容器卡在"stopped but not removed"的中间状态

2. Runc兼容性问题

   • 旧版runc（1.1.12）与containerd交互时存在进程状态上报延迟
   • 在高压场景下可能丢失容器停止事件

3. 资源竞争条件

   • 高频创建/删除操作导致containerd任务队列堆积
   • 部分停止请求因上下文超时被丢弃

解决方案

经过验证的完整修复方案：

1. 版本升级

   • Containerd必须升级至≥1.7.22版本（包含状态同步修复）
   • 配套升级runc至≥1.1.14版本

2. 配置优化

   [plugins."io.containerd.grpc.v1.cri".containerd]
     stop_timeout = "60s"  # 适当延长超时时间
   

3. 应急处理 对于已出现问题的节点：

   # 获取容器状态详情
   ctr -n k8s.io task ls | grep <container_id>
   
   # 收集诊断信息（需root权限）
   kill -10 $(pidof containerd)  # 生成堆栈日志到/tmp/
   journalctl -u containerd > containerd.log
   

预防措施

1. 压力测试时采用分批次操作（建议每次不超过20个Pod）
2. 监控containerd的stop_container指标异常
3. 定期维护时执行systemctl restart containerd预防状态累积

技术启示

容器运行时状态的精确管理是分布式系统的关键挑战。该案例揭示了：

• 状态机实现必须考虑所有异常路径
• 超时处理需要与上层编排系统协同设计
• 压力测试应覆盖资源竞争场景

建议企业在生产环境采用LTS版本的容器运行时，并建立版本升级验证流程。对于关键业务系统，可考虑实现自动化的容器状态修复机制。