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

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

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

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

背景

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

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

ImageApparate(幻影)

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

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

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

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

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

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

基于此前提,在兼容OCI V1的框架下,TCR 推出了 ImageApparate(幻影) 容器镜像加速服务。首先直接放结论,在 200 节点且镜像内容占镜像总大小的 5% 到 10%。如上所述,相比于传统的下载全部镜像的方式,ImageApparate 在容器全部启动时间上都有 5-10倍 的提升。而且本测试主要并不只是关注容器创建时间,而是继续测试了从容器启动到业务进程可以提供服务后的总体时间:

顺序读取 500MB 大文件测试了包括从容器启动后到顺序读取 500MB 文件完成后的时间

随机读取 1000 小文件测试了包括从容器启动后到随即读取 1000个 4k-16k 完成后的时间

执行 python 程序测试了包括从容器启动后加载 Python 解释器执行一段简单的 python 代码完成后的时间

执行 gcc 编译测试了包括从容器启动后执行 gcc 编译一段简单 C 代码并运行完成后的时间

ImageApparate 方案设计 传统模式的问题

自 Docker 发布以来云计算领域发生了巨大的变革,传统虚拟机逐步被容器替代。Docker 秉持 Build, Ship And Run 的理念出色的完成了容器运行时和容器镜像的设计,引领整个容器行业。但是随着时间的推移容器的 Ship And Run 在面对广泛的用户需求场景中也逐渐暴露出一些问题。

传统容器启动和镜像下载方式为:

访问镜像仓库服务获取权限认证以及获取镜像存储地址

通过网络访问镜像存储地址下载全部镜像层并解压

根据镜像的层信息使用联合文件系统挂载全部层作为rootfs,在此文件系统上创建并启动容器

img

容器镜像的设计从 Docker 发布至今一直沿用下来,并已经成为事实标准也就是我们现在使用的OCI V1,使用分层的设计大大减少空间占用,利用各类联合文件系统(Aufs、Overlayfs)将每层联合挂载起来形成一个完整的RootFS只读根文件系统,容器运行时的写入操作会在联合文件系统的最上层的读写层,非常精巧的设计。

但是,开发者和用户对于速度追求是永无止境的,随着业务上云的广泛普及,为了充分发挥云上资源的弹性能力,用户往往需要新扩出来的计算节点可以用最快的速度使用容器化的计算能力(容器启动服务可以接受流量),而此时这个全新节点就需要下载容器镜像全部的层,大大拖慢容器启动速度,在这个场景下容器镜像的分层设计没有得到充分的利用,完全失效了。

针对OCI V1容器镜像格式的一些问题社区也开始有集中的讨论,当前tar包作为OCI V1的镜像层分发格式主要有以下问题:

不同层之间的内容冗余

没有基于文件的寻址访问能力,需要全部解包后才能访问

没有并发解包能力

使用 whiteout 处理文件删除在不同存储类型中转换导致解压效率低下

TCR-Apparate OCI 制品

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpppyz.html