Amazon EKS AMI中containerd异常重启导致Pod初始化失败问题分析

问题现象

在使用Amazon EKS GPU节点(AMI版本amazon-eks-gpu-node-1.29-v20240227)时，用户报告containerd服务会突然停止响应，随后systemd自动重启containerd服务。在此过程中，部分容器无法正常启动，kubelet日志中会出现"connection reset by peer"错误。

问题背景

该问题发生在AWS EKS环境中，使用g4dn.xlarge实例类型，运行Kubernetes 1.29版本。节点上部署了NVIDIA GPU Operator v23.9.1来管理GPU资源。当containerd服务异常重启时，新创建的容器会陷入初始化失败状态。

技术分析

从日志中可以观察到几个关键现象：

1. containerd服务在运行过程中突然停止响应，systemd检测到服务异常后自动重启
2. 重启过程中，kubelet与containerd的socket连接被重置，导致容器启动失败
3. 日志中显示containerd正在处理GPU相关的容器操作，包括NVIDIA设备插件和DCGM exporter
4. 系统使用的是较旧的"io.containerd.runtime.v1.linux"运行时，该运行时在containerd v1.4后已被标记为弃用

根本原因

经过深入分析，问题根源在于NVIDIA GPU Operator与Amazon EKS GPU AMI的兼容性问题：

1. Amazon EKS GPU AMI已经内置了对NVIDIA GPU的支持，包括预配置的containerd运行时设置
2. GPU Operator会尝试修改containerd配置以使用NVIDIA特定的运行时(runc shim/fork)
3. 这种重复配置导致containerd运行时不稳定，特别是在处理GPU相关容器时
4. containerd服务崩溃后，systemd自动重启服务，但部分容器状态已经不一致

解决方案

针对这一问题，推荐以下解决方案：

1. 移除GPU Operator：由于Amazon EKS GPU AMI已经提供了完整的GPU支持，不需要额外安装GPU Operator。移除后系统稳定性显著提升。

2. 监控containerd健康状态：可以设置额外的监控来检测containerd服务状态，及时发现并处理异常情况。

3. 升级containerd配置：考虑将运行时配置从弃用的"io.containerd.runtime.v1.linux"升级到推荐的"io.containerd.runc.v2"。

最佳实践

对于在Amazon EKS上使用GPU实例的用户，建议：

1. 直接使用Amazon EKS GPU优化的AMI，避免安装额外的GPU管理组件
2. 定期更新节点AMI以获取最新的稳定性修复和性能优化
3. 监控系统日志，特别是containerd和kubelet的交互情况
4. 在部署生产工作负载前，充分测试GPU相关功能的稳定性

通过遵循这些实践，可以确保GPU工作负载在EKS环境中的稳定运行。