Uber開源P2P容器倉庫Kraken，每秒分布TB級數據

Docker容器倉庫的主要職能是存儲和分布Docker鏡像。這是個看似容易的任務，但是當計算集群達到Uber的規模後，容器倉庫很容易成為系統的瓶頸。尤其在混合雲多活架構下，鏡像分布變得更加複雜。

為了解決私有容器倉庫的性能問題，Uber開發了P2P的鏡像倉庫——Kraken（海怪）。

容器技術一直以來是Uber架構的基礎（ Uber為此還開發了自己的鏡像生成工具Makisu——卷簾），但是隨著計算集群的增長，簡單在私有容器倉庫的基礎上做數據分片和增加cache無法提供Uber所需的流量。

Kraken在2016年應運而生。這個項目著重於可擴展性和可用性，並且適用於再混合雲架構中的鏡像管理，復制和分布。Kraken還支持後台擴展，可以以其他容器倉庫為後台，單純的作為發布層來部署。

架構

Uber的工程師經過了幾輪設計，最終選定P2P的架構。Kraken使用的P2P協議基於BitTorrent，但是加以了改進，使其更適合在數據中心內部署的企業級應用。

Kraken本身不負責數據的存儲，而是支持多種存儲後台，比如AWS S3，HDFS，甚至是其他的應用倉庫。存儲後台的界面設計非常通用，開發者可以輕鬆的加入新的做到。

Kraken的各個部分都可以自我修復，任意單一機器的問題都不會對系統整體造成影響。假如有多個異地集群，Kraken還支持基於鏡像名的異地無損復制。

性能

Kraken在2018年初被部署入生產環境。自那以後，曾經的鏡像倉庫性能問題不復存在。

最忙碌的一個Kraken集群每天分布超過一百萬個鏡像層，其中有十萬個以上大小超過1GB。在高峰時期，Kraken可以在30秒內分布2萬個大小在100MB和1GB之間的鏡像層。

Kraken的可擴展性使其可以輕鬆支持超過8000台機器的計算集群，而且可以以最大下載速度50%以上的速度向集群中每台機器分布鏡像。事實上在Uber收集到的數據中，集群和鏡像的大小對下載速度沒有明顯的影響。

對比

對於第一次聽說Kraken的開發者而言，難免會問到Kraken和阿里巴巴Dragonfly（蜻蜓）項目的區別。Dragonfly的架構中，由超級節點決定每一塊4MB數據塊的流向。雖然超級節點理論上可以做出最優的選擇，但是整個集群的流量會被一台或幾台機器的處理能力所限制。隨著集群或鏡像大小的增加，性能會呈線性下降。

Kraken的架構中，中心部件Tracker只負責搭建起一個隨機正則圖的網路拓撲結構，但是具體的數據傳輸的協商是由每台機器上的peer進程負責，所以Kraken的性能不會太受集群和鏡像大小的影響。此外，Kraken是一個高可用性的系統，並且支持異地無損復制，適合使用於混合雲環境。

開源

自從內部使用以來，Kraken已被用來管理Uber的所有鏡像。

Uber希望可以通過開源這個項目，來引發更多Docker相關領域的討論。

假如您對Kraken的做到細節有興趣，請訪問Kraken的GitHub頁面：https://github.com/uber/kraken。

原文鏈接：https://eng.uber.com/introducing-kraken/