首页 / 更多教程 / 阿里巴巴开源容器镜像加速技术
阿里巴巴开源容器镜像加速技术
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了阿里巴巴开源容器镜像加速技术，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含9162字，纯文字阅读大概需要14分钟。
内容图文
近日阿里巴巴开源了其云原生容器镜像加速技术（https://github.com/alibaba/accelerated-container-image），其推出的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等人的研究[2]表明，拉取镜像占用了容器启动时间的76%，而只有6.4%的时间用来读取数据。因此，支持On-demand Read技术的镜像，已经成为默认的潮流风向。Google提出的stargz[3]格式，其全称是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整体架构如图，以下分别介绍各个组件
containerd snapshotter
containerd自1.4版起，开始初步支持一些启动远程镜像的功能，并且k8s已经明确将放弃Docker作为运行时的支持。所以DADI开源版本选择优先支持containerd生态，之后再支持Docker。
snapshotter的核心功能是实现抽象的服务接口，用于容器rootfs的挂载和卸载等操作。它的设计替代了在Docker 早期版本称之为graphdriver的模块，使得存储驱动更加简化，同时兼容了块设备快照与overlayfs。
DADI提供的overlaybd-snapshotter一方面能让容器引擎支持新的overlaybd格式的镜像，即将虚拟块设备挂载到对应的目录，另一方面也兼容传统OCI tar格式镜像，让用户继续以overlayfs运行普通容器。
iSCSI target
iSCSI是一种被广泛支持的远程块设备协议，稳定成熟性能高，遇到故障可恢复。overlaybd模块作为iSCSI协议的后端存储，即使程序意外crash，重新拉起即可恢复。而基于文件系统的镜像加速方案，例如stargz，则无法恢复。
iSCSI target是overlaybd的运行时载体。在本项目中，我们实现了两种target模块：第一种是基于开源项目tgt[4]，由于其拥有backing store机制，可以将代码编译成动态链接库以便运行时加载；第二种是基于Linux内核的LIO SCSI target（又称为TCMU）[5]，整个target运行在内核态，可以比较方便地输出虚拟块设备。
ZFile
ZFile是我们提供的一种支持在线解压的数据压缩格式。它将源文件按固定大小的block size切分，各数据块进行单独压缩，同时维护一个jump table，记录了各数据块在ZFile中的物理偏移位置。如需从ZFile中读数据，只要查找索引找到对应位置，并仅解压缩相关的data block即可。
ZFile支持各种有效的压缩算法，包括lz4，zstd等，它解压速度极快，开销低，可以有效节省存储空间和数据传输量。实验数据表明，按需解压远程的ZFile数据，性能高于加载非压缩数据，这是因为传输节省的时间，大于解压的额外开销。
overlaybd支持将layer文件导出成ZFile格式。
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%[6]，带来了全新的Serverless使用体验。
总结展望
阿里巴巴开源的DADI容器加速项目以及其推出的overlaybd镜像格式，有助于应对新时代下容器对快速启动的需求。项目组未来将协同社区一起，加快对接主流工具链，积极参与新镜像格式标准制定，目标是让overlaybd成为OCI远程镜像格式的标准之一。
欢迎大家参与开源项目，一起贡献力量！
后续工作
Artfacts Manifest
OCI Image的v1 Manifest格式描述能力有限，无法满足远程镜像需求。目前v2的讨论没有实质进展，推翻v1也不现实。但是，可以借助OCI Artfacts Manifest使用Additional Descriptor来描述原始数据，兼容性上有所保证，用户更容易接受。Artfacts也是OCI/CNCF在推广的项目，DADI未来计划拥抱Artfacts并实现PoC。
开放对多种文件系统的支持
DADI本身支持用户根据需要选择合适的文件系统来构建镜像，但是目前尚未开放相应的接口，默认使用了ext4文件系统。我们未来将完善相关接口并放开此功能，由用户根据自身需要，决定使用什么文件系统。
Buildkit工具链
目前用户可以通过buildkit外挂snapshotter来构建镜像，未来将进一步完善，形成完整工具链。
数据预取
在容器启动后对I/O模式进行记录，后续启动同一镜像时便可以重放该记录，对数据进行预取，避免临时请求Registry，这样容器的冷启动时间将继续缩短一半以上。理论上所有无状态或幂等容器都可以进行录制和重放。
参考文献
[1] https://www.usenix.org/conference/atc20/presentation/li-huiba
[2] https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter
[3] https://github.com/containerd/stargz-snapshotter
[4] http://stgt.sourceforge.net/
[6] https://developer.aliyun.com/article/781992
内容总结
以上是互联网集市为您收集整理的阿里巴巴开源容器镜像加速技术全部内容，希望文章能够帮你解决阿里巴巴开源容器镜像加速技术所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。