作者 | 陈博
起源 | 阿里巴巴云原生公众号

近日阿里巴巴开源了其云原生容器镜像减速技术，它推出的 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，这样容器的冷启动工夫将持续缩短一半以上。实践上所有无状态或幂等容器都能够进行录制和重放。