阿里巴巴正式開源自研容器技術Pouch

阿里巴巴正式開源自研容器技術 Pouch

11月19日上午，在《中國開源年會》現場，阿里巴巴正式開源了基於Apache 2.0協議的容器技術Pouch。Pouch是一款輕量級的容器技術，擁有快速高效、可移植性高、資源佔用少等特性，主要幫助阿里更快的做到內部業務的交付，同時提高超大規模下資料中心的物理資源利用率。開源之後，Pouch成為一項普惠技術，人人都可以在GitHub上獲取，GitHub專案地址：https://github.com/alibaba/pouch 。

Pouch的開源，是阿里看好容器技術的一個訊號。時至今日，全球範圍內，容器技術在大多數企業中落地，已然成為一種共識。如何做好容器的技術選型，如何讓容器技術可控，相信是每一個企業必須考慮的問題。Pouch無疑使得容器生態再添利器，在全球巨頭壟斷的容器開源生態中，為中國技術贏得了一塊陣地。

Pouch 技術現狀

此次開源Pouch，相信行業中很多專家都會對阿里目前的容器技術感興趣。到底阿里玩容器是一個俠之大者，還是後起之秀呢？以過去看未來，技術領域尤其如此，技術的沉澱與積累，大致可以看清一家公司的技術實力。

Pouch 演進

追溯Pouch的歷史，我們會發現Pouch起源於2011年。當時，Linux核心之上的namespace、cgroup等技術開始成熟，LXC等工具也在同時期誕生不久。阿里巴巴作為一家技術公司，即基於LXC研發了容器技術t4，並在當時以產品形態給集團內部提供服務。此舉被視為阿里對容器技術的第一次探索，也為阿里的容器技術積澱了最初的經驗。隨著時間的推移，兩年後，Docker橫空出世，其映象技術層面，極大程度上解決了困擾行業多年的“軟體封裝”問題。映象技術流行開來後，阿里沒有理由不去融合這個給行業帶來巨大價值的技術。於是，在2015年，t4在自身容器技術的基礎上，逐漸吸收社群中的Docker映象技術，慢慢演變，打磨為Pouch。

帶有映象創新的容器技術，似一陣颶風，所到之處，國內外無不叫好，阿里巴巴不外如是。2015年末始，阿里巴巴集團內部在基礎設施層面也在悄然發生變化。原因很多，其中最簡單的一條，相信大家也不難理解，阿里巴巴體量的網際網路公司，背後必定有巨大的資料中心在支撐，業務的爆炸式增長，必定導致基礎設施需求的增長，也就造成基礎設施成本的大幅提高。容器的輕量級與資源消耗低，加上映象的快速分發，迅速讓阿里巴巴下定決心，在容器技術領域加大投入，幫助資料中心全面升級。

阿里容器規模

經過兩年多的投入，阿里容器技術Pouch已經在集團基礎技術中，扮演著極其重要的角色。2017年雙11，鉅額交易1682億背後，Pouch在“超級工程”中做到了：

• 100%的線上業務Pouch化
• 容器規模達到百萬級

回到阿里集團內部，Pouch的日常服務已經覆蓋絕大部分的事業部，覆蓋的業務場景包括：電商、廣告、搜尋等；覆蓋技術棧包括：電商應用、資料庫、大資料、流計算等；覆蓋程式語言：Java、C++、NodeJS等。

Pouch 技術優勢

阿里巴巴容器技術如此之廣的應用範圍，對行業來說實屬一大幸事，因為阿里已經用事實說明：容器技術已經在大規模生產環境下得到驗證。然而，由於Pouch源自阿里，而非社群，因此在容器效果、技術實現等方面，兩套體系存在差異。換言之，Pouch存在不少獨有的技術優勢。

隔離性強

隔離性是企業走雲化之路過程中，無法迴避的一個技術難題。隔離性強，意味著技術具備了商用的初步條件；反之則幾乎沒有可能在業務線上鋪開。哪怕是阿里巴巴這樣的技術公司，實踐容器技術伊始，安全問題都無法倖免。眾所周知，行業中的容器方案大多基於Linux核心提供的cgroup和namespace來實現隔離，然後這樣的輕量級方案存在弊端：

• 容器間，容器與宿主間，共享同一個核心；
• 核心實現的隔離資源，維度不足。

面對如此的核心現狀，阿里巴巴採取了三個方面的工作，來解決容器的安全問題：

