一、P2P鏡像分發(fā)簡(jiǎn)述

隨著云原生架構(gòu)被越來越多的企業(yè)接受，企業(yè)應(yīng)用中容器集群的規(guī)模也越來越大。當(dāng)容器集群達(dá)到一定的規(guī)模且單容器應(yīng)用副本數(shù)達(dá)到一定級(jí)別時(shí)，集群中容器鏡像的分發(fā)將面臨挑戰(zhàn)。
??P2P（Peer-to-Peer，點(diǎn)對(duì)點(diǎn)）鏡像分發(fā)借鑒了互聯(lián)網(wǎng)P2P文件傳輸?shù)乃悸罚荚谔岣哏R像在容器集群中的分發(fā)效率，以更快的鏡像拉取速度來對(duì)kubernetes集群進(jìn)行優(yōu)化。
本篇主要講述 Kraken+Harbor的理論部分，部署及使用的實(shí)踐部分在下篇文章進(jìn)行詳細(xì)的描述。

1.1 P2P鏡像分發(fā)的原理

鏡像分發(fā)規(guī)模達(dá)到一定數(shù)量時(shí)，首先面臨壓力的是Harbor服務(wù)或者后端存儲(chǔ)的帶寬。如果100個(gè)節(jié)點(diǎn)同時(shí)拉取鏡像，鏡像被壓縮為500MB，此時(shí)需要在10秒內(nèi)完成拉取，則后端存儲(chǔ)面臨5GB/s的帶寬。在一些較大的集群中，可能有上千個(gè)節(jié)點(diǎn)同時(shí)拉取一個(gè)鏡像，帶寬壓力可想而知。
解決這個(gè)問題的方法有很多，比如劃分集群、增加緩存和負(fù)載均衡等，但較好的解決方法可能是采用P2P鏡像分發(fā)技術(shù)。

Ps: Harbor在鏡像同步、鏡像拉取的默認(rèn)超時(shí)時(shí)間是900s，鏡像拉取超時(shí)時(shí)間可以在Harbor的Nginx配置文件/etc/nginx/nginx.conf中進(jìn)行修改。

$ cat /etc/nginx/nginx.conf
http {
  ...
  proxy_connect_timeout  600;   #連接超時(shí)時(shí)間
  proxy_send_timeout     600;   #發(fā)送超時(shí)時(shí)間
  proxy_read_timeout     600;   #讀取超時(shí)時(shí)間
    ...
}

修改完成后，需要重新啟動(dòng)Harbor服務(wù)和Nginx服務(wù)，使配置生效。

P2P鏡像分發(fā)技術(shù)將需要分發(fā)的文件做分片處理，生成種子文件，每個(gè)P2P節(jié)點(diǎn)都根據(jù)種子文件下載分片。做分片時(shí)可以將文件拆分成多個(gè)任務(wù)并行執(zhí)行，不同的節(jié)點(diǎn)可以從種子節(jié)點(diǎn)拉取不同的分片，下載完成之后自己再作為種子節(jié)點(diǎn)供別的節(jié)點(diǎn)下載。采用去中心化的拉取方式之后，流量被均勻分配到P2P網(wǎng)絡(luò)中的節(jié)點(diǎn)上，可以顯著提升分發(fā)速度。

1.2 P2P鏡像分發(fā)技術(shù)有哪些？

以下是一些常見的P2P鏡像分發(fā)技術(shù)：

