简介： 近日阿里巴巴开源了其云原生容器镜像加速技术，它推出的 overlaybd 镜像格式，相比于传统的分层 tar 包文件格式，实现了基于网络的按需读取，从而使得容器可以快速启动。
作者 |陈博
来源 | 阿里巴巴云原生公众号
近日阿里巴巴开源了其云原生容器镜像加速技术，它推出的 overlaybd 镜像格式，相比于传统的分层 tar 包文件格式，实现了基于网络的按需读取，从而使得容器可以快速启动。
该技术方案原本是阿里云内部 DADI 项目的一部分， DADI 是 Data Accelerator for Disaggregated Infrastructure 的缩写，旨在为计算存储分离架构提供各种可能的数据访问加速技术。镜像加速是 DADI 架构在容器及云原生领域的一次突破性尝试，该技术自 2019 年投产以来，已在线上部署了大量机器，累计启动容器次数超过 10 亿，支持了阿里巴巴集团及阿里云的多个业务线，极大提高了应用的发布和扩容效率。2020 年，团队在国际顶级会议发表了论文"DADI: Block-Level Image Service for Agile and Elastic Application Deployment. USENIX ATC'20"[1]，并随后启动了开源项目，计划将技术该贡献给社区，通过建立标准并打造生态，吸引更多的开发者投入到容器及云原生性能优化这个领域上来。
背景简介
随着 Kubernetes 和云原生的大爆发，容器在企业内部的大规模应用已经越来越广泛。部署启动快是容器的核心优势之一，这个启动快是指本地镜像实例化的时间非常短，即“热启动”时间短。然而对于“冷启动”，即在本地无镜像的情况下，需要先从 Registry 下载镜像才能创建容器。业务的镜像经过长期维护和更新，无论是镜像层数还是整体大小都会达到一个较大的量级，比如可能达到数百 MB 或者几个 GB。因此生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥堵而无法快速地下载镜像。
例如，在之前某年的双十一活动中，阿里内部一个应用因为容量不足触发紧急扩容，但因并发量过大，整体扩容耗时较长，这期间对部分用户的使用体验造成了影响。而到了 2019 年，随着 DADI 的部署上线，新镜像格式的容器在“镜像拉取+容器启动”上耗费的总时间比普通容器缩短了 5 倍，且 p99 长尾时间更是比后者快了 17 倍。
如何处理存储在远端的镜像数据，这是解决容器冷启动慢这个问题的核心点。历史上业界对这一问题做出的尝试有：使用块存储或者NAS保存容器镜像，实现按需读取；使用基于网络的分发技术（如 p2p），将镜像从多个源头下载、或者提前预热到主机上，避免出现网络单点瓶颈。近年来，针对新镜像格式的讨论也逐渐被提上议题，根据 Harter 等人的研究表明，拉取镜像占用了容器启动时间的 76%，而只有 6.4% 的时间用来读取数据。因此，支持 On-demand Read 技术的镜像，已经成为默认的潮流风向。Google 提出的 stargz 格式，其全称是 Seekable tar.gz，顾名思义，可以有选择地从存档中搜寻并提取特定的文件，无需扫描或者解压整个镜像。stargz 旨在提高镜像拉取的性能，其延迟拉取技术（lazy-pull）不会拉取整个镜像文件，实现了按需读取。为了进一步提高运行时效率，stargz 又推出了一个 containerd 的 snapshotter 插件，在存储层面对 I/O 做了进一步优化。
在容器的生命周期中，镜像就绪后需要挂载（mount），而分层镜像挂载的核心技术便是 overlayfs，它以一种堆叠的形式将下层的多个 layer 文件合并，并向上暴露出一个统一的只读文件系统。类比上文提到的块存储和 NAS，一般可以通过快照的形式进行分层堆叠，而跟 stargz 绑定的 CRFS，也可以看做是 overlayfs 的另一种实现。
新镜像格式
DADI 没有直接使用 overlayfs，或者说，它只是借鉴了 overlayfs 和早期联合文件系统（union filesystem）的思想，但提出了一种全新的基于块设备的分层堆叠技术，称之为 overlaybd，它为容器镜像提供了一系列基于块的合并数据视图。overlaybd 的实现十分简单，因此很多之前想做而不能做的事都可以成为现实；而实现一个完全 POSIX 兼容的文件系统接口则充满挑战，并可能存在 bug，这点从各个主流文件系统的发展历史上就可以看出。
除了简单以外，overlaybd 对比 overlayfs 的其他优点有：
- 避免多层镜像导致的性能下降，如 overlayfs 模式下大文件的更新会触发跨层引用复制，系统必须先将文件复制到可写层；或者创建硬链接速度很慢等问题。
- 可以方便地采集 block 级别的 I/O 模式，进行录制以及重放，从而预取数据，进一步加速启动。
- 用户的文件系统和宿主机 OS 可以灵活选择，如支持 Windows NTFS。
- 可以使用有效的编解码器进行在线解压缩。
- 可以下沉到云中的分布式存储（如 EBS）中，镜像系统盘可以跟数据盘使用同一套存储方案。
- overlaybd 具有天然的可写层支持（RW），只读挂载甚至可以成为历史。
overlaybd 原理
为了理解 overlaybd 的原理，首先需要了解容器镜像的分层机制。容器镜像由多个增量 layer 文件组成，在使用时进行叠加，这样在镜像分发时只需要对 layer 文件进行分发。每一层实质上都是与上一层的差异（包括文件的添加，修改或删除）的压缩包。容器引擎可以通过其 storage driver，按照约定的方式将差异叠加起来，然后以 Read-Only 的模式挂载到指定目录，该目录即称为 lower_dir；而以 Read/Write 模式挂载的可写层，挂载目录则一般称为 upper_dir。
请注意，overlaybd 本身没有文件的概念，它只是将镜像抽象为虚拟块设备，并在其上装载常规的文件系统。当用户应用读取数据时，该读取请求首先由常规的文件系统处理，将请求转换为虚拟块设备的一次或多次读取。这些读取请求会被转发到用户态的接收程序，即 overlaybd 的运行时载体，最后转换为对一个或多个 layer 的随机读取。
与传统镜像一样，overlaybd 在内部仍然保留着 layer 分层的结构，但每层的内容都是文件系统变更差异对应的一系列 data block。overlaybd 向上提供了一个合并视图，对 layer 的叠加规则很简单，即对于任意一个 data block，总是使用最后的变更，在 layer 中未发生变更的块均视为全零块；向下又提供了将一系列 data block 导出成一个 layer 文件的功能，该文件高密度非稀疏、且可索引。因此，对块设备某个连续 LBA 范围进行读操作，可能包含了原本属于多层的小块数据段，我们将这些小块数据段称为 segment。从 segment 的属性中找到层号，便能够继续映射到对这层的 layer 文件的读取上来。传统的容器镜像可以将它的 layer 文件保存在 Registry 或者对象存储上，那么 overlaybd 镜像自然也可以。
为了更好的兼容性，overlaybd 在 layer 文件的最外层，包装了一层 tar 文件的头和尾，这样伪装成一个 tar 文件。由于 tar 内部仅一个文件，不影响按需读取。目前无论是 docker、containerd 或者 buildkit，对镜像的下载或上传默认都有 untar 和 tar 的流程，不侵入代码是无法逾越的，所以增加 tar 伪装有利于兼容性和流程的统一，例如在镜像转换、构建、或者全量下载使用时，都无需修改代码，只需提供插件即可。
整体架构
DADI 整体架构如图，以下分别介绍各个组件：
1. containerd snapshotter
containerd 自 1.4 版起，开始初步支持一些启动远程镜像的功能，并且 K8s 已经明确将放弃 Docker 作为运行时的支持。所以 DADI 开源版本选择优先支持 containerd 生态，之后再支持 Docker。
snapshotter 的核心功能是实现抽象的服务接口，用于容器 rootfs 的挂载和卸载等操作。它的设计替代了在 Docker 早期版本称之为 graphdriver 的模块，使得存储驱动更加简化，同时兼容了块设备快照与 overlayfs。
DADI 提供的 overlaybd-snapshotter 一方面能让容器引擎支持新的 overlaybd 格式的镜像，即将虚拟块设备挂载到对应的目录，另一方面也兼容传统 OCI tar 格式镜像，让用户继续以 overlayfs 运行普通容器。
2. iSCSI target
iSCSI 是一种被广泛支持的远程块设备协议，稳定成熟性能高，遇到故障可恢复。overlaybd 模块作为 iSCSI 协议的后端存储，即使程序意外 crash，重新拉起即可恢复。而基于文件系统的镜像加速方案，例如 stargz，则无法恢复。
iSCSI target 是 overlaybd 的运行时载体。在本项目中，我们实现了两种 target 模块：第一种是基于开源项目 tgt，由于其拥有 backing store 机制，可以将代码编译成动态链接库以便运行时加载；第二种是基于 Linux 内核的 LIO SCSI target（又称为 TCMU），整个 target 运行在内核态，可以比较方便地输出虚拟块设备。
3. ZFile
ZFile 是我们提供的一种支持在线解压的数据压缩格式。它将源文件按固定大小的 block size 切分，各数据块进行单独压缩，同时维护一个 jump table，记录了各数据块在 ZFile 中的物理偏移位置。如需从 ZFile 中读数据，只要查找索引找到对应位置，并仅解压缩相关的 data block 即可。
ZFile 支持各种有效的压缩算法，包括 lz4，zstd 等，它解压速度极快，开销低，可以有效节省存储空间和数据传输量。实验数据表明，按需解压远程的 ZFile 数据，性能高于加载非压缩数据，这是因为传输节省的时间，大于解压的额外开销。
overlaybd 支持将 layer 文件导出成 ZFile 格式。
4. cache
正如上文所说，layer 文件保存在 Registry 上，容器对块设备的读 I/O 会映射到对 Registry 的请求上（这里利用到了 Registry 对 HTTP Partial Content 的支持）。但是由于 cache 机制的存在，这种情形不会一直存在。cache 会在容器启动后的一段时间后自动开始下载 layer 文件，并持久化到本地文件系统。如果 cache 命中，则读 I/O 就不会再发给 Registry，而是读本地。
行业领先
3 月 25 日，权威咨询机构 Forrester 发布 2021 年第一季度 FaaS 平台（Function-As-A-Service Platforms）评估报告，阿里云凭借产品能力全球第一的优势脱颖而出，在八个评测维度中拿到最高分，成为比肩亚马逊 AWS 的全球 FaaS 领导者。这也是首次有国内科技公司进入 FaaS 领导者象限。
众所周知，容器是 FaaS 平台的承载基础，而容器启动速度更是决定了整个平台的性能与响应延迟。DADI 助力阿里云函数计算产品，大幅度缩短容器启动时间 50%~80%，带来了全新的 Serverless 使用体验。
总结展望
阿里巴巴开源的 DADI 容器加速项目以及其推出的 overlaybd 镜像格式，有助于应对新时代下容器对快速启动的需求。项目组未来将协同社区一起，加快对接主流工具链，积极参与新镜像格式标准制定，目标是让 overlaybd 成为 OCI 远程镜像格式的标准之一。
欢迎大家参与开源项目，一起贡献力量！
后续工作
1. Artfacts Manifest
OCI Image 的 v1 Manifest 格式描述能力有限，无法满足远程镜像需求。目前 v2 的讨论没有实质进展，推翻 v1 也不现实。但是，可以借助 OCI Artfacts Manifest 使用 Additional Descriptor 来描述原始数据，兼容性上有所保证，用户更容易接受。Artfacts 也是 OCI/CNCF 在推广的项目，DADI 未来计划拥抱 Artfacts 并实现 PoC。
2. 开放对多种文件系统的支持
DADI 本身支持用户根据需要选择合适的文件系统来构建镜像，但是目前尚未开放相应的接口，默认使用了 ext4 文件系统。我们未来将完善相关接口并放开此功能，由用户根据自身需要，决定使用什么文件系统。
3. Buildkit 工具链
目前用户可以通过 buildkit 外挂 snapshotter 来构建镜像，未来将进一步完善，形成完整工具链。
4. 数据领取
在容器启动后对 I/O 模式进行记录，后续启动同一镜像时便可以重放该记录，对数据进行预取，避免临时请求 Registry，这样容器的冷启动时间将继续缩短一半以上。理论上所有无状态或幂等容器都可以进行录制和重放。