• 使用者態增強容器的隔離維度，比如網路頻寬、磁碟使用量等；
• 給核心提交patch，修復容器的資源可見性問題，cgroup方面的bug；
• 實現基於Hypervisor的容器，通過建立新核心來實現容器隔離。

容器安全的研究，在行業中將會持續相當長時間。而阿里在開源Pouch中，將在原有的安全基礎上，繼續融合lxcfs等特性與社群共享。同時阿里巴巴也在計劃開源“阿里核心”，將多年來阿里對Linux核心的增強回饋行業。

P2P 映象分發

隨著阿里業務爆炸式增長，以及2015年之後容器技術的迅速普及，阿里容器映象的分發也同時成為亟待解決的問題。雖然，容器映象已經幫助企業在應用檔案複用等方面，相較傳統方法做了很多優化，但是在數以萬計的叢集規模下，分發效率依然令人抓狂。舉一個簡單例子：如果資料中心中有10000臺物理節點，每個節點同時向映象倉庫發起映象下載，映象倉庫所在機器的網路壓力，CPU壓力可想而知。

基於以上場景，阿里巴巴映象分發工具“蜻蜓”應運而生。蜻蜓是基於智慧P2P技術的通用檔案分發系統。解決了大規模檔案分發場景下分發耗時、成功率低、頻寬浪費等難題。大幅提升釋出部署、資料預熱、大規模容器映象分發等業務能力。目前，“蜻蜓”和Pouch同時開源，專案地址為：https://github.com/alibaba/dragonfly 。Pouch與蜻蜓的使用架構圖如下：

富容器技術

阿里巴巴集團內部囊括了各式各樣的業務場景，幾乎每種場景都對Pouch有著自己的要求。如果使用外界“單容器單程式”的方案，在業務部門推行容器化存在令人難以置信的阻力。阿里巴巴內部，基礎技術起著巨大的支撐作用，需要每時每刻都更好的支撐業務的執行。當業務執行時，技術幾乎很難做到讓業務去做改變，反過來適配自己。因此，一種對應用開發、應用運維都沒有侵入性的容器技術，才有可能大規模的迅速鋪開。否則的話，容器化過程中，一方面得不到業務方的支援，另一方面也需要投入大量人力幫助業務方，非標準化的實現業務運維。

阿里深諳此道，內部的Pouch技術可以說對業務沒有任何的侵入性，也正是因為這一點在集團內部做到100%容器化。這樣的容器技術，被無數阿里人稱為“富容器”。

“富容器”技術的實現，主要是為了在Linux核心上建立一個與虛擬機器體驗完全一致的容器。如此一來，比一般容器要功能強大，內部有完整的init程式，以及業務應用需要的任何服務，當然這也印證了Pouch為什麼可以做到對應用沒有“侵入性”。技術的實現過程中，Pouch需要將容器的執行入口定義為systemd，而在核心態，Pouch引入了cgroup namespace 這一最新的核心patch，滿足systemd在富容器模式的隔離性。從企業運維流程來看，富容器同樣優勢明顯。它可以在應用的Entrypoint啟動之前做一些事情，比如統一要做一些安全相關的事情，運維相關的agent拉起。這些需要統一做的事情，倘若放到使用者的啟動指令碼，或映象中就對使用者的應用誕生了侵入性，而富容器可以透明的處理掉這些事情。

核心相容性

容器技術的井噴式發展，使得不少走在技術前沿的企業享受到技術紅利。然後，“長尾效應”也註定技術演進存在漫長週期。Pouch的發展也在規模化程式中遇到相同問題。

但凡規模達到一定量，“摩爾定律”決定了資料中心會存有遺留資源，如何利用與處理這些物理資源，是一個大問題。阿里集團內部也是如此，不管是不同型號的機器，還是從2.6.32到3.10+的Linux核心，異構現象依然存在。倘若要使所有應用執行Pouch之中，Pouch就必須支援所有核心版本，而現有的容器技術支援的Linux核心都在3.10以上。不過技術層面萬幸的是，對2.6.32等老版本核心而言，namespace的支援僅僅缺失user namespace；其他namespace以及常用的cgroup子系統均存在；但是/proc/self/ns等用來記錄namespace的輔助檔案當時還不存在，setns等系統呼叫也需要在高版本核心中才能支援。而阿里的技術策略是，通過一些其他的方法，來繞過某些系統呼叫，實現老版本核心的容器支援。

當然，從另一個角度而言，富容器技術也很大程度上，對老版本核心上的其他運維繫統、監控系統、使用者使用習慣等實現了適配，保障Pouch在核心相容性方面的高可用性。

