ImageApparate(幻影)镜像加速服务让镜像分发效率提升 5-10 倍 (2)

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

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

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

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

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

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

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

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

ImageApparate(幻影)镜像加速服务让镜像分发效率提升 5-10 倍

镜像附加存储 IAS(ImageAttachStorage)

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

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

ImageApparate(幻影)镜像加速服务让镜像分发效率提升 5-10 倍

运行时实现

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

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

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

只读镜像格式

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

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

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wpppyz.html