编者按：本文具体介绍蚂蚁平安科技应用龙蜥社区技术进行镜像减速的实际过程，能够让您理解如何基于龙蜥社区推出的容器镜像，Nydus 与 Dragonfly 镜像减速技术和 LifseaOS 为容器的启动减速。文章转自金融级分布式架构，以下为全文：
01 背景简介
ZOLOZ 是龙蜥社区理事单位蚂蚁团体旗下的寰球平安风控平台，通过业内当先的生物辨认、大数据分析和人工智能技术，为用户和机构提供平安又便捷的平安风控解决方案。ZOLOZ 已为中国、印尼、马来西亚、菲律宾等 14 个国家和地区的 70 余家合作伙伴提供数字化转型过程中的平安风控技术支持。目前，曾经笼罩金融、保险、证券、信贷、电信、公众服务等畛域，累计服务用户超 12 亿。
随着 Kubernetes 和云原生的大暴发，ZOLOZ 利用开始在私有云上进行大规模容器化部署。ZOLOZ 业务的镜像通过长期保护和更新，无论是镜像层数还是整体大小都达到了一个较大的量级（数百 MB 或者几个 GB）。特地是 ZOLOZ AI 算法推理利用的根底镜像大小要远大于个别利用镜像（Docker Hub 上 PyTorch/PyTorch：1.13.1-CUDA 11.6-cuDNN 8-Runtime 有 4.92GB，同比 CentOS：latest 只有约 234MB），对于容器冷启动，即在本地无镜像的状况下，须要先从 Registry 下载镜像能力创立容器，在生产环境中，容器的冷启动往往耗时数分钟，并且随规模扩大会导致 Registry 因集群内网络拥挤而无奈疾速地下载镜像，如此宏大的镜像给利用的更新和扩容等操作都带来了不少挑战。在私有云上容器化继续推动的当下，ZOLOZ 利用次要遇到了三大挑战：
1. 算法镜像大，推送到云上镜像仓库耗时长，开发过程中，在应用测试环境进行测试时，往往心愿疾速迭代，疾速验证，然而每次改完一个分支公布验证都要通过几十分钟，开发效率非常低下。
2. 拉取算法镜像耗时长，在集群扩容大量机器拉取镜像文件会容易导致集群网卡被打满，影响业务失常运行。
3. 集群机器拉起工夫长，难以满足流量突增时，弹性主动扩缩容。
尽管也尝试过各种折中的解决方案，但这些计划都有缺点，咱们当初联合蚂蚁、阿里云、字节跳动等多个技术团队打造了一套更通用的私有云上解决方案，该计划革新成本低，性能好，其中大部分技术都在龙蜥社区中发动、倒退、开源，目前看来是比拟现实的计划。
02 术语及定义
OCI：Open Container Initiative，凋谢容器打算是一个 Linux 基金会我的项目，由 Docker 在 2015 年 6 月启动，旨在为操作系统级虚拟化（最重要的是 Linux 容器）设计凋谢规范。
OCI Manifest：遵循 OCI Image Spec 的制品。
BuildKit：是 Docker 公司出品的一款更高效、Docekrfile 无关、更符合云原生利用的新一代 Docker 构建工具。
镜像：本文中的镜像指 OCI Manifest，也包含 Helm Chart 等其余 OCI Manifest。
镜像仓库：遵循 OCI Distribution Spec 实现的制品仓库。
ECS：是一种由 CPU、内存、云盘组成的资源汇合，每一种资源都会逻辑对应到数据中心的计算硬件实体。
ACR：阿里云镜像仓库服务。
ACK：阿里云容器服务 Kubernetes 版提供高性能可伸缩的容器利用治理能力，反对企业级容器化利用的全生命周期治理。
ACI：ACI 全称 Ant Continuous Integration（AntCI），是蚂蚁团体研发效力旗下一款以流水线（Pipeline）为外围的 CI/CD 效力产品。应用智能自动化构建、测试和部署，提供了以代码流为输出的轻量级继续交付解决方案，进步团队研发的工作效率。
Private Zone：基于专有网络 VPC（Virtual Private Cloud）环境的公有 DNS 服务。该服务容许在自定义的一个或多个 VPC 中将公有域名映射到 IP 地址。
P2P：点对点技术，当 P2P 网络中某一个 Peer 从 Server 下载数据的时候，下载完数据后也能当作服务端供其余 Peer 下载。当大量节点同时下载的时候，能保障后续下载的数据，能够不必从 Server 端下载。从而加重 Server 端的压力。
Dragonfly：Dragonfly 是⼀款基于 P2P 技术的文件散发和镜像减速零碎，并且是云原生架构中镜像减速畛域的规范解决方案以及最佳实际。当初为云原生计算机基金会（CNCF）托管作为孵化级我的项目。
Nydus：Nydus 镜像减速框架是 Dragonfly 的子项目，它提供了容器镜像按需加载的能力，在生产环境撑持了每日百万级别的减速镜像容器创立，在启动性能，镜像空间优化，端到端数据一致性，内核态反对等方面相比 OCIv1 有微小劣势。Nydus 也是龙蜥社区云原生 SIG 开创我的项目之一。
LifseaOS：龙蜥社区的开源我的项目，是面向容器场景的轻量、疾速、平安、镜像原子治理的容器优化操作系统。相比传统操作系统软件包数量缩小 60%，镜像大小缩小 70%，OS 首次启动从传统 OS 的 1min 以上降落到了 2s 左右。反对镜像只读和 OSTree 技术，将 OS 镜像版本化治理，更新操作系统上的软件包、或者固化的配置时，以整个镜像为粒度进行更新。
03 方案设计
3.1 解决镜像大的问题
3.1.1 精简根底镜像大小
根底 OS 从 CentOS 7 改为龙蜥社区公布的官网 OS 镜像 Anolis OS 8，精简运维工具的装置，只默认装置一些必须的工具列表（根底运维工具、运行时通用依赖、日志清理、平安基线等组件），并简化平安加固的配置，根底镜像从 1.63GB 缩小到 300MB。
Anolis OS 仓库：https://hub.docker.com/r/openanolis/anolisos/tags
3.1.2 Dockerfile 优化
通过 Dockerfile 编写束缚、镜像检测等伎俩缩小不必要的构建资源和工夫。
Dockerfile 最佳实际准则：https://docs.docker.com/develop/develop-images/dockerfile_bes…
3.1.3 并行构建和构建缓存
蚂蚁构建核心采纳 Nydus 社区优化版的 BuildKit，BuildKit 反对 layer 级别缓存，精确援用先前的产出物并进行缓存匹配，应用办法与一般镜像并无区别，对于 Multistage 类型 Dockerfile，BuildKit 能够实现不同 stage 之间的并行执行。
3.2 推送到云上镜像仓库耗时长
3.2.1 应用 Nydus 镜像进行块级别数据去重
传统 OCI 镜像，不同镜像之间能够共享的最小单位是镜像中的层，在 deduplication 上的效率是非常低的，层外部存在反复的数据，层与层之间可能存在大量反复的数据，即便有渺小的差异，也会被作为不同的层。依据 OCI Image Spec 对删除文件和 Hard Link 的设计，一个镜像外部可能存在曾经被下层删除的文件依然存在于上层中，并蕴含在镜像中。另外 OCI Image 应用了 tar+gzip 格局来表白镜像中的层，而 tar 格局并不辨别 tar archive entries ordering，这带来一个问题即如果用户在不同机器上 build 去同一个镜像，最终可能会因为应用了不同的文件系统而失去不同的镜像，但若干不同镜像的本质内容是完全相同的状况，导致上传下载数据量飙增。
OCIv1 存在的问题与 OCIv2 提案：https://hackmd.io/@cyphar/ociv2-brainstorm
Nydus 镜像文件以文件 Chunk 为粒度宰割，扁平化元数据层（移除中间层），每一个 Chunk 在镜像中只会保留一次，可指定 Base Image , 用作其余 Nydus Image 的 Chunk dictionary，基于 Chunk level deduplication 提供了在不同镜像之间低成本的 data 去重能力，大大降低了镜像的上传和下载数据量。
（图 /Nydus 镜像块共享）
如上图 Nydus 镜像 1 和镜像 2 存在雷同的数据块 B2、C、E1、F，镜像 2 新增 E2、G1、H1、H2，如果镜像仓库曾经存在镜像 1，那么镜像 2 能够基于镜像 1 进行镜像构建，仅须要将 E2、G1、H1、H2 构建在一层，在上传的时候仅须要将这一层上传到镜像仓库，达到仅文件差别上传、拉取的成果，缩短研发周期。
3.2.2 间接构建云上 Nydus 镜像
目前在大多数减速镜像的落地场景中，减速镜像的生产都是基于镜像转换的。目前落地的 Nydus 转换计划次要为以下三种：
i. 镜像仓库转换
一般镜像构建实现并 push 到镜像仓库后，触发镜像仓库的转换动作，实现镜像转换。这种计划的毛病在于，构建和转换往往在不同机器上进行。镜像构建并 push 后，还须要 pull 到转换机并将产出 push 到镜像仓库，须要减少一次残缺的镜像流转过程，提早较高，而且还占用镜像仓库的网络资源。在减速镜像转换实现前，利用公布并无奈享受减速成果，仍须要残缺 pull 镜像。
ii. 双版本构建
在一般镜像构建实现后，在构建机本地间接转换。为提高效率，能够在每层构建实现后即开始对该层进行转换，减速镜像生成提早能够大幅升高。这个计划，无需期待一般镜像上传即可开始转换，而且在本地转换，相比拟计划 1，能够省掉的转换机镜像传输的开销。如果根底镜像对应的减速镜像不存在，则将其转换进去；如果存在，pull 能够忽略不计，然而无可避免的是 push 总是须要双份。
iii. 间接构建
上述两种基于转换的计划，与间接构建 Nydus 减速镜像相比，都有显著的生产提早。一是基于 OCI 的镜像构建速度显著慢于 Nydus 镜像构建；二是转换是预先行为，都存在或多或少的滞后；三是都存在额定的数据传输。而间接构建，流程少，速度快，又节约资源：
能够看出，减速镜像构建，步骤显著缩小，数据传输量显著缩小，构建实现后即可间接享受减速镜像的能力，利用公布速度能够大幅晋升。
3.3 镜像启动慢
3.3.1 Nydus 镜像按需加载
在容器启动时，容器内业务 IO 申请哪些文件的数据，再从远端 Registry 拉取这些数据，这样防止镜像大量数据拉取阻塞容器的启动，镜像的数据的理论使用率是很低的，比方 Cern 的这篇论文中就提到，个别镜像只有 6% 的内容会被理论用到。按需加载的目标是让容器运行时有选择地从 Blob 中的镜像层（layer）下载和提取文件，但 OCI/ Docker 镜像标准将所有的镜像层打包成一个 tar 或 tar.gz 存档，这样即便你要提取单个文件也要扫描整个 Blob。如果镜像应用 gzip 进行压缩，就更没有方法提取特定文件了。
（图 /Nydus 镜像格局）
RAFS 镜像格局是 Nydus 提出的存档压缩格局。其中将容器镜像文件零碎的数据（Blobs）和元数据（Bootstrap）拆散，让原来的镜像层只存储文件的数据局部。并且把文件以 Chunk 为粒度宰割，每层 Blob 存储对应的 Chunk 数据；因为采纳了 Chunk 粒度，这细化了去重粒度，Chunk 级去重让层与层之间，镜像与镜像之间共享数据更容易，也更容易实现按需加载。原来的镜像层只存储文件的数据局部（也就是图中的 Blob 层）。Blob 层存储的是文件数据的切块（Chunk），例如将一个 10MB 的文件，切割成 10 个 1MB 的块，于是就能够将 Chunk 的 Offset 记录在一个索引中，容器在申请文件的局部数据时，通过联合 OCI/Docker 镜像仓库标准反对的 HTTP Range Request，容器运行时能够有选择地从镜像仓库中获取文件，如此一来节俭不必要的网络开销。对于 Nydus 镜像格局的更多细节，请参考 Nydus Image Service 我的项目。
元数据和 Chunk 的索引加在一起，就组成了上图中的 Meta 层，它是所有镜像层重叠后容器能看到的整个 Filesystem 构造，蕴含目录树结构，文件元数据，Chunk 信息（块的大小和偏移量，以及每个文件的元数据（名称、文件类型、所有者等））。有了 Meta 之后，就能够在不扫描整个存档文件的状况下提取须要的文件。另外，Meta 层蕴含了 Hash 树以及 Chunk 数据块的 Hash，以此来保障咱们能够在运行时对整颗文件树校验，以及针对某个 Chunk 数据块做校验，并且能够对整个 Meta 层签名，以保障运行时数据被篡改后仍然可能被查看进去。
（图 /Nydus 按需加载）
Nydus 默认应用用户态文件系统实现 FUSE 来做按需加载，用户态的 Nydus Daemon 过程将 Nydus 镜像挂载点作为容器 RootFS 目录，当容器产生 read(fd,count) 之类的文件系统 IO 时，内核态 FUSE 驱动将该申请退出解决队列，用户态 Nydus Daemon 通过 FUSE Device 读取并解决该申请，从远端 Registry 拉取 Count 对应数量的 Chunk 数据块后，最终通过内核态 FUSE 回复给容器。Nydus 还实现了一层本地 Cache，曾经从远端拉取的 Chunk 会解压缩后缓存在本地，Cache 能够做到以层为单位在镜像之间共享，也能够做到 Chunk 级别的共享。
（图 / 从 Pod 创立到容器启动）
利用 Nydus 做镜像减速后，不同利用的启动工夫都有了质的飞跃，可能在十分短的工夫内拉起利用，满足云上疾速伸缩的要求。
3.3.2 只读文件系统 EROFS
当容器镜像中存在大量文件时，频繁的文件操作会产生大量的 FUSE 申请，造成内核态 / 用户态上下文的频繁切换，造成性能瓶颈；龙蜥社区设计并实现了兼容内核原生 EROFS 文件系统的 Nydus RAFS（Registry Acceleration File System）v6 格局，相比于此前的格局，它具备块数据对齐，元数据更加精简，高可扩展性与高性能等劣势。在镜像数据全副下载到本地的状况下，FUSE 用户态计划会导致拜访文件的过程频繁陷出到用户态，并波及内核态 / 用户态之间的内存拷贝，更进一步反对了 EROFS over FS-Cache 计划（Linux 5.19-rc1），当用户态 Nydusd 从远端下载 Chunk 后会间接写入 FS-Cache 缓存，之后容器拜访时，可能间接通过内核态 FS-Cache 读取数据，而无需陷出到用户态，在容器镜像的场景下实现简直无损的性能和稳定性，其按需加载阶段体现相似 FUSE 用户态实现，按需加载完结后与原生文件系统的性能相近，优于 FUSE 用户态实现。
（图 / 不同文件系统计划按需加载阶段比照）
目前 Nydus 在构建，运行，内核态（Linux 5.19-rc1）均已反对了该计划，龙蜥社区的 Anolis OS 7、Anolis OS 8 内核也都反对了 RAFS v6，具体用法能够参见 Nydus EROFS FS-Cache user guide，另外想理解更多 Nydus 内核态实现细节，能够参见 Nydus 镜像减速之内核演进之路。
（图 /Nydus 内核实现细节）
3.3.3 Dragonfly P2P 减速镜像下载
不论是镜像仓库服务自身还是背地的存储，最终必定是有带宽和 QPS 限度的。如果单纯依赖服务端提供的带宽和 QPS，很容易就无奈满足需要。因而须要引入 P2P，加重服务端压力，进而满足大规模并发拉取镜像的需要。在大规模拉镜像的场景下，在应用 Dragonfly&Nydus 场景比照 OCIv1 场景可能节俭 90% 以上的容器启动工夫。
（图 /Dragonfly P2P 镜像减速拉取）
应用 Nydus 之后启动工夫更短是因为镜像 Lazyload 的个性，只须要拉取很小的一部分元数据 Pod 就能启动。在大规模场景下，应用 Dragonfly 回源拉取镜像的数量很少。OCIv1 的场景所有的镜像拉取都要回源，因而应用 Dragonfly 回源峰值和回源流量相比 OCIv1 的场景少很多。并且应用 Dragonfly 后随着并发数进步，回源峰值和流量不会显著进步。
（图 /1G 大小的随机文件测试）
3.4 集群伸缩工夫长
3.4.1 ACR 镜像仓库寰球同步
为了满足客户优质的体验以及数据合规需要，须要就近接入，因而 ZOLOZ 在寰球多个站点进行云上部署。借助 ACR 镜像仓库进行跨境同步减速，寰球多地区间同步，进步容器镜像散发效率。上传和下载镜像都在本区域机房内进行，特地是在一些网络不太好的国家内，也可能像本地机房一样进行部署，真正做到利用的一键部署到寰球各地。
3.4.2 采纳 ContainerOS 极速启动
借助云原生满足客户急速增长资源扩容，利用弹性降低成本，在云上须要极速伸缩虚拟机，并将其退出到集群外部。阿里云 ACK 基于龙蜥的 LifseaOS，构建了全托管节点池的容器优化 OS 镜像 ContainerS。ContainerOS 通过简化 OS 启动流程，预置集群管控必备组件的容器镜像以缩小节点启动过程中因镜像拉取而带来的耗时，极大地提高了 OS 启动速度，升高了 ACK 链路中的节点扩容工夫。ContainerOS 从如下几个方面进行了优化：
ContainerOS 通过简化 OS 启动流程，无效升高 OS 启动工夫。ContainerOS 的定位是跑在云上虚拟机的操作系统，不会波及到太多的硬件驱动，因而 ContainerOS 将必要的内核驱动模块批改为 built-in 模式。此外，ContainerOS 去除了 initramfs，且 udev 规定也被大大简化，此时 OS 启动速度失去了大幅晋升。以 ecs.g7.large 规格的 ECS 实例为例，LifseaOS 的首次启动工夫放弃在 2s 左右，而 Alinux3 则须要 1min 以上。
ContainerOS 通过预置集群管控必备组件的容器镜像以缩小节点启动过程中因镜像拉取而带来的耗时。ECS 节点启动实现后须要拉取局部组件的容器镜像，这些组件负责在 ACK 场景下执行一些基础性的工作。例如 Terway 组件负责网络，节点必须在 Terway 组件的容器就绪的状况下能力转换为就绪状态。因而，既然网络拉取的长尾效应会带来极大的耗时，那么能够通过预置的形式提前将此组件提前装置在 OS 外部，此时可间接从本地目录获取，防止网络拉取镜像耗时。
ContainerOS 也会通过联合 ACK 管控链路优化，进步节点弹性性能。
最终，统计了从空的 ACK 节点池扩容的端到端的 P90 耗时，从下发扩容申请开始计时，到 90% 的节点处于就绪状态完结计时，并比照了 CentOS、Alinux2 Optimized-OS 计划，ContainerOS 性能劣势显著，具体数据如下图所示。
（图 /ecs.c6.xlarge 并发启动数据）
3.5 整体链路
（图 /ZOLOZ 私有云利用部署整体计划）
- 通过精简根底镜像以及遵循 Dockerfile 规约，对镜像大小进行精简。
- 利用蚂蚁托管的 BuildKit 对镜像进行 Multistage 并行构建，在反复构建时采纳缓存放慢镜像构建。间接构建 Nydus 减速镜像时通过镜像之间反复剖析进行去重，仅上传镜像之间差别的块到近程镜像仓库。
- 通过 ACR 寰球减速同步的能力，将镜像散发到寰球不同的镜像仓库中，进行就近拉取。
- 通过 Dragonfly P2P 网络对 Nydus 镜像块进行按需减速拉取。
- 节点上应用 ContainerOS 操作系统，进步 OS 启动速度以及镜像启动速度。
（图 / 容器研发流程）
（图 / 以 3G 镜像为例）
* 调度工夫：该工夫是指从阿里云创立一台 ECS，到节点退出到 K8s 集群并 Ready 的工夫，得益于 ContainerOS 的优化，该耗时升高非常明显。
通过对研发全流程各个环节进行极致的优化，能够发现优化后，研发效率和线上稳定性都失去了质的晋升，目前整套计划曾经在阿里云和 AWS 都实现了部署，线上稳固运行 3 个月，将来将在云厂商提供规范的部署环境，满足更多类型的业务场景。
04 使用指南
4.1 镜像构建
代码资产都在蚂蚁域内，利用蚂蚁镜像构建核心托管的 BuildKit 集群，通过自定义的 ACI 组件进行构建 Nydus 镜像。
镜像构建:
stage: 镜像构建
id: build-image
component: nydus-image-build
inputs:
imageName: ${{parameters.imageName}} #构建的镜像 name
imageTag: ${{vcs.commitSha}} # 构建的镜像 tag，这里的 ${{vcs.commitSha}} 是 ACI 内置参数
dockerfile: Dockerfile # dockerfile 文件地位（默认绝对代码根目录）chunkDictImage: ${{parameters.chunkDictImage}}
timeoutInSec: 1200能够指定 Chunk Dict Image 按 Chunk 去重粒度，如果构建的镜像和 Chunk Dict Image。Image Name 能够间接指定阿里云 ACR 仓库，构建的 Nydus 镜像间接推送到云上，缩小镜像直达耗时。
4.2 Dragonfly 装置
$ helm repo add dragonfly https://dragonflyoss.github.io/helm-charts/
$ helm install --wait --timeout 10m --dependency-update --create-namespace --namespace dragonfly-system dragonfly dragonfly/dragonfly --set dfdaemon.config.download.prefetch=true,seedPeer.config.download.prefetch=true
NAME: dragonfly
LAST DEPLOYED: Fri Apr 7 10:35:12 2023
NAMESPACE: dragonfly-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the scheduler address by running these commands:
export SCHEDULER_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l "app=dragonfly,release=dragonfly,component=scheduler" -o jsonpath={.items[0].metadata.name})
export SCHEDULER_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $SCHEDULER_POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
kubectl --namespace dragonfly-system port-forward $SCHEDULER_POD_NAME 8002:$SCHEDULER_CONTAINER_PORT
echo "Visit http://127.0.0.1:8002 to use your scheduler"
2. Get the dfdaemon port by running these commands:
export DFDAEMON_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l "app=dragonfly,release=dragonfly,component=dfdaemon" -o jsonpath={.items[0].metadata.name})
export DFDAEMON_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $DFDAEMON_POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
You can use $DFDAEMON_CONTAINER_PORT as a proxy port in Node.
3. Configure runtime to use dragonfly:
https://d7y.io/docs/getting-started/quick-start/kubernetes/更多详情参考：https://d7y.io/zh/docs/setup/integration/nydus
4.3 Nydus 装置
$ curl -fsSL -o config-nydus.yaml https://raw.githubusercontent.com/dragonflyoss/Dragonfly2/main/test/testdata/charts/config-nydus.yaml
$ helm install --wait --timeout 10m --dependency-update --create-namespace --namespace nydus-snapshotter nydus-snapshotter dragonfly/nydus-snapshotter -f config-nydus.yaml
NAME: nydus-snapshotter
LAST DEPLOYED: Fri Apr 7 10:40:50 2023
NAMESPACE: nydus-snapshotter
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing nydus-snapshotter.
Your release is named nydus-snapshotter.
To learn more about the release, try:
$ helm status nydus-snapshotter
$ helm get all nydus-snapshotter更多详情参考：https://github.com/dragonflyoss/helm-charts/blob/main/INSTALL.md
同时，AnolisOS 8 零碎中曾经集成了 Nydus 相干的包以及工具，您能够在应用 AnolisOS 8 的时候疾速应用 Nydus 能力，详情参考：https://openanolis.cn/sig/cloud-native/doc/624244092113272868…
4.4 ContainerOS 应用
ContainerOS 基于龙蜥社区的 LifseaOS 我的项目开发，针对 ACK 集群节点池的弹性扩容场景，实现了极速扩容的个性。一方面，LifseaOS 通过简化 OS 自身的启动流程进步了 OS 启动速度。它裁剪掉了大量云上场景无需的硬件驱动，必要的内核驱动模块批改为 built-in 模式，去除了 initramfs，udev 规定也被大大简化，OS 首次启动工夫从传统 OS 的 1min 以上降落到了 2s 左右。另一方面，ContainerOS 联合 ACK 场景进行了定制优化。它通过预置集群管控必备组件的容器镜像以缩小节点启动过程中因镜像拉取而带来的耗时，并联合 ACK 管控链路优化（例如调节要害逻辑的检测频率、调整高负载下零碎瓶颈中的限流值等），极大地提高了节点扩容速度。在阿里云管制台上为 ACK 集群建设托管节点池 时，在配置菜单中能够抉择 ECS 实例的操作系统，下拉抉择 ContainerOS 即可，OS 镜像名字中的 1.24.6 对应的是集群的 K8s 版本。另外，如果您须要高性能的节点池弹性扩容能力，为了实现最佳的节点扩容性能，更多信息请参见应用 ContainerOS 实现节点极速扩容。
05 注意事项
ContainerOS 目前仅反对 Kubernetes 1.24.6 及以上版本，须要在创立 ACK 集群，或降级 ACK 集群的 K8s 版本为 1.24.6 及以上版本方可应用。ContainerOS 预置了影响 Node Ready 和 Pod Ready 的必备的组件，如 Flannel、Terway 等网络插件。本来节点启动后须要拉取并启动这些组件的容器镜像，节点才会处于就绪状态，预置之后便无需从网络上拉取。然而，为了避免集群的组件版本与预置的组件版本不统一的状况，请参考注意事项。
06 参考资料
- https://github.com/containerd/containerd
- https://github.com/dragonflyoss/Dragonfly2
- https://d7y.io/
- https://github.com/dragonflyoss/image-service
- https://nydus.dev/
- https://github.com/goharbor/harbor
- https://www.alibabacloud.com/help/zh/container-registry
- https://github.com/moby/moby/tree/master/image/spec
- https://docs.docker.com/registry/spec/manifest-v2-1/
- https://docs.docker.com/registry/spec/manifest-v2-2/
- https://github.com/opencontainers/image-spec/blob/main/layer.md#representing-changes
- https://github.com/opencontainers/image-spec/blob/main/manifest.md
- https://www.usenix.org/conference/fast16/technical-sessions/p…
- https://www.kernel.org/doc/html/latest/filesystems/fuse.html
- https://virtio-fs.gitlab.io/
- https://www.kernel.org/doc/html/latest/filesystems/erofs.html
- https://github.com/dragonflyoss/image-service/blob/fscache/docs/nydus-fscache.md
- https://mp.weixin.qq.com/s/w7lIZxT9Wk6-zJr23oBDzA
- https://static.sched.com/hosted_files/kccncosschn21/fd/EROFS_…
- https://github.com/imeoer/buildkit/tree/nydus-compression-type
文 / 蚂蚁团体 ZOLOZ 团队
原文链接
本文为阿里云原创内容，未经容许不得转载。