ImageApparate(幻影)镜像加速服务让镜像分发效率提升 5-10 倍

作者介绍

李昂，腾讯高级开发工程师，主要关注容器存储和镜像存储相关领域，目前主要负责腾讯容器镜像服务和镜像存储加速系统的研发和设计工作。

李志宇，腾讯云后台开发工程师。负责腾讯云 TKE 集群节点和运行时相关的工作，包括 containerd、docker 等容器运行时组件的定制开发和问题排查。

洪志国，腾讯云架构师，负责 TKE 产品容器运行时，K8s，容器网络，mesh 数据面等基础组件研发。

背景

在业务普遍已经完成容器化的大环境下，不同的业务场景对于容器启动需求也是不同的，在离线计算和一些需要快速增加计算资源（伸缩组）的在线服务场景下，往往对于容器的启动速度有较高的要求。

在容器启动的整个周期中镜像拉取的时间往往占据 70% 甚至更多。据统计，某离线计算业务因容器镜像较大，每次扩容上千 Pod 耗时高达 40 分钟。镜像分发成为容器快速弹性伸缩的主要障碍。

ImageApparate(幻影)

为了解决这个问题，腾讯云容器服务 TKE 团队开发了下一代镜像分发方案 ImageApparate(幻影), 将大规模大镜像分发的速度提升 5-10倍。

应对既有 Docker 下载镜像模式带来的问题，社区新方案的讨论主要在镜像数据的延迟加载(Lazy-Pull)和新镜像格式的设计不再以层为最小单位，而是 chuck 或者镜像内文件本身。

不过，目前看OCI V2离我们依然还很远，当前我们通过何种方式来应对这类场景呢？

回到问题本身，当前OCI V1和容器运行时交互逻辑需要先下载完整镜像才能运行容器，但是容器启动和运行时到底会使用镜像内的多少内容，这篇论文 FAST '16 统计了 DockerHub 中一些常见的官方镜像在其使用启动后需要读取的数据量，得出的结论是仅有平均 6.4% 的内容需要读取。也就是说镜像中的大部分内容可能在容器的整个生命周期内根本不需要，那么如果我们只加载 6% 的数据就可以大幅减少镜像拉取时间，从而加速容器启动速度，这也就为后续的优化提供了理论前提。

因此减少容器启动时间的重点就在容器的 rootfs 即容器镜像的获取上。

基于此前提，在兼容OCI V1的框架下，TCR 推出了 ImageApparate(幻影) 容器镜像加速服务。首先直接放结论，在 200 节点且镜像内容占镜像总大小的 5% 到 10%。如上所述，相比于传统的下载全部