Kraken： Uber使用Go語(yǔ)言開發(fā)而開源的一個(gè)鏡像P2P分發(fā)項(xiàng)目
Dragonfly： 阿里巴巴開源的 P2P 鏡像和文件分發(fā)系統(tǒng)，可以解決原生云應(yīng)用中面臨的分發(fā)問題。
BitTorrent： BitTorrent是一種常用的P2P文件分發(fā)協(xié)議，可以用于分發(fā)鏡像文件。BitTorrent協(xié)議將文件劃分為多個(gè)塊，每個(gè)塊由多個(gè)節(jié)點(diǎn)共享，下載者可以同時(shí)從多個(gè)節(jié)點(diǎn)下載塊，從而提高下載速度。
IPFS： IPFS（InterPlanetary File System）是一種分布式文件系統(tǒng)，可以用于存儲(chǔ)和分發(fā)鏡像文件。IPFS將文件分割為多個(gè)塊，每個(gè)塊由多個(gè)節(jié)點(diǎn)存儲(chǔ)，下載者可以從多個(gè)節(jié)點(diǎn)下載塊，從而提高下載速度和可靠性。
Docker Swarm： Docker Swarm是Docker官方提供的容器編排工具，可以用于分發(fā)鏡像文件。Docker Swarm將鏡像分發(fā)到多個(gè)節(jié)點(diǎn)上，下載者可以從多個(gè)節(jié)點(diǎn)下載鏡像，從而提高下載速度和可靠性。
Alibaba Cloud P2P鏡像服務(wù)： 阿里云提供了P2P鏡像服務(wù)，可以用于分發(fā)鏡像文件。P2P鏡像服務(wù)將鏡像分發(fā)到多個(gè)節(jié)點(diǎn)上，下載者可以從就近的節(jié)點(diǎn)下載鏡像，從而提高下載速度和可靠性。
需要注意的是，P2P鏡像分發(fā)技術(shù)需要在多個(gè)節(jié)點(diǎn)之間共享和下載文件，因此需要考慮安全性和版權(quán)問題。此外，不同的P2P鏡像分發(fā)技術(shù)有不同的實(shí)現(xiàn)方式和特點(diǎn)，需要根據(jù)實(shí)際情況選擇合適的技術(shù)。

二、Kraken P2P鏡像分發(fā)

項(xiàng)目地址：https://github.com/uber/kraken

2.1 Kraken是什么？

Kraken 是一個(gè) P2P 驅(qū)動(dòng)的 Docker 注冊(cè)表，專注于可擴(kuò)展性和可用性。它專為混合云環(huán)境中的 Docker 鏡像管理、復(fù)制和分發(fā)而設(shè)計(jì)。借助可插拔的后端支持，Kraken 可以作為分發(fā)層輕松集成到現(xiàn)有的 Docker 注冊(cè)表設(shè)置中。

自 2018 年初以來，Kraken 一直在 Uber 投入生產(chǎn)。在我們最繁忙的集群中，Kraken 每天分發(fā)超過 100 萬(wàn)個(gè) blob，其中包括 10 萬(wàn)個(gè) 1G+ blob。在生產(chǎn)負(fù)載高峰期，Kraken 在 30 秒內(nèi)分發(fā)了 20K 100MB-1G 的 blob。
??解決這個(gè)問題的方法有很多，比如劃分集群、增加緩存和負(fù)載均衡等，但較好的解決方法可能是采用P2P鏡像分發(fā)技術(shù)。Kraken是Uber使用Go語(yǔ)言開發(fā)而開源的一個(gè)鏡像P2P分發(fā)項(xiàng)目。其采用了無共享架構(gòu)，具有部署簡(jiǎn)單、容錯(cuò)性高的特點(diǎn)，所以整體上系統(tǒng)的運(yùn)維成本比較低。

解決這個(gè)問題的方法有很多，比如劃分集群、增加緩存和負(fù)載均衡等，但較好的解決方法可能是采用P2P鏡像分發(fā)技術(shù)。Kraken的核心是P2P文件分發(fā)，主要功能是容器鏡像的P2P分發(fā)，目前并不支持通用文件的分發(fā)。

2.2 Kraken組件

Kraken由Proxy、Build-Index、Tracker、Origin、Agent五個(gè)組件組成：

Proxy： 作為Kraken的門戶，實(shí)現(xiàn)了Docker Registry V2接口。
Build-Index： 和后端存儲(chǔ)對(duì)接，負(fù)責(zé)鏡像Tag和Digest的映射。
Origin： 和后端存儲(chǔ)對(duì)接，負(fù)責(zé)文件對(duì)象的存儲(chǔ)，在分發(fā)時(shí)作為種子節(jié)點(diǎn)。
Tracker ：P2P分發(fā)的中心服務(wù)，記錄節(jié)點(diǎn)內(nèi)容，負(fù)責(zé)形成P2P分發(fā)網(wǎng)絡(luò)。
Agent： 部署在節(jié)點(diǎn)上，實(shí)現(xiàn)了Docker Registry V2接口，負(fù)責(zé)通過P2P拉取鏡像文件。

