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

阿里云云棲社群發表於2017-11-27
阿里

linux 安全 架構 docker 開源 映象 電商 容器 資料中心 雲效 蜻蜓 pouch

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



0acdac1b1944a2a86825e571875f63e2be795b82





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
















34fcaae2985add9be896fbbca823d948ea16aa41




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



但凡規模達到一定量，“摩爾定律”決定了資料中心會存有遺留資源，如何利用與處理這些物理資源，是一個大問題。阿里集團內部也是如此，不管是不同型號的機器，還是從 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 開源過程中，第一要務即解耦內部依賴，把最核心的、對社群同樣有巨大價值的部分開源出來。同時，阿里希望在開源的最開始，即與社群站在一起，共建 Pouch 的開源社群。隨後，以開源版本的 Pouch 逐漸替換阿里巴巴集團內部的 Pouch，最終達成 Pouch 內外一致的目標。當然，在這過程中，內部 Pouch 的解耦工作，以及外掛化演進工作同樣重要。而在 Pouch 的開源計劃中，明年 3 月底會是一個重要的時間點，彼時 Pouch 的 1.0 版本將釋出。


405bb7122a318e7f2f1398ab025a9fa6c5ab6c5c


容器編排系統的支援，是 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 核心的場景。


484a4626f29deaaa119e6b3a428e937e5c91febe











原文連結


相關文章