Containerd容器运行时中Pod无法正常退出的问题分析与解决

在Kubernetes集群升级到EKS 1.31版本后，用户报告了一个关于containerd容器运行时的典型问题：工作负载Pod在完成任务后无法正常退出，而是进入了NotReady状态。本文将从技术角度深入分析该问题的成因、诊断方法以及解决方案。

问题现象

用户在使用Argo Workflow时发现，任务Pod在完成执行后没有按预期进入Completed状态，而是持续显示为NotReady状态。通过查看containerd日志，发现关键错误信息：

failed rootfs umount: failed to unmount target /run/containerd/io.containerd.runtime.v2.task/k8s.io/[容器ID]/rootfs: device or resource busy

这表明containerd在尝试卸载容器根文件系统时遇到了"设备或资源忙"的错误，导致容器清理过程无法完成。

根本原因分析

经过深入调查，发现问题可能由以下几个因素导致：

1. 文件系统挂载点被占用：这是最直接的错误表现，表明某些进程仍然在使用容器的挂载点空间。在Linux系统中，当一个挂载点被进程占用时，系统会拒绝卸载操作以保护数据完整性。

2. 监控工具干扰：用户环境中运行的Kubeshark等容器监控工具可能会挂载节点根文件系统并保持文件打开状态。这类工具为了实现深度监控，往往会侵入容器命名空间，可能导致资源锁定问题。

3. containerd版本兼容性：虽然用户使用的是1.7.23版本，但在升级到Kubernetes 1.31后，可能存在某些边缘情况下的兼容性问题。

诊断方法

当遇到此类问题时，建议采用以下诊断步骤：

1. 检查占用进程：使用fuser -m命令查看哪些进程正在使用容器挂载点：

   fuser -m /run/containerd/io.containerd.runtime.v2.task/k8s.io/[容器ID]/rootfs
   

2. 分析系统日志：除了containerd日志外，还应检查dmesg和系统日志，寻找与挂载/卸载相关的其他错误信息。

3. 环境审查：检查节点上运行的所有DaemonSet和系统Pod，特别是那些具有特权权限或需要挂载主机文件系统的组件。

解决方案

根据问题原因，可采取以下解决措施：

1. 移除干扰组件：如确认是Kubeshark等监控工具导致的问题，应考虑暂时停用或寻找替代方案。用户反馈在卸载Kubeshark后问题得到缓解。

2. 手动恢复：在紧急情况下，可以重启containerd服务来释放被锁定的资源：

   systemctl restart containerd
   

3. 版本升级：考虑升级到containerd的稳定版本，特别是针对Kubernetes 1.31测试认证的版本。

4. 配置调整：对于关键生产环境，可以调整containerd的GC（垃圾回收）策略，增加资源释放的重试次数和超时设置。

预防措施

为避免类似问题再次发生，建议：

1. 在生产环境部署前，充分测试新版本Kubernetes与容器运行时的兼容性
2. 严格控制具有主机挂载权限的工作负载
3. 建立完善的监控机制，及时发现和处理资源锁定问题
4. 定期维护和清理节点上的残留容器资源

总结

容器运行时作为Kubernetes的核心组件，其稳定性直接影响整个集群的可靠性。本次问题的分析过程展示了如何从错误信息出发，逐步定位到根本原因，并提供了针对性的解决方案。对于运维人员来说，理解容器生命周期的完整过程以及资源清理机制，是解决此类问题的关键。

在云原生技术快速发展的今天，保持组件版本的协调一致，合理控制集群中的特权工作负载，都是保障生产环境稳定运行的重要原则。