云效平臺2017-11-27 13:44:21瀏覽315評論0發表于：阿里云效平臺
linux安全架構docker開源鏡像電商容器數據中心云效蜻蜓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。
本文為云棲社區原創內容，未經允許不得轉載，如需轉載請發送郵件至yqeditor@list.alibaba-inc.com；如果您發現本社區中有涉嫌抄襲的內容，歡迎發送郵件至：yqgroup@service.aliyun.com 進行舉報，并提供相關證據，一經查實，本社區將立刻刪除涉嫌侵權內容。
