p2p-如何拯救k8s鏡像分發的阿喀琉斯之踵

K8s的出現為PaaS行業的發展打了一針興奮劑，Docker+k8s的技術路線已經成為了容器雲的主流。尤其針對大流量，大彈性的應用場景來說，k8s将其從繁雜的運維、部署工作中徹底拯救出來。然而事情往往沒有那麼簡單而美好，當我們使用k8s去管理一些大規模叢集的時候，我們會發現有很多問題等待我們解決。比如，當叢集中的所有節點同時去鏡像倉庫拉取鏡像的時候，這種大規模并發很有可能阻塞倉庫的出口，導緻大家的下載下傳速度都慢得難以忍受，這就是k8s鏡像分發的阿喀琉斯之踵。我們當然可以采取鏡像倉庫叢集化的方法來緩解這個瓶頸，然而這種做法始終是治标不治本，此外還會造成維護成本升高，以及鏡像同步時效性差等問題。

那麼如何解決這個讓人困擾的問題呢？

p2p看起來是一個好辦法，去中心化的做法，不但可以降低對倉庫節點的依賴，同時也可以為使用者節省寶貴的外網流量。但是在k8s叢集中拉取鏡像的場景内使用p2p技術要面對一系列困難，包括節點間資料安全性的問題、無預熱前提下的大規模并發拉取、非侵入式将叢集改造成p2p網絡等。經過不斷的探索與實驗，我們--華為雲容器鏡像服務，終于摸索出了一套在k8s叢集中完美整合p2p下載下傳的方案。該方案的提出有效的解決了我們遇到的實際問題，提高了鏡像下載下傳速度，并為客戶節省了大量帶寬資源。

p2p改造後的叢集下載下傳測試結果

如上圖所示，我們限制了鏡像倉庫的下載下傳帶寬，并測試了200節點與500節點情況下，不同下載下傳方式的狀況。随着節點數量的增大，并發量觸及到鏡像倉庫下載下傳瓶頸的可能性也随之增大，然而使用了p2p下載下傳方式改造的k8s叢集并沒有受到該瓶頸的制約，表現遠強于傳統下載下傳方式。尤其是對于較大的鏡像，差距更為明顯。

我們是如何把p2p下載下傳整合到k8s叢集内的呢？

在華為雲容器鏡像服務中我們是這樣做的，我們改變了所有叢集節點去鏡像倉庫拉取鏡像的傳統做法。在使用者節點中注入peer用戶端，使用peer用戶端截取docker client的拉取鏡像請求，并将請求重定向。經過修改後隻有部分節點（約10%）真正到達鏡像倉庫去擷取鏡像資料，剩餘節點轉為自叢集内的其它節點擷取鏡像。要實作這個方案，主要的開發點有三處：需要對鏡像倉庫進行改造，部署并改造新的tracker伺服器，以及在使用者節點注入peer用戶端。

對鏡像倉庫的改造

要想實作叢集的p2p下載下傳功能，所下載下傳的檔案必須包含有種子，是以要對已有的鏡像倉庫進行改造。當使用者push鏡像到鏡像倉庫時，倉庫自動計算鏡像所有layer的SHA值，并為每一個layer生成一個種子檔案。

為了保證叢集的安全性驗證，倉庫為每個接入的peer下發由倉庫私鑰簽名的jwt token，這個token将會進入叢集網絡，并保證叢集節點的認證安全。

部署改良後的tracker伺服器

傳統的Tracker伺服器的主要功能是為所有peer用戶端提供peer清單。針對k8s叢集場景，我們所搭建的Tracker伺服器除了負責分發peer清單外，還增加了許多其它特性。

1. 判斷peer節點的叢集歸屬，因為tracker伺服器可能對多個叢集進行服務，而每個叢集中的節點網絡相對獨立，是以tracker負責記錄peer節點的叢集歸屬資訊很有必要，這樣可以避免分發出網絡不互通的peer清單。

2. Tracker伺服器負責監控每個peer的狀态，自動将部分下載下傳完成的peer節點資源釋放，因為叢集節點屬于客戶資源，一旦完成任務應該盡快将資源釋放出去。當Tracker判斷目前叢集中完成節點比例已足夠支撐下載下傳時，會訓示部分已完結節點終結任務釋放資源，并将其移除出任務清單。當所有peer節點均已完成下載下傳，而且一段時間内沒有新的下載下傳請求進入，那麼Tracker會訓示将全部叢集節點資源釋放。

3. Tracker按比例（約10%）指定部分peer節點到鏡像倉庫下載下傳，以此将資料帶入整個叢集網絡。

4. Tracker提供peer節點的安全性驗證，保證同屬于一個叢集并下載下傳同一個資源的peer節點有擷取peer清單的權限。

容器化的peer用戶端

在這個解決方案中，我們創造性的将peer用戶端容器化，并通過華為雲容器引擎（CCE）的插件功能，将peer容器分發給整個叢集。peer容器可以通過修改docker用戶端代理的方式，攔截下載下傳鏡像請求的相關接口，将從鏡像倉庫下載下傳操作轉化為p2p網絡下載下傳操作，并把擷取到的鏡像資料歸還給docker用戶端，以此快速的把鏡像資料分發到整個叢集網絡。該peer用戶端還具有以下特性：

• 根據tracker的配置設定，修改下載下傳位址，小部分從鏡像倉庫下載下傳，大部分從叢集網絡中下載下傳。

• 在peer用戶端的tcp握手協定中注入jwt token安全校驗，保證節點資料安全，防止假冒節點盜取資料。

• Peer用戶端采用優先級下載下傳方式，能夠保證在下載下傳過程中就可以将資料傳輸給docker用戶端，而不是當資料全部下載下傳完全後再傳輸給docker，以此最大限度的節省下載下傳實際。

經過p2p方案改造後的k8s叢集，下載下傳速度得到了提升的同時，也為客戶節約了大量帶寬。目前這個特性已經在菊廠雲上開放給使用者使用，感興趣的同學們快來體驗吧。

本文轉自DockOne-

p2p-如何拯救k8s鏡像分發的阿喀琉斯之踵