阿里巴巴开源容器镜像加速技术
https://github.com/alibaba/accelerated-container-image),其推出的overlaybd镜像格式,相比于传统的分层tar包文件格式,实现了基于网络的按需读取,从而使得容器可以快速启动。
[1],并随后启动了开源项目,计划将技术该贡献给社区,通过建立标准并打造生态,吸引更多的开发者投入到容器及云原生性能优化这个领域上来。
背景简介
随着Kubernetes和云原生的大爆发,容器在企业内部的大规模应用已经越来越广泛。部署启动快是容器的核心优势之一,这个启动快是指本地镜像实例化的时间非常短,即“热启动”时间短。然而对于“冷启动”,即在本地无镜像的情况下,需要先从Registry下载镜像才能创建容器。业务的镜像经过长期维护和更新,无论是镜像层数还是整体大小都会达到一个较大的量级,比如可能达到数百MB或者几个GB。因此生产环境中,容器的冷启动往往耗时数分钟,并且随规模扩大会导致Registry因集群内网络拥堵而无法快速地下载镜像。
例如,在之前某年的双十一活动中,阿里内部一个应用因为容量不足触发紧急扩容,但因并发量过大,整体扩容耗时较长,这期间对部分用户的使用体验造成了影响。而到了2019年,随着DADI的部署上线,新镜像格式的容器在“镜像拉取+容器启动”上耗费的总时间比普通容器缩短了5倍,且p99长尾时间更是比后者快了17倍。
[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,则无法恢复。
[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领导者象限。
[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,这样容器的冷启动时间将继续缩短一半以上。理论上所有无状态或幂等容器都可以进行录制和重放。
本文为阿里云原创内容,未经允许不得转载。
相关推荐
- 为什么 K8s 在阿里能成功?| 问底中国 IT 技术演进 容器在阿里巴巴的发展历程 为什么 K8s 在阿里能成功 阿里巴巴的 K8s 应用情况 基于 K8s 的云原生改造实践 面向终态升级 自愈能力升级 不可变基础设施 总结与展望 云原生实践峰会即将开幕
- 阿里巴巴开源容器镜像加速技术
- CentOS7.6部署阿里巴巴开源的pouch容器管理工具实战
- pip 加速下载 一、问题 二、使用样例 三、国内知名开源镜像站
- docker入门 一条命令加速 这条命令其实就是改了docker的一个配置文件里面的注册镜像地址, 可以查看一下 注意里面的json数据有语法错误,要把后面的逗号去掉 e80是容器id 如果没有centos镜像,会自动下载 74a为容器名 语法是: docker tag 仓库名 新仓库名
- 业界首个机密计算容器运行时—Inclavare Containers正式进入CNCF! 首个机密计算开源容器运行时- Inclavare Containers 五大特色功能,为用户数据保驾护航 加速云原生基础设施拥抱机密计算
- 阿里巴巴为什么能抗住90秒100亿?看完这篇你就明白了! 3.2第一次演进:Tomcat与数据库分开部署 3.3 第二次演进:引入本地缓存和分布式缓存 3.4 第三次演进:引入反向代理实现负载均衡 3.5 第四次演进:数据库读写分离 3.6 第五次演进:数据库按业务分库 3.7 第六次演进:把大表拆分为小表 3.8 第七次演进:使用LVS或F5来使多个Nginx负载均衡 3.9 第八次演进:通过DNS轮询实现机房间的负载均衡 3.10 第九次演进:引入NoSQL数据库和搜索引擎等技术 3.11 第十次演进:大应用拆分为小应用 3.12 第十一次演进:复用的功能抽离成微服务 3.13 第十二次演进:引入企业服务总线ESB屏蔽服务接口的访问差异 3.14 第十三次演进:引入容器化技术实现运行环境隔离与动态服务管理 3.15 第十四次演进:以云平台承载系统
- 基础软件只有在云上做才有变的机会,中国的基础软件一直做不起来,原因是缺乏与用户互动的机会。阿里巴巴推动“去IOE”,正从“商业软件”向“开源软件”,再向”自主技术+云计算”的路径上演变。
- Serverless 如何在阿里巴巴实现规模化落地? 一、Serverless 规模化落地集团的成果 二、两大背景,两大优势 – 加速 Serverless 落地 三、Serverless 落地场景 – 前端轻应用 四、技术输出,拓展新场景
- Docker入门 Docker基本组成 安装Docker 阿里云镜像加速 HelloWorld流程 底层原理 Docker的常用命令 容器命令 常用其他命令 小结 作业练习 Docker镜像讲解 容器数据卷 DockerFile Docker网络 IDEA整合Docker
- Eclipse中SVN的安装步骤(两种)和用法
- SpringBoot题目