卡瓦邦噶！
·
Piccolo P2P 镜像分发
内容提要
Harbor 在大规模容器启动时面临镜像下载瓶颈，用户构建的镜像质量参差不齐，导致下载压力增大。为此，提出结合中心化服务发现与去中心化 P2P 下载的方案，开发了 Piccolo 项目。Piccolo 通过本地 daemonset 提升下载效率，减少对 Harbor 的依赖，显著改善下载带宽和性能。
关键要点
-
Harbor 在大规模容器启动时面临镜像下载瓶颈，网络带宽需求极高。
-
用户构建的镜像质量参差不齐，导致下载压力增大。
-
需要解决大量 worker 节点迅速扩容上万容器的问题。
-
Spegel 的下载方案存在服务发现性能低的问题。
-
提出结合中心化服务发现与去中心化 P2P 下载的方案，开发 Piccolo 项目。
-
Piccolo 通过本地 daemonset 提升下载效率，减少对 Harbor 的依赖。
-
Piccolo Server 作为服务发现的源，提供 image 列表上报、查询和全量同步接口。
-
部署 Piccolo 后，97% 的下载请求可以在 Pi 完成，显著降低 Harbor 流量。
-
Piccolo 为集群提供约 8Tib 的下载带宽，几乎不消耗额外资源。
-
Piccolo server 性能高，一台 8C8G 的实例可支撑 5 万个 Pi。
-
服务发现核心是用 MySQL 表存储 blob 和 IP 的对应关系，支持不同 group 的 Pi 互相发现。
-
Piccolo server 返回资源时根据请求者 IP 相似度排序，优化下载效率。
-
所有 API 接口都有重试和指数时间退让，增强系统的稳定性和可用性。
延伸解读
镜像下载瓶颈的背景
在大规模容器启动时，Harbor面临的镜像下载瓶颈主要源于网络带宽需求极高。用户构建的镜像质量参差不齐，尤其是大于10GiB的镜像，导致下载压力加剧。因此，解决这一问题对于提升容器启动效率至关重要。
Piccolo的创新方案
Piccolo项目通过结合中心化服务发现与去中心化P2P下载，显著提升了镜像下载效率。其本地daemonset的设计使得97%的下载请求可以在本地完成，极大减少了对Harbor的依赖，从而缓解了网络流量压力。
服务发现的关键性
Piccolo的服务发现机制使用MySQL表存储blob和IP的对应关系，支持不同组的Pi互相发现。这种设计不仅提高了服务发现的效率，还通过IP相似度排序优化了下载过程，确保资源的快速获取。
系统稳定性与可用性
Piccolo的API接口设计包含重试和指数时间退让机制，增强了系统在大规模部署时的稳定性。这种设计能够有效分散请求，降低系统在高负载情况下的失败风险，确保服务的持续可用性。
延伸问答
Piccolo 项目的主要目标是什么？
Piccolo 项目的主要目标是解决 Harbor 在大规模容器启动时的镜像下载瓶颈，提升下载效率，减少对 Harbor 的依赖。
Piccolo 如何提升镜像下载效率？
Piccolo 通过本地 daemonset 提升下载效率，允许在本地完成大部分下载请求，从而减少对 Harbor 的流量。
Piccolo Server 的功能是什么？
Piccolo Server 作为服务发现的源，提供 image 列表上报、查询和全量同步接口，支持 Pi 之间的资源发现。
Piccolo 的部署对资源消耗有何影响？
Piccolo 的部署消耗非常少，平均 CPU 使用不到 1%，内存约 22M，几乎不消耗额外资源。
Piccolo 如何解决服务发现的性能问题？
Piccolo 使用中心化的高性能服务发现，利用 MySQL 表存储 blob 和 IP 的对应关系，优化查询效率。
Piccolo 在下载请求处理上有什么优势？
部署 Piccolo 后，97% 的下载请求可以在 Pi 完成，显著降低了对 Harbor 的依赖和流量。