因此綜合來看，在Pouch的技術優勢之上，我們不難發現適用Pouch的應用場景：傳統IT架構的的迅速容器化，企業大規模業務的部署，安全隔離要求高穩定性要求高的金融場景等。

Pouch架構

憑藉差異化的技術優勢，Pouch在阿里巴巴大規模的應用場景下已經得到很好的驗證。然而，不得不說的是：目前阿里巴巴內部的Pouch與當前開源版本依然存在一定的差異。

雖然優勢明顯，但是如果把內部的Pouch直接開源，這幾乎是一件不可能的事。多年的發展，內部Pouch在服務業務的同時，存在與阿里內部基礎設施、業務場景耦合的情況。耦合的內容，對於行業來說通用性並不強，同時涉及一些其他問題。因此，Pouch開源過程中，第一要務即解耦內部依賴，把最核心的、對社群同樣有巨大價值的部分開源出來。同時，阿里希望在開源的最開始，即與社群站在一起，共建Pouch的開源社群。隨後，以開源版本的Pouch逐漸替換阿里巴巴集團內部的Pouch，最終達成Pouch內外一致的目標。當然，在這過程中，內部Pouch的解耦工作，以及外掛化演進工作同樣重要。而在Pouch的開源計劃中，明年3月底會是一個重要的時間點，彼時Pouch的1.0版本將釋出。

從計劃開源的第一刻開始，Pouch在生態中的架構圖就設計如下：

Pouch的生態架構可以從兩個方面來看：第一，如何對接容器編排系統；第二，如何加強容器執行時。

容器編排系統的支援，是Pouch開源計劃的重要板塊。因此，設計之初，Pouch就希望自身可以原生支援Kubernetes等編排系統。為實現這點，Pouch在行業中率先支援container 1.0.0。目前行業中的容器方案containerd主要停留在0.2.3版本，新版本的安全等功能還無法使用，而Pouch已經是第一個吃螃蟹的人。當前Docker依然是Kubernetes體系中較火的容器引擎方案，而Kubernetes在runtime層面的戰略計劃為使用cri-containerd降低自身與商業產品的耦合度，而走相容社群方案的道路，比如cri-containerd以及containerd社群版。另外，需要額外提及的是，內部的Pouch是阿里巴巴排程系統Sigma的重要組成部分，同時支撐著“混部”工程的實現。Pouch開源路線中，同樣會以支援“混部”為目標。未來，Sigma的排程（scheduling）以及混部（co-location）能力有望服務行業。

生態方面，Pouch立足開放；容器執行時方面，Pouch主張“豐富”與“安全”。runC的支援，可謂順其自然。runV的支援，則表現出了和生態的差異性。雖然docker預設支援runV，然而在docker的API中並非做到對“容器”與“虛擬機器”的相容，從而Docker並非是一個統一的管理入口。而據我們所知，現有企業中仍有眾多存量虛擬機器的場景，因此，在迎接容器時代時，如何通過統一的運維入口，同時管理容器和虛擬機器，勢必會是“虛擬機器邁向容器”這個變遷過渡期中，企業最為關心的方案之一。Pouch的開源形態，很好的覆蓋了這一場景。runlxc是阿里巴巴自研的lxc容器執行時，Pouch對其的支援同時也意味著runlxc會在不久後開源，覆蓋企業內部擁有大量低版本Linux核心的場景。

Pouch對接生態的架構如下，而Pouch內部自身的架構可參考下圖：

和傳統的容器引擎方案相似，Pouch也呈現出C/S的軟體架構。命令列CLI層面，可以同時支援Pouch CLI以及Docker CLI。對接容器runtime，Pouch內部通過container client通過gRPC呼叫containerd。Pouch Daemon的內部採取元件化的設計理念，抽離出相應的System Manager、Container Manager、Image Manager、Network Manager、Volume Manager提供統一化的物件管理方案。

寫在最後

如今Pouch的開源，意味著阿里積累的容器技術將走出阿里，面向行業。而Pouch的技術優勢，決定了其自身會以一個差異化的容器解決方案，供使用者選擇。
企業在走雲化之路，擁抱雲原生（Cloud Native）時，Pouch致力於成為一款強有力的軟體，幫助企業的數字化轉型做到最穩定的支援。

Pouch目前已經在GitHub上開源，GitHub地址為： https://github.com/alibaba/pouch ，歡迎任何形式的開源參與。