Amazon EKS AMI中NVIDIA容器工具包配置错误问题分析

Amazon EKS AMI近期发现一个与NVIDIA容器工具包(nvidia-container-toolkit)相关的配置问题，该问题影响了节点上containerd的运行配置。本文将详细分析该问题的成因、影响范围以及解决方案。

问题背景

在Amazon EKS AMI的v20241106版本中，NVIDIA容器工具包1.17.0版本存在一个配置生成错误。这个错误导致containerd的配置文件被不正确地重写，移除了EKS默认的一些重要配置项。

问题表现

受此问题影响的节点会表现出以下症状：

1. pause容器镜像问题：containerd会使用默认的pause容器镜像(registry.k8s.io/pause:3.5)，而不是EKS提供的区域ECR镜像。如果节点无法访问registry.k8s.io，将导致无法创建Pod。

2. cgroup驱动配置错误：containerd使用了错误的cgroup驱动配置，导致Pod被放置在错误的cgroup树位置，这可能会影响监控数据的准确性。

3. 私有镜像仓库配置丢失：部分用户报告称，配置文件移除了私有镜像仓库的认证路径配置，导致节点无法从私有仓库拉取容器镜像。

问题根源

该问题的根本原因是NVIDIA容器工具包1.17.0版本在生成containerd配置时，没有正确处理现有的配置项，而是进行了全量覆盖。具体来说，工具包在更新配置时没有保留EKS原有的重要默认配置。

解决方案

NVIDIA已经修复了这个问题，并在1.17.1版本中发布了修复补丁。Amazon EKS团队随后在v20241109版本的AMI中集成了修复后的工具包版本。

对于已经受影响的集群，建议采取以下措施：

1. 将节点AMI升级到v20241109或更高版本
2. 如果暂时无法升级，可以手动修复containerd配置文件，恢复以下关键配置项：
   • 正确的pause容器镜像路径
   • 适当的cgroup驱动设置
   • 私有镜像仓库的认证配置路径

最佳实践

为避免类似问题，建议：

1. 在升级节点前，备份重要的配置文件
2. 在测试环境中验证新版本AMI的兼容性
3. 监控节点上的containerd日志，及时发现配置问题
4. 确保节点有适当的网络访问权限，作为临时缓解措施

总结

这次事件提醒我们基础设施组件的相互依赖性。即使是单个组件的版本更新，也可能对系统其他部分产生连锁反应。保持组件版本的最新状态，同时建立完善的配置管理和监控机制，是维护Kubernetes集群稳定性的关键。