2.3 特征

以下是 Kraken 的一些亮點(diǎn)：
高度可擴(kuò)展: Kraken 能夠以超過每臺(tái)主機(jī)最大下載速度限制的 50% 的速度分發(fā) Docker 映像。簇大小和圖像大小對(duì)下載速度沒有顯著影響。
每個(gè)集群至少支持 15k 臺(tái)主機(jī)。
支持任意大的斑點(diǎn)/層。我們通常將最大大小限制為 20G 以獲得最佳性能。
高度可用: 沒有組件是單點(diǎn)故障。
安全: 通過 TLS 支持上傳者身份驗(yàn)證和數(shù)據(jù)完整性保護(hù)。
可插拔存儲(chǔ)選項(xiàng): Kraken 不是管理數(shù)據(jù)，而是插入可靠的 blob 存儲(chǔ)選項(xiàng)，如 S3、GCS、ECR、HDFS 或其他注冊(cè)表。存儲(chǔ)界面簡(jiǎn)單，新選項(xiàng)易于添加。
無損跨集群復(fù)制: Kraken 支持集群間基于規(guī)則的異步復(fù)制。
最小的依賴性: 除了可插拔存儲(chǔ)，Kraken 僅對(duì) DNS 具有可選依賴性。

2.4 Kraken+Harbor的3種可選方案

結(jié)合Kraken的P2P鏡像分發(fā)技術(shù)，其基本思路是將Harbor作為鏡像管理系統(tǒng)，將Kraken作為鏡像分發(fā)工具，有三種可選方案：
方案一： 以Harbor作為統(tǒng)一的對(duì)外接口，將Kraken作為后端，后面對(duì)接Registry；
方案二： 以Kraken作為統(tǒng)一的對(duì)外接口，將Harbor作為后端；
方案三： 使用一個(gè)公共的Registry作為統(tǒng)一的后端，Harbor和Kraken都使用這個(gè)Registry。

其中，在第3種方案中解耦了兩個(gè)系統(tǒng)，當(dāng)Harbor或者Kraken出現(xiàn)問題時(shí)，另一個(gè)系統(tǒng)仍可以正常工作。這種方案要求Harbor和Kraken能訪問同一個(gè)Registry，最好是將Harbor和Kraken部署在同一個(gè)Kubernetes集群中，然后通過Service模式訪問同一個(gè)Registry服務(wù)。

如果不能將它們部署在同一個(gè)集群中，就需要跨集群訪問，效率受到影響。所以，當(dāng)Harbor和Kraken被部署在不同集群中時(shí)，也可采用第2種方案，這樣Kraken會(huì)對(duì)Harbor強(qiáng)依賴。Kraken通過Harbor對(duì)外暴露的Docker Registry V2接口訪問Harbor，用戶依舊可以通過Harbor管理鏡像，并通過Kraken分發(fā)鏡像。

在上所示的方案中，Harbor和Kraken共享Registry服務(wù)，鏡像數(shù)據(jù)只會(huì)在Registry中保存一份。通過Kraken的鏡像預(yù)熱功能，可以讓鏡像在推送到Harbor后，就在Kraken中緩存一份，用戶可以設(shè)置Kraken緩存的大小和過期策略。

在P2P分發(fā)系統(tǒng)中，當(dāng)開始分發(fā)一個(gè)文件時(shí)，P2P分發(fā)系統(tǒng)首先需要生成這個(gè)文件的種子文件（Torrent文件），在種子文件中包含了文件的基本信息、文件的分片信息、Tracker服務(wù)器（P2P中心服務(wù)）的地址等。

