Amazon EKS AMI 中containerd版本管理的最佳实践

在构建基于Amazon EKS AMI的自定义节点镜像时，containerd容器运行时的版本管理是一个需要特别注意的技术点。本文将通过一个实际案例，深入分析containerd版本控制的关键技术细节。

问题现象

用户在使用v20240828版本的Amazon EKS AMI构建自定义AL2023镜像时，发现节点上运行的containerd版本为1.7.20，而非预期的1.7.11版本。这一现象表明在自定义镜像构建过程中，containerd被意外升级了。

根本原因分析

经过技术排查，发现问题的根源在于AL2023操作系统独特的版本化仓库机制。与传统的AL2使用yum versionlock插件锁定特定包版本不同，AL2023采用了版本化仓库的设计理念。

在2023.5.20240805版本的AL2023更新中，官方仓库将containerd升级到了1.7.20版本。当用户在自定义镜像构建过程中执行dnf update -y命令时，系统会从最新的仓库版本获取containerd，导致版本不一致。

解决方案

要确保containerd版本与EKS AMI保持一致，建议采取以下措施：

1. 移除全局更新命令：在自定义镜像构建脚本中，应避免使用dnf update -y这样的全局更新命令，以防止关键组件被意外升级。

2. 明确指定依赖版本：对于必须更新的软件包，应该明确指定版本号，避免隐式依赖最新版本。

3. 利用版本化仓库特性：理解并合理利用AL2023的版本化仓库机制，确保组件版本的一致性。

技术实践建议

对于需要在EKS节点上安装额外软件的场景，推荐以下最佳实践：

1. 分层构建：先基于官方AMI构建基础层，再添加自定义组件，保持核心组件不变。

2. 版本验证：在构建完成后，使用ctr version命令验证containerd版本是否符合预期。

3. 变更控制：建立完善的变更管理流程，记录每次构建的组件版本信息。

通过以上措施，可以确保自定义EKS节点的稳定性和一致性，避免因组件版本不匹配导致的兼容性问题。