Amazon EKS AMI中containerd配置修改的最佳实践

背景介绍

在Amazon EKS节点上，containerd作为容器运行时，其配置文件/etc/containerd/config.toml的管理方式在近期AMl版本中发生了变化。许多用户在尝试修改containerd配置时遇到了节点无法加入集群的问题，特别是在需要保留解压后的容器镜像层(discard_unpacked_layers=false)的场景下。

问题分析

在早期Amazon EKS AMI版本中，用户可以通过简单的sed命令修改默认的containerd配置文件。然而，从amazon-eks-node-1.29-v20240202版本开始，这种修改方式变得不可靠，主要原因有：

1. EKS AMI现在构建时默认不修改containerd的基础配置，导致默认配置文件可能全是注释内容
2. EKS bootstrap脚本会动态生成最终的containerd配置，覆盖用户修改
3. containerd的配置合并机制会完全覆盖整个配置节而非合并单个键值

解决方案演进

1. 直接修改模板文件（不推荐）

sed -i 's/discard_unpacked_layers = true/discard_unpacked_layers = false/g' /etc/eks/containerd/containerd-config.toml

这种方法虽然简单，但存在明显缺陷：

• 依赖EKS内部实现细节，非常脆弱
• 可能与其他工具(如NVIDIA设备插件)的配置修改冲突
• 在AMI更新时容易失效

2. 使用containerd的imports功能（推荐方案）

从较新版本开始，Amazon EKS AMI支持通过/etc/containerd/config.d/目录下的配置文件来覆盖默认配置。这是目前最可靠的配置修改方式：

1. 创建自定义配置文件

mkdir -p /etc/containerd/config.d
cat <<EOF > /etc/containerd/config.d/spegel.toml
version = 2
[plugins."io.containerd.snapshotter.v1.overlayfs"]
  discard_unpacked_layers = false
EOF

2. 确保文件权限正确

chmod 644 /etc/containerd/config.d/spegel.toml

这种方式的优势：

• 不依赖EKS内部实现细节
• 配置清晰明确，易于维护
• 与其他工具的配置修改兼容
• 在AMI更新时更加稳定

技术原理深入

containerd的配置系统采用"最后写入胜出"的原则。当使用imports功能时：

1. 主配置文件(/etc/containerd/config.toml)首先被加载
2. 然后按字母顺序加载config.d目录下的配置文件
3. 对于相同配置节，后加载的会完全覆盖之前的配置

这种机制虽然简单高效，但也意味着：

• 无法实现配置节的深度合并
• 每个配置文件需要包含完整的配置节结构
• 顺序依赖可能导致意外覆盖

最佳实践建议

1. 对于生产环境，始终使用imports方式修改配置
2. 保持每个配置文件的单一职责原则
3. 为配置文件使用有意义的名称(如00-base.toml,10-network.toml)
4. 在节点部署后验证实际生效的配置：

containerd config dump

5. 对于需要深度合并的场景，可以考虑使用配置模板工具如gomplate或jsonnet

总结

Amazon EKS AMI对containerd配置的管理方式经历了演进，从早期的直接修改到现在的imports机制。理解这一变化背后的技术原理，采用推荐的配置覆盖方式，可以确保节点配置的可靠性和可维护性。特别是在需要保留容器镜像层等特殊场景下，正确使用config.d目录的配置覆盖功能是保障集群稳定运行的关键。