共计 4398 个字符，预计需要花费 11 分钟才能阅读完成。
PART. 0
背景
火山引擎镜像仓库 CR 应用 TOS 来存储容器镜像。目前在肯定水平上能满足并发大规模的镜像拉取。然而最终拉取的并发量受限于 TOS 的带宽和 QPS。
这里简略介绍一下目前针对于大规模拉镜像遇到的两个场景的问题：
1、客户端数量越来越多，镜像越来越大，TOS 带宽最终无奈满足需要。
2、如果客户端应用了 Nydus 对镜像格局做转换之后，对 TOS 的申请量会有数量级的减少，TOS API 的 QPS 限度导致无奈满足需要。
不论是镜像仓库服务自身还是背地的存储，最终必定是有带宽和 QPS 限度的。如果单纯依赖服务端提供的带宽和 QPS，很容易就无奈满足需要。因而须要引入 P2P，加重服务端压力，进而满足大规模并发拉取镜像的需要。
PART. 1
基于 P2P 技术镜像散发零碎调研
目前开源社区有几个 P2P 我的项目，这里对这些我的项目进行简略介绍。
Dragonfly
架构图
术语
Manager
1、存储动静配置供 Seed Peer 集群、Scheduler 集群以及 Dfdaemon 生产。
2、保护 Seed Peer 集群和 Scheduler 集群之间关联关系。
3、提供对立异步工作治理，用作预热等性能。
4、监听各模块是否衰弱运行。
5、为 Dfdaemon 筛选最优 Scheduler 集群调度应用。
6、提供可视化控制台，不便用户操作治理 P2P 集群。
Scheduler
1、基于机器学习的多场景自适应智能 P2P 节点调度, 为以后下载节点抉择最优父节点。
2、构建 P2P 下载网络的有向无环图。
3、依据不同特征值评估节点下载能力, 剔除异样节点。
4、当下载失败状况，被动告诉 Dfdaemon 进行回源下载。
Dfdaemon
1、基于 gRPC 提供下载性能, 并提供多源适配能力。
2、开启 Seed Peer 模式能够作为 P2P 集群中回源下载节点, 也就是整个集群中下载的根节点。
3、为镜像仓库或者其余 HTTP 下载工作提供代理服务。
4、下载工作基于 HTTP 或 HTTPS 或其余自定义协定。
Kraken
架构图
术语
Agent
1、是 P2P 网络中的对等节点，须要在每个节点上部署。
2、实现了 Docker Registry interface。
3、告诉 tracker 本人领有的数据。
4、下载其余 agent 的数据（tracker 会通知该 agent 须要下载这块数据须要到哪个 agent 上下载）
Origin
1、负责从存储中读取数据做种。
2、反对不同的存储。
3、通过 Hash 环的模式保障高可用。
Tracker
1、P2P 网络中的协调者，追踪谁是 Peer，谁是 Seeder。
2、追踪 Peer 领有的数据。
3、提供有序的 Peer 节点供 Peer 下载数据。
4、通过 Hash 环的模式保障高可用。
Proxy
1、实现了 Docker Registry Interface。
2、将镜像层传给 Origin 组件。
3、将 Tag 传给 BUILD INDEX 组件。
Build-Index
1、Tag 和 digest 映射，agent 下载对应 Tag 数据时向 Build-Index 获取对应的 Digest 值。
2、集群之间镜像复制。
3、保留 Tag 数据在存储中。
4、通过 Hash 环的模式保障高可用。
Dragonfly vs Kraken
PART. 2
计划
在火山引擎上，次要思考 VKE 和 VCI 通过 CR 拉取镜像。
1、VKE 的产品特点是基于 ECS 部署的 K8S，因而非常适宜每个节点部署 Dfdaemon，充分利用每个节点的带宽，进而充分利用 P2P 的能力。
2、VCI 的产品特点是底层有一些资源很短缺虚构节点。下层的服务是以 POD 为载体，因而无奈像 VKE 那样每个节点部署 Dfdaemon，所以部署的模式部署几个 Dfdaemon 作为缓存，利用缓存的能力。
3、VKE 或 VCI 客户端拉取通过 Nydus 格局转化过的镜像。在该场景下，须要应用 Dfdaemon 作为缓存，不宜应用过多的节点，防止对 Scheduler 造成过大的调度压力。
基于火山引擎对于以上产品的需要，以及联合 Dragonfly 的特点，须要设计一套兼容诸多因素的部署计划。部署 Dagonfly 的方案设计如下。
PART. 3
整体架构图
1、火山引擎上的资源都是归属于主账号下。P2P 管制组件以主账号级别隔离，每个主账号下一套 P2P 管制组件。服务端实现 P2P Manager Controller，通过该 Controller 来管控管制面所有 P2P 管制组件。
2、P2P 管制组件部署在镜像仓库数据面 VPC，通过 LB 与用户集群买通。
3、在 VKE 集群上，Dfdaemon 以 DaemonSet 形式部署，每个节点上部署一个 Dfdaemon。
4、在 VCI 上，Dfdaemon 以 Deployment 形式部署。
5、ECS 上 Containerd 通过 127.0.0.1:65001 拜访本节点上的 Dfdaemon。
6、通过在用户集群部署一个 controller 组件，基于 PrivateZone 性能，在用户集群生成.p2p.volces.com 域名，controller 会依据肯定的规定筛选特定节点 （包含 VKE、VCI） 的 Dfdaemon pod，以 A 记录的模式解析到上述域名。
- ECS 上 Nydusd 通过.p2p.volces.com 域名拜访 Dfdaemon。
- VCI 上镜像服务客户端和 Nydusd 通过.p2p.volces.com 域名拜访 Dfdaemon。
PART. 4
压测数据
环境
镜像仓库：带宽 10Gbit/s。
ECS: 4C8G，挂载本地盘，带宽 6Gbit/s。
镜像
Nginx (500M)
TensorFlow (3G)
组件版本
Dragonfly v2.0.8。
Quota
Dfdaemon: Limit 2C6G。
Scheduler: 2 Replicas，Request 1C2G，Limit 4C8G。
Manager: 2 Replicas，Request 1C2G，Limit 4C8G。
POD 启动工夫比照
Nginx Pod 别离并发 50、100、200、500 的所有 Pod 从创立到启动耗费工夫。
TensorFlow Pod 别离并发 50、100、200、500 的所有 Pod 从创立到启动耗费工夫。
在大规模拉镜像的场景下，在应用 Dragonfly 和 Dragonfly & Nydus 场景比照 OCIv1 场景可能节俭 90% 以上的容器启动工夫。应用 Nydus 之后启动工夫更短是因为镜像 lazyload 的个性，只须要拉取很小的一部分元数据 Pod 就能启动。
存储源端带宽峰值比照
Nginx Pod 别离并发 50、100、200、500 的存储端峰值流量。
TensorFlow Pod 别离并发 50、100、200、500 的存储端峰值流量。
回源流量比照
Nginx Pod 别离并发 50、100、200、500 的回源流量。
TensorFlow Pod 别离并发 50、100、200、500 的回源流量。
在大规模场景下，应用 Dragonfly 回源拉取镜像的数量很少。OCIv1 的场景所有的镜像拉取都要回源，因而应用 Dragonfly 回源峰值和回源流量相比 OCIv1 的场景少很多。并且应用 Dragonfly 后随着并发数进步，回源峰值和流量不会显著进步。
PART. 5
总结
基于我的项目整体成熟度，社区活跃度、用户数量、架构复杂度，是否针对 Nydus 优化。将来发展趋势等因素综合思考，Dragonfly 是 P2P 我的项目中最优的选型。
PART. 6
术语及定义
OCI
Open Container Initiative，凋谢容器打算是一个 Linux 基金会我的项目，由 Docker 在 2015 年 6 月启动，旨在为操作系统级虚拟化（最重要的是 Linux 容器）设计凋谢规范。
OCI Artifact
遵循 OCI image spec 的制品。
镜像
本文中的镜像指 OCI Artifact，因而也包含 Helm Chart 等其余 OCI Artifact。
镜像仓库
遵循 OCI distribution spec 实现的制品仓库。
ECS
是一种由 CPU、内存、云盘组成的资源汇合，每一种资源都会逻辑对应到数据中心的计算硬件实体。
CR
火山引擎镜像仓库服务。
VKE
火山引擎通过深度交融新一代云原生技术，提供以容器为外围的高性能 Kubernetes 容器集群治理服务，助力用户疾速构建容器化利用。
VCI
火山一种 Serverless 和容器化的计算服务。以后 VCI 可无缝集成容器服务 VKE，提供 Kubernetes 编排能力。
应用 VCI，能够专一于构建利用自身，而无需购买和治理底层云服务器等基础设施，并仅为容器理论运行耗费的资源付费。VCI 还反对秒级启动、高并发创立、沙箱容器平安隔离等能力。
TOS
火山引擎提供的海量、平安、低成本、易用、高牢靠、高可用的分布式云存储服务。
Private Zone
基于专有网络 VPC（Virtual Private Cloud）环境的公有 DNS 服务。该服务容许在自定义的一个或多个 VPC 中将公有域名映射到 IP 地址。
P2P
点对点技术，当 P2P 网络中某一个 peer 从 server 下载数据的时候，下载完数据后也能当作服务端供其余 peer 下载。当大量节点同时下载的时候，能保障后续下载的数据，能够不必从 server 端下载。从而加重 server 端的压力。
Dragonfly
Dragonfly 是⼀款基于 P2P 技术的文件散发和镜像减速零碎，并且是云原生架构中镜像减速畛域的规范解决方案以及最佳实际。当初为云原生计算机基金会 （CNCF） 托管作为孵化级我的项目。
Nydus
Nydus 简介: Nydus 镜像减速框架是 Dragonfly 的子项目，它提供了容器镜像按需加载的能力，在生产环境撑持了每日百万级别的减速镜像容器创立，在启动性能，镜像空间优化，端到端数据一致性，内核态反对等方面相比 OCIv1 有微小劣势。
*|社区相干网址|*
Dragonfly 社区官网网站:
Volcano Engine: https://www.volcengine.com/
Volcano Engine VKE: https://www.volcengine.com/product/vke
Volcano Engine CR: https://www.volcengine.com/product/cr
Dragonfly 官网: https://d7y.io/
Dragonfly Github Repo: https://github.com/dragonflyoss/Dragonfly2
Nydus 官网: https://nydus.dev/
Nydus Gihtub Repo: https://github.com/dragonflyoss/image-service
Dragonfly Star 一下✨：
https://github.com/dragonflyoss/Dragonfly2
火山引擎基于 Dragonfly 减速实际
Dragonfly 基于 P2P 的文件和镜像散发零碎
展台招募|“SOFA 五周年”开源集市等你来！
Dragonfly 和 Nydus Mirror 模式集成实际