Amazon EKS AMI 中 containerd 1.7.2x 版本与 AWS VPC CNI 兼容性问题分析

问题背景

在 Amazon EKS 环境中，当用户将节点升级到 Kubernetes 1.29 版本并使用 containerd 1.7.22 或更高版本时，可能会遇到 VPC CNI 插件（aws-node）持续崩溃重启的问题。这个问题表现为节点无法进入 Ready 状态，同时 containerd 日志中会显示"cannot exec in a stopped container"的错误信息。

问题现象

当使用 containerd 1.7.22 或更高版本的 AMI 时，用户会观察到以下典型症状：

1. aws-node Pod 处于 CrashLoopBackOff 状态
2. 节点无法达到 Ready 状态
3. containerd 日志中出现如下错误：

   failed to exec in container: failed to start exec: OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
   

根本原因分析

经过深入调查，发现这个问题与 containerd 1.7.20 版本引入的行为变更有关。具体来说：

1. containerd 1.7.20 变更：该版本修改了处理 resolv.conf 文件的行为。在之前版本中，如果指定的 resolv.conf 文件为空，containerd 会回退使用主机的 /etc/resolv.conf。但从 1.7.20 开始，这一回退行为被移除。

2. 用户配置影响：许多用户在 EKS 节点的 bootstrap.sh 脚本中通过 --kubelet-extra-args 参数传递了 --resolv-conf 标志，并指向一个空文件。这种配置在旧版本中能正常工作，但在新版本中会导致 DNS 解析失败。

3. 连锁反应：DNS 解析失败会影响 VPC CNI 插件的正常运行，导致 aws-node Pod 无法完成必要的网络配置，进而引发崩溃循环。

解决方案

针对此问题，推荐采取以下解决方案：

1. 移除过时的 resolv-conf 配置：

   • 检查节点的用户数据(userdata)配置
   • 删除 bootstrap.sh 中 --kubelet-extra-args 参数里的 --resolv-conf 标志
   • 确保不再依赖这一已弃用的配置项

2. 替代方案：

   • 如果需要自定义 DNS 配置，应该直接修改主机的 /etc/resolv.conf
   • 或者使用更现代的 DNS 配置方法，如 systemd-resolved

3. 临时回退方案：

   • 如果必须暂时保持原有行为，可以降级到 containerd 1.7.19 或更早版本
   • 但这只是临时解决方案，不建议长期使用

最佳实践建议

为了避免类似问题，建议 EKS 用户：

1. 定期审查用户数据配置：特别是那些长期未变更的配置项，检查是否有已弃用的参数

2. 测试环境先行：在升级生产环境前，先在测试环境中验证新版本 AMI 的兼容性

3. 简化用户数据：保持用户数据尽可能简洁，避免不必要的自定义配置

4. 监控组件健康：特别关注核心组件如 VPC CNI 的健康状态，及时发现潜在问题

总结

这次事件凸显了基础设施组件升级时可能带来的兼容性挑战。通过理解 containerd 行为变更的本质，用户可以更有针对性地调整配置，确保 EKS 环境的稳定运行。这也提醒我们，在云原生环境中，保持配置的简洁性和现代性对于长期维护至关重要。