在Amazon EKS上秒级拉取数GB容器镜像
内容提要
本文探讨了机器学习容器镜像体积庞大（可达20-30GB）导致拉取缓慢的问题，指出瓶颈在于软件串行处理流程而非网络或硬件。通过并行分块下载和并行解压的优化方案，将拉取时间从几分钟缩短至几秒。这些改进已默认应用于EKS Auto Mode，并贡献给containerd开源项目，使整个生态系统受益。
延伸解读
瓶颈不在网络，而在软件串行处理
文章指出，在100至400 Gbps网络带宽的加速实例上，拉取30GB镜像的瓶颈并非网络或硬件，而是containerd的串行处理流程。传统流程中，下载、验证、解压、提取等六个阶段按顺序执行，导致同一时刻仅有一种资源（网络、CPU或磁盘）被利用，其余资源闲置。这一发现颠覆了“网络慢”的直觉，提醒我们在高带宽环境下，软件架构的并行化往往比硬件升级更关键。
并行化改造：从串行到并行的关键突破
优化方案聚焦于两个核心：一是通过HTTP range请求将大层分块并行下载，二是利用overlay文件系统的特性实现跨层并行解压。由于overlay snapshotter将每层独立存放，解压顺序不再依赖，从而将总解压时间从各层之和缩短为最大单层时间。这些改进已默认应用于EKS Auto Mode，并贡献给containerd上游，使整个生态受益。
ML镜像的特殊性：为何传统优化手段受限
文章对比了多种常见优化手段，如镜像瘦身、预缓存、懒加载等，但指出它们在ML场景下效果有限。GPU软件栈（如CUDA）存在压缩后3-4GB的硬性下限，且镜像跨团队构建难以整体优化；预缓存因节点频繁伸缩而失效；懒加载因ML启动时密集访问数据而几乎全量拉取。因此，直接加速拉取管线成为更有效的路径。
未来方向：并行解压与可并行验证
尽管已实现并行下载和解压，但单层解压仍为串行，完整性验证也需顺序读取。文章提出利用rapidgzip等库实现层内并行解压，以及采用BLAKE3等树形哈希实现验证与下载并行。这些改进有望进一步消除剩余串行阶段，使拉取时间逼近硬件极限，为多GB镜像的部署带来更大提升。
Q&A
为什么机器学习容器镜像拉取速度慢？
机器学习容器镜像通常很大，可达20-30GB，拉取慢的主要原因是软件处理流程是串行的，没有充分利用硬件资源，而不是网络或硬件本身。
在Amazon EKS上，如何将数GB容器镜像的拉取时间从几分钟缩短到几秒？
通过并行分块下载（使用HTTP range请求）和并行解压，将拉取时间从几分钟缩短到几秒。这些改进已默认应用于EKS Auto Mode，并贡献给containerd开源项目。
传统containerd在拉取镜像时是如何处理层的？
传统containerd按顺序执行六个阶段：下载、验证、解压、提取等，每个层使用单个HTTP连接下载，且解压和提取是严格串行的，导致资源闲置。
为什么单个大层会成为镜像拉取的瓶颈？
因为镜像中的层大小不均，单个大层（可达9GB以上）需要经过所有六个阶段，而其他层可能很快完成，所以总拉取时间受限于最大的层。
有哪些常见的减少镜像拉取时间的方法？它们对ML工作负载有什么局限？
常见方法包括：减小镜像大小、镜像缓存、注册表侧优化、懒加载和P2P分发。对于ML工作负载，减小镜像大小受限于GPU软件栈的压缩下限；缓存因频繁重建和节点伸缩而受限；懒加载因ML镜像启动时密集访问大部分数据而效果有限；P2P分发无法解决首次冷拉取。
在EKS上如何配置containerd以启用并行下载和解压？
在AL2023上，通过nodeadm NodeConfig设置containerd配置，例如max_concurrent_downloads=20和max_concurrent_unpacks=5；在Bottlerocket上，通过settings API设置等效键。
SOCI snapshotter在镜像拉取优化中扮演什么角色？
SOCI snapshotter是containerd的插件，用于拦截和定制拉取路径，作为开发和验证并行下载和解压改进的试验场，改进后已贡献给containerd上游。
未来还有哪些优化方向可以进一步缩短镜像拉取时间？
未来优化方向包括：单层内的并行解压（如使用rapidgzip）和可并行化的完整性验证（如使用BLAKE3树状哈希），以消除剩余的串行阶段。