當(dāng)P2P網(wǎng)絡(luò)的節(jié)點(diǎn)需要下載文件時(shí)，會(huì)先獲取對(duì)應(yīng)文件的種子文件，然后從P2P中心服務(wù)上獲取每個(gè)分片可下載節(jié)點(diǎn)的信息，再按照分片去不同的節(jié)點(diǎn)上下載，在全部分片文件都下載完成之后再拼裝成一個(gè)完整的文件。具體的實(shí)現(xiàn)在不同的P2P分發(fā)系統(tǒng)中是不一樣的，但核心機(jī)制都一樣。

就Kraken而言，當(dāng)Kraken系統(tǒng)中沒有文件緩存而有節(jié)點(diǎn)需要下載這個(gè)文件時(shí)，Kraken會(huì)首先從后端存儲(chǔ)中取出這個(gè)文件，然后計(jì)算文件的種子信息，再進(jìn)行分片分發(fā)。

在生成種子文件時(shí)需要先下載文件，這屬于比較耗時(shí)的環(huán)節(jié)，Kraken為了省去下載文件的時(shí)間，設(shè)計(jì)了鏡像的預(yù)熱系統(tǒng)，用戶可以通過Kraken提供的接口告知Kraken即將需要分發(fā)的鏡像，Kraken會(huì)預(yù)先將對(duì)應(yīng)的鏡像從后端存儲(chǔ)中下載下來，并計(jì)算好種子文件等待分發(fā)，這大大縮短了鏡像分發(fā)的時(shí)長(zhǎng)。

2.5 Kraken的預(yù)熱流程

Kraken的預(yù)熱方案是基于Registry的通知機(jī)制實(shí)現(xiàn)的，如圖1-2所示，觸發(fā)的流程如下。
（1）用戶向Harbor端推送鏡像。
（2）Registry觸發(fā)通知機(jī)制，向Kraken-proxy發(fā)送通知請(qǐng)求。
（3）Kraken-proxy解析收到的請(qǐng)求，在這個(gè)請(qǐng)求中包含了推送鏡像的所有信息。
（4）Kraken-proxy向Kraken-origin請(qǐng)求獲取鏡像對(duì)應(yīng)的Manifest文件。
（5）Kraken-proxy解析Manifest文件，獲取鏡像所有的層文件信息。
（6）Kraken-proxy會(huì)逐個(gè)請(qǐng)求Kraken-origin下載每個(gè)層文件。
（7）Kraken-origin從Registry下載層文件時(shí)，會(huì)先將層文件都緩存在本地，計(jì)算出每個(gè)層文件的種子信息。

Kraken 的預(yù)熱方案會(huì)導(dǎo)致所有鏡像都被緩存到Kraken-origin中，從而導(dǎo)致Kraken-origin的磁盤吞吐量和占用都較高。為了避免這個(gè)問題，通常建議將測(cè)試和生產(chǎn)鏡像倉(cāng)庫(kù)分離，使用兩個(gè)Harbor，其中測(cè)試倉(cāng)庫(kù)獨(dú)立使用，生產(chǎn)環(huán)境集成Kraken使用P2P分發(fā)，在兩個(gè)倉(cāng)庫(kù)之間通過Harbor的遠(yuǎn)程復(fù)制功能實(shí)現(xiàn)鏡像同步。

因?yàn)橥ǔＶ挥性跍y(cè)試環(huán)境下驗(yàn)證通過的鏡像才會(huì)被發(fā)布到生產(chǎn)環(huán)境下的 Harbor 中，所以大大減少了生產(chǎn)倉(cāng)庫(kù)的壓力，也能減少 Kraken 系統(tǒng)中緩存鏡像的數(shù)量；將測(cè)試和生產(chǎn)環(huán)境分離時(shí)，可以將角色權(quán)限劃分清楚，實(shí)現(xiàn)多方協(xié)作。

Harbor在未來的版本規(guī)劃中設(shè)計(jì)了基于策略的預(yù)熱功能，可以根據(jù)設(shè)置的策略將匹配的鏡像預(yù)熱到Kraken中，這是解決問題的最好方案。

Complain that it is better to walk in the dark than to carry a lamp.文章來源地址http://www.zghlxwxcb.cn/news/detail-476799.html

到了這里，關(guān)于使用Harbor 和 Kraken 優(yōu)化鏡像拉取速的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！