Amazon EKS AMI 中预拉取容器镜像的实践与优化

前言

在 Amazon EKS 环境中，容器镜像的拉取时间往往成为影响应用启动速度的关键因素。特别是对于大型机器学习镜像，每次节点扩容时都需要重新拉取镜像，这显著增加了应用响应时间。本文将探讨如何在 Amazon EKS AMI 中预拉取容器镜像的实践方法及其优化效果。

技术背景

Amazon EKS 使用 containerd 作为容器运行时，其镜像存储在特定的命名空间中。默认情况下，Kubernetes 使用 k8s.io 命名空间来管理容器镜像。通过 Amazon EC2 Image Builder，我们可以在 AMI 构建阶段预先拉取所需的容器镜像，从而减少节点启动后的镜像拉取时间。

实现方案

1. Image Builder 模板设计

通过创建自定义的 Image Builder 模板，在 AMI 构建阶段执行容器镜像的预拉取操作。以下是关键步骤的实现：

name: ml-image-pull
description: 预拉取机器学习容器镜像
schemaVersion: 1.0

phases:
  - name: build
    steps:
      - name: pull-ml-image
        action: ExecuteBash
        inputs:
          commands:
            - password=$(aws ecr get-login-password --region us-west-2)
            - sudo ctr --namespace k8s.io images pull --user AWS:$password account_id.dkr.ecr.us-west-2.amazonaws.com/ml-image:latest > /dev/null
            - sudo ctr --namespace k8s.io images list | grep ml-image

2. 关键参数说明

• --namespace k8s.io：确保镜像被拉取到 Kubernetes 使用的 containerd 命名空间
• --user AWS:$password：提供 ECR 认证信息
• 输出重定向：避免构建日志过大

3. 验证阶段

在测试阶段验证镜像是否成功预拉取：

  - name: test
    steps:
      - name: confirm-ml-image-pulled
        action: ExecuteBash
        inputs:
          commands:
            - set -e
            - sudo ctr --namespace k8s.io images list | grep ml-image

实践中的发现与优化

1. imagePullPolicy 的影响

预拉取的镜像能否被 Kubernetes 直接使用取决于 Pod 的 imagePullPolicy 设置：

• 当设置为 Always 时，Kubelet 会忽略本地已存在的镜像，强制重新拉取
• 设置为 IfNotPresent 时，Kubelet 会优先使用本地镜像

2. 性能考量

在实际测试中发现以下现象：

1. 节点启动时间：使用预拉取镜像的 AMI 启动的节点比标准 AMI 慢约一倍
2. 文件系统缓存：首次访问预拉取镜像中的文件时性能较差，后续访问恢复正常

3. 优化建议

1. 权衡预拉取与启动时间：评估预拉取大镜像带来的启动时间增加是否值得
2. 文件系统预热：考虑在 AMI 构建后执行文件系统预热操作
3. 镜像标签策略：使用固定版本标签而非 latest，确保一致性

总结

在 Amazon EKS 环境中预拉取容器镜像可以显著减少应用启动时间，特别是对于大型镜像场景。然而，这一优化需要综合考虑多方面因素：

1. 正确设置 imagePullPolicy
2. 评估预拉取对节点启动时间的影响
3. 关注文件系统缓存行为

通过合理的配置和测试，这一技术可以成为优化 EKS 集群性能的有效手段之一，特别是在需要频繁扩容或使用大型容器镜像的场景中。