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

NO IMAGE
雲效平臺 2017-11-27 13:44:21 瀏覽315 評論0 發表於: 阿里雲效平臺

linux 安全 架構 docker 開源 鏡像 電商 容器 數據中心 雲效 蜻蜓 pouch

摘要:

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

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

github.com/alibaba/pou…

阿里巴巴正式開源其自研容器技術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 在“超級工程”中做到了:

回到阿里集團內部,Pouch 的日常服務已經覆蓋絕大部分的事業部,覆蓋的業務場景包括:電商、廣告、搜索等;覆蓋技術棧包括:電商應用、數據庫、大數據、流計算等;覆蓋編程語言:Java、C++、NodeJS 等。


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

隔離性強

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


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


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

P2P 鏡像分發

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

基於以上場景,阿里巴巴鏡像分發工具“蜻蜓”應運而生。蜻蜓是基於智能 P2P 技術的通用文件分發系統。解決了大規模文件分發場景下分發耗時、成功率低、帶寬浪費等難題。大幅提升發佈部署、數據預熱、大規模容器鏡像分發等業務能力。目前,“蜻蜓”和 Pouch 同時開源,項目地址為:
github.com/alibaba/dra…

Pouch 與蜻蜓的使用架構圖如下:
阿里巴巴正式開源其自研容器技術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 的開源計劃中,明年 3 月底會是一個重要的時間點,彼時 Pouch 的 1.0 版本將發佈。

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

阿里巴巴正式開源其自研容器技術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

和傳統的容器引擎方案相似,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 地址為:
github.com/alibaba/pou…


作者介紹

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





本文為雲棲社區原創內容,未經允許不得轉載,如需轉載請發送郵件至[email protected];如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至:[email protected] 進行舉報,並提供相關證據,一經查實,本社區將立刻刪除涉嫌侵權內容。

原文鏈接

相關文章

【Linux】Linux服務器搭建JDK環境

【Linux】Linux下修改主機名簡單三步搞定

從商用到開源:DB2遷移至MySQL的最佳實踐

Docker鏡像與容器命令專題