腾讯云：ImageApparate(幻影)镜像加速服务让镜像分

小提示：您能找到这篇{腾讯云：ImageApparate(幻影)镜像加速服务让镜像分}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的腾讯云：ImageApparate(幻影)镜像加速服务让镜像分内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">

< ">背景

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

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

< ">ImageApparate(幻影)

< ">为了解决这个问题，腾讯云容器服务TKE团队开发了下一代镜像分发方案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在面对广泛的用户需求场景中也逐渐暴露出一些问题。

< ">传统容器启动和镜像下载方式为：

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

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

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

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

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

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

< ">1.不同层之间的内容冗余

< ">2.没有基于文件的寻址访问能力，需要全部解包后才能访问

< ">3.没有并发解包能力

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

< ">TCR-Apparate OCI制品

< ">我们设计的目标是面向生产级别，在节点上同时支持镜像加速模式和普通模式，为了和正常OCI V1镜像存储解耦，我们开发了镜像附加存储IAS(ImageAttachStorage)结合镜像Manifest中的外部层类型(Foreign Layer)，可以在契合OCI V1语义下完成加速镜像的制作、上传和下载，继承原有镜像权限的同时，加速后的镜像Manifest索引以OCI制品形式存储在镜像仓库本身的存储中。

< ">在镜像格式方面为了支持按需加载和克服tar格式之前的一些缺点，ImageApparate使用了只读文件系统代替了tar格式。只读文件系统解决了镜像层内文件寻址能力同时又具备成为Rootfs可靠的性能。ImageApparate仍然使用分层的设计在Manifest外部层中直接指定附件存储地址，附加存储层IAS在下载镜像时就可以按需挂载。

< ">用户开启镜像加速功能并设置相关规则后，push镜像后ImageApparate会在后台运行如下流程：

< ">1.用户以任意符合OCI V1接口标准的客户端(包括Docker)Push镜像到TCR仓库

< ">2.TCR的镜像服务会将用户数据写入到镜像仓库本身的后端存储中，一般为COS对象存储。

< ">3.TCR的镜像服务会检查镜像加速规则，如果符合规则会给Apparate-client组件发出Webhook通知，请求转换镜像格式。

< ">4.Apparate-client组件收到通知后会把COS数据写入到IAS中，使用特定算法把此镜像的每个Layer逐个转换为支持ImageApparate挂载的Layer格式。

< ">因此，对于TCR用户来说只需要定义规则标记哪些镜像需要加速，而CI/CD的使用方式上没有任何变化，原来的开发模式顺理成章地继承下来。

< ">镜像附加存储IAS(ImageAttachStorage)

< ">顾名思义，狭义的镜像附加存储IAS是除了本身的镜像后端存储之外的数据存储地址，IAS既可以和镜像仓库的使用相同的对象存储，也可以使用NFS或者Lustre。Apparate中的镜像附加存储除了存储地址外，还包含一套插件化的接口（兼容Posix）和镜像层IAS中的布局（Layout）。IAS中每个目录代表一个Layer，这里依然会使用基于内容寻址(Content Addressable)复用内容相同层，只读文件系统文件包含了这个原始层中的全部内容，随时可以通过加载元数据索引获取整个目录树。目前Apparate使用了腾讯云CFS[2]高性能版作为IAS的一种实现，高吞吐低延迟CFS目前和镜像下载场景非常契合。

< ">镜像本地缓存由不同的IAS附加存储插件自身实现，目前CFS实现使用了FScache框架作为本地缓存可以自动按页缓存访问过的在远端存储上的部分数据，根据当前磁盘通过本地缓存能力，有效提升镜像数据重复访问的性能和稳定性。

< ">运行时实现

< ">当前ImageApparate在节点上使用的IAS附加存储插件被称之为Apparate-snapshotter，是通过containerd的proxy-snapshotter能力实现的。

< ">Apparate-snapshotter主要负责解析记录在镜像层中的IAS信息，从而拿到另外数据存储地址，接下来Apparate-snapshotter会去数据存储服务中加载远程数据，并在本地提供访问的Posix入口。

< ">比如在CFS场景下，会把远端数据mount到本地，并把挂载点作为接下来本地访问的入口。当需要使用远端数据时便由snapshotter或内核来提供按需加载的能力。

< ">只读镜像格式

< ">对于支持Lazy-Pull的镜像文件系统来说，只读是非常关键的属性，因为只读文件系统不需要考虑数据写入和删除造成的碎片和垃圾回收，可以提前在制作文件系统的时候优化数据块和索引的分布，这样可以大幅提高文件系统的读取性能。

< ">当前IAS支持的只读文件系统还增加了基于字母顺序排序的目录项索引(directory index)，可以大大加速目录项的Lookup操作。

< ">ImageApparate在TCR中使用方式

< ">创建加速组件

< ">当前ImageApparate在TCR中为alpha功能需要白名单开启。开启加速组件需要选择对应CFS的高性能版，请确认所在地域有此版本CFS。

< ">创建加速规则

< ">创建加速规则，只有规则中匹配的镜像或者Tag才会自动加速。之后再向TCR推送镜像后可以看到匹配加速规则的镜像会生成后缀为-apparate的OCI制品。

< ">TKE集群侧开启加速功能

< ">在TKE集群中创建TCR插件时开启镜像加速配置，之后可以给需要加速的集群中节点打标签kubectl label node xxx cloud.tencent.com/apparate=true，集群中Pod的镜像可以仍然使用原镜像名字(例如上述test/nginx:1.9)，加速插件支持自动选取已加速的镜像来进行挂载。如果镜像已被加速，那么观察TKE集群中Pod的image字段可以看到已被替换为test/nginx:1.9-apparate。

< ">后续工作

< ">当容器镜像是按需加载后，Layer（层）可能已经不再是复用的最小单位了，ImageApparate后续也会探索基于文件或者危机公关关于食品失败案例块镜像格式以及转换工具以获得更高的性能和效率。在接口侧镜像附加存储IAS也会支持更多数据源，包括和TKE P2P组件的集成，按需加载与P2P结合可以更好的应对超大规模镜像加载场景，大大减轻源站压力。

参考资料

[1]FAST'16:https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter

[2]CFS:https://console.cloud.tencent.com/cfs

[3]Slacker:Fast Distribution with Lazy Docker Containers:https://www.usenix.org/conference/fast16/technical-sessions/presentation/harter

[4]Image Manifest V 2,Schema 2:https://docs.docker.com/registry/spec/manifest-v2-2/

[5]General Filesystem Caching:https://www.kernel.org/doc/Documentation/filesystems/caching/fscache.txt

[6]EROFS:A Compression-friendly Readonly File System for Resource-scarce Devices:https://www.usenix.org/system/files/atc19-gao.pdf