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

摘要：繼重啓維護Dubbo後，阿里技術在開源方面的動態不斷，在中國開源年會上，阿里巴巴又正式開源了其自研容器技術Pouch。

在中國開源年會現場，阿里巴巴正式開源了基於 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

做者介紹

孫宏亮，阿里巴巴技術專家，畢業於浙江大學，目前在阿里巴巴負責容器項目 Pouch 的開源建設。數年來一直從事雲計算領域，是國內第一批研究和實踐容器技術的工程師，在國內起到極爲重要的容器技術佈道做用。擁有著做《Docker 源碼分析》，我的崇尚開源精神，同時是 Docker Swarm 項目的全球 Maintainer。