PouchContainer 現(xiàn)在服務(wù)于阿里巴巴集團(tuán)和螞蟻金服集團(tuán)的絕大部分 BU， 包括交易&中間件，B2B/CBU/ICBU，搜索廣告數(shù)據(jù)庫(kù)，還有收購(gòu)或入股的一些公司，比如優(yōu)酷高德、UC等。其中體量***的是交易和電商平臺(tái)，在 2017 年雙 11 的時(shí)候我們支撐了破紀(jì)錄的峰值，背后的應(yīng)用都是跑在 PouchContainer 里面，整體容器實(shí)例已經(jīng)到了***規(guī)模。使用了 PouchContainer 的應(yīng)用涵蓋了各種各樣的場(chǎng)景。這些場(chǎng)景從運(yùn)行模式來(lái)看，有標(biāo)準(zhǔn)的在線(xiàn) App，還有像購(gòu)物車(chē)、廣告、測(cè)試環(huán)境等比較特殊的場(chǎng)景。不同的場(chǎng)景對(duì) PouchContainer 有不同的使用方式和需求。從編程語(yǔ)言看，實(shí)際運(yùn)行著 Java、C/C++，Nodejs，GoLang 等語(yǔ)言編寫(xiě)的應(yīng)用。從技術(shù)棧的角度看，包含了電商、DB、流計(jì)算、大數(shù)據(jù)、專(zhuān)有云等場(chǎng)景，每個(gè)場(chǎng)景對(duì)于容器各方面要求，所用到的特性都不太一樣，PouchContainer 針對(duì)每個(gè)場(chǎng)景的需求都在產(chǎn)品上都做了支持。

PouchContainer 容器技術(shù)在阿里的演進(jìn)過(guò)程伴隨著阿里技術(shù)架構(gòu)本身的演進(jìn)。阿里內(nèi)部技術(shù)架構(gòu)經(jīng)歷了一個(gè)從集中式單體應(yīng)用到分布式微服務(wù)化的演進(jìn)。

淘寶最開(kāi)始是一個(gè)巨石型的應(yīng)用，一個(gè)應(yīng)用里包含了商品、用戶(hù)、下單等等所有交易鏈路的功能。隨著功能越來(lái)越完善，維護(hù)起來(lái)也越來(lái)越困難。為了提高研發(fā)效率，從 2008 年開(kāi)始我們逐漸把這個(gè)應(yīng)用拆分成了多個(gè)分布式應(yīng)用，商品的，交易的，用戶(hù)的，前臺(tái)的，后端的；通過(guò) HSF 遠(yuǎn)程調(diào)用框架，TDDL 分布式數(shù)據(jù)層和 Notify 分布式消息中間件串聯(lián)起來(lái)。其中每個(gè)服務(wù)都有多個(gè)實(shí)例，都可以獨(dú)立研發(fā)演進(jìn)，并可以進(jìn)一步繼續(xù)拆分。于是就逐漸形成了一個(gè)龐大的分布式服務(wù)集群。從巨石型應(yīng)用到多個(gè)單一功能的輕量級(jí)服務(wù)型應(yīng)用，總的應(yīng)用實(shí)例數(shù)變多了，每個(gè)實(shí)例需要的系統(tǒng)資源變少了。于是從最初的每個(gè)實(shí)例直接使用物理機(jī)自然過(guò)渡到使用 Xen，KVM 等虛擬化技術(shù)。VM 使用了一段時(shí)間之后，發(fā)現(xiàn)整體物理機(jī)的利用率還是很低。當(dāng)時(shí)一個(gè) 24 核的物理機(jī)只能虛出 4 臺(tái) 4 核的 VM，除了當(dāng)時(shí)虛擬化本身的開(kāi)銷(xiāo)不小外，每個(gè)應(yīng)用實(shí)例在 VM 里仍然用不完分到的資源。于是就想能不能不用虛擬機(jī)，用更輕量的基于進(jìn)程級(jí)別的資源切分使用方式。

這個(gè)時(shí)候阿里內(nèi)部的運(yùn)維體系已經(jīng)比較龐大了，從應(yīng)用的構(gòu)建部署到分發(fā)，到一些運(yùn)行期的監(jiān)控告警等管控系統(tǒng)，都依賴(lài)于一個(gè)應(yīng)用實(shí)例跑在一個(gè)獨(dú)立機(jī)器里的假定。這個(gè)假定已經(jīng)不經(jīng)意間貫穿到了研發(fā)運(yùn)維的各個(gè)環(huán)節(jié)里面，包括系統(tǒng)的設(shè)計(jì)，運(yùn)維習(xí)慣等都嚴(yán)重依賴(lài)這個(gè)假定。我們不可能重新搭建集群，把存量的業(yè)務(wù)停掉再到新的集群里面用新的運(yùn)維模式去跑起來(lái)，這個(gè)業(yè)務(wù)和運(yùn)維上都是沒(méi)法接受的，不可能電商交易的研發(fā)停幾個(gè)月，系統(tǒng)停幾天來(lái)搞這個(gè)事情。所以我們首先要做到兼容，新的資源使用方式必須兼容原先的假定。我們經(jīng)過(guò)仔細(xì)分析了這個(gè)假定的內(nèi)涵，發(fā)現(xiàn)每個(gè)應(yīng)用實(shí)例歸納下來(lái)無(wú)非有如下 4 點(diǎn)要求：

• 有獨(dú)立IP
• 能夠SSH登陸
• 有獨(dú)立的，隔離的文件系統(tǒng)
• 資源隔離，并且使用量和可見(jiàn)性隔離

首先是有獨(dú)立 IP，能夠 SSH 登錄。其次有獨(dú)立的文件系統(tǒng)，應(yīng)用程序跑起來(lái)，希望程序看到的整個(gè)文件系統(tǒng)都是給他專(zhuān)用的，因?yàn)楝F(xiàn)有的代碼和配置中必然有很多路徑的硬編碼，需要滿(mǎn)足這個(gè)潛在要求。還有不管通過(guò)工具還是代碼，他只能看到分配給他自己的資源。比如 4 個(gè) CPU，8G 的內(nèi)存，他能夠根據(jù)這些資源的用量做一些監(jiān)控，做一些對(duì)自己資源使用量的采集和告警。這四個(gè)特點(diǎn)總結(jié)下來(lái)就是新的資源使用方式要做到和物理機(jī)或者 VM 的使用體驗(yàn)一致。能夠做到這樣的話(huà)原先跑在 VM 里的應(yīng)用就可以很平滑的遷移過(guò)來(lái)，現(xiàn)有的應(yīng)用系統(tǒng)和運(yùn)維系統(tǒng)不需要做很大的改動(dòng)。

我們?yōu)榱四苓_(dá)到這四點(diǎn)，最開(kāi)始是多隆大神手工 Hack 系統(tǒng)調(diào)用，glibc 基礎(chǔ)庫(kù)等，實(shí)現(xiàn)了一些資源上的隔離。像有獨(dú)立的 IP 可登錄 ，就用虛擬網(wǎng)卡，在每個(gè)容器里面起一個(gè) sshd 進(jìn)程；資源的隔離和可見(jiàn)性上，就用 Cgroup 和 Namespace 等內(nèi)核特性；后來(lái)發(fā)現(xiàn)開(kāi)源的 LXC 項(xiàng)目也在做同樣的事情，并且比手工 Hack 更通用化，更優(yōu)雅一些。于是我們集成 LXC，并且在內(nèi)核上加了定制的資源可見(jiàn)性隔離的 patch，讓用戶(hù)的實(shí)例只能看到分配給他的 CPU和內(nèi)存，另外還增加了基于目錄的磁盤(pán)空間隔離的 patch，這樣就形成了我們***代的容器產(chǎn)品。這個(gè)產(chǎn)品當(dāng)時(shí)代號(hào)是 T4，寓意是第四代淘寶技術(shù)，淘寶 4.0；在 2011 年的時(shí)候 T4 容器技術(shù)灰度上線(xiàn)。T4 相比 VM，完全沒(méi)有虛擬化 Hypervisor 層的開(kāi)銷(xiāo)，資源切分和分配上更加靈活，可以支持不同程度的資源超賣(mài)。這樣就很好的支持了業(yè)務(wù)爆發(fā)增長(zhǎng)的需求，控制了物理機(jī)按業(yè)務(wù)增長(zhǎng)比例膨脹的勢(shì)頭。另外因?yàn)?T4 完全兼容了之前研發(fā)和運(yùn)維對(duì)物理機(jī)和 VM 的使用習(xí)慣，絕大多數(shù)應(yīng)用都能夠做到透明的切換，應(yīng)用無(wú)感知。因?yàn)橛羞@些特性，在接下來(lái)的短短幾年時(shí)間里，T4 逐步接管了交易和電商主體的在線(xiàn)應(yīng)用。

到 2015 年的時(shí)候 Docker 技術(shù)火起來(lái)了。我們寫(xiě)程序的都知道有個(gè)著名的公式，程序=數(shù)據(jù)結(jié)構(gòu)+算法。從程序交付使用變成一個(gè)軟件產(chǎn)品的角度來(lái)看，我們可以套用這個(gè)公式：

• 軟件= 文件（集）+ 進(jìn)程（組）；

從靜態(tài)來(lái)看，軟件從構(gòu)建分發(fā)到部署，最終形式是一個(gè)有依賴(lài)層次的文件集。從動(dòng)態(tài)來(lái)看，這些文件集，包括二進(jìn)制和配置，由操作系統(tǒng)加載到內(nèi)存后執(zhí)行，就是一個(gè)有交互關(guān)系的進(jìn)程組。我們之前的 T4 容器在進(jìn)程（組），或者說(shuō)運(yùn)行時(shí)上做的事情和 Docker 基本類(lèi)似，比如說(shuō)都使用了 Cgroup、Namespace、linux bridge 等技術(shù)。還有些是 T4 特有的，比如基于目錄的磁盤(pán)空間的隔離，資源可見(jiàn)性隔離，對(duì)老版本內(nèi)核的兼容等。我們從最早物理機(jī)演化到 VM，再到現(xiàn)在的容器，內(nèi)核的升級(jí)周期比較漫長(zhǎng)，迭代很慢，15年的時(shí)候存量的機(jī)器上全部都是 2.6.32 內(nèi)核，T4是兼容 2.6.32 內(nèi)核的。 但是另一方面在文件（集）的處理上 Docker 做得更好，更加系統(tǒng)化。 T4 只做了很薄的一層鏡像，給相同的業(yè)務(wù)域做了一個(gè)基礎(chǔ)的運(yùn)行和配置環(huán)境，這個(gè)鏡像沒(méi)有深入到每一個(gè)特定的應(yīng)用。 而 Docker 是將每個(gè)應(yīng)用的整個(gè)依賴(lài)棧打包到了鏡像中。因此在 2015 年我們引入了 Docker 的鏡像機(jī)制來(lái)完善自己的容器。

在將 Docker 鏡像整合進(jìn)來(lái)之后，原來(lái)基于 T4 的研發(fā)運(yùn)維體系受到了很大的沖擊。 首先交付方式變了，之前是 build 一個(gè)應(yīng)用的代碼包，把代碼包交給我們的部署發(fā)布系統(tǒng)，后者創(chuàng)建一個(gè)空的容器，根據(jù)這個(gè)業(yè)務(wù)所在的很薄的模板把一個(gè)空的容器跑起來(lái)，再到容器里面安裝依賴(lài)的一些 IPM 包，設(shè)置一些配置，按每個(gè)應(yīng)用定好的一個(gè)列表一個(gè)一個(gè)的安裝好，然后把應(yīng)用包解壓?jiǎn)?dòng)起來(lái)。這個(gè)應(yīng)用依賴(lài)的軟件和配置列表我們內(nèi)部叫做應(yīng)用的基線(xiàn)。引入鏡像之后，在將 Docker 鏡像整合進(jìn)來(lái)之后，原有的交付方式發(fā)生了變化。之前是 build 一個(gè)應(yīng)用的代碼包，把代碼包交給我們的部署發(fā)布系統(tǒng)，后者創(chuàng)建一個(gè)空的容器，根據(jù)這個(gè)業(yè)務(wù)對(duì)應(yīng)的很薄的一個(gè)模板，把一個(gè)空的容器跑起來(lái)，再到容器里面安裝依賴(lài)的一些 RPM 包，設(shè)置一些配置，按每個(gè)應(yīng)用定好的一個(gè)清單一個(gè)一個(gè)的安裝好，然后把應(yīng)用包解壓到主目錄啟動(dòng)起來(lái)。這個(gè)應(yīng)用依賴(lài)的軟件和配置清單我們內(nèi)部叫做應(yīng)用的基線(xiàn)。引入鏡像之后，我們應(yīng)用的代碼包和依賴(lài)的所有的這些三方軟件、二方軟件都會(huì)打成一個(gè)鏡像。之前通過(guò)基線(xiàn)維護(hù)應(yīng)用依賴(lài)環(huán)境，現(xiàn)在都放到每個(gè)應(yīng)用自己的 Dockerfile 中了，整個(gè)研發(fā)構(gòu)建和分發(fā)運(yùn)維的過(guò)程大大簡(jiǎn)化了。

做了這個(gè)事情之后，研發(fā)和運(yùn)維之間的職責(zé)和邊界就發(fā)生了變化。之前研發(fā)只需要關(guān)注功能，性能，穩(wěn)定性，可擴(kuò)展性，可測(cè)試性等等。引入了鏡像之后，因?yàn)橐约喝?xiě) Dockerfile，要了解這個(gè)技術(shù)依賴(lài)和運(yùn)行的環(huán)境倒底是什么，應(yīng)用才能跑起來(lái)，原來(lái)這些都是相應(yīng)運(yùn)維人員負(fù)責(zé)的。研發(fā)人員自己梳理維護(hù)起來(lái)后，就會(huì)知道這些依賴(lài)是否合理，是否可以?xún)?yōu)化等等。研發(fā)還需要額外關(guān)注應(yīng)用的可運(yùn)維性和運(yùn)維成本，關(guān)注自己的應(yīng)用是有狀態(tài)的還是無(wú)狀態(tài)的，有狀態(tài)的運(yùn)維成本就比較高。這個(gè)職責(zé)的轉(zhuǎn)換，可以更好的讓研發(fā)具備全棧的能力，思考問(wèn)題涵蓋運(yùn)維領(lǐng)域后，對(duì)如何設(shè)計(jì)更好的系統(tǒng)會(huì)帶來(lái)更深刻的理解。所以引入 Docker 之后對(duì)研發(fā)也提出了新的要求。我們總結(jié)新的時(shí)期，新的運(yùn)維模式下對(duì)研發(fā)能力要求的幾個(gè)要素，總結(jié)起來(lái)就是幾個(gè)原則：

為了更好的把自己的系統(tǒng)建設(shè)好，我們要倡導(dǎo)研發(fā)從***天建立系統(tǒng)的時(shí)候，就要考量最終的可運(yùn)維性，比如參數(shù)是否可配置，是否可以隨時(shí)重啟。機(jī)器每天都有硬件故障產(chǎn)生，這些硬故障不可能每天都人工處理，必須要盡可能自動(dòng)化處理，自動(dòng)化處理時(shí)，雖然有些故障只影響了一部分實(shí)例，另一部分是好的，但是也可能需要一起處理，比如需要物理機(jī)上的業(yè)務(wù)全部遷移走來(lái)維修物理機(jī)的時(shí)候。所以不管當(dāng)時(shí)容器里的業(yè)務(wù)是好的還是不好的，都要滿(mǎn)足隨時(shí)可重啟，可遷移的要求。原來(lái)是部分交付，現(xiàn)在要考慮你到底運(yùn)行環(huán)境是什么樣的，什么樣的運(yùn)行環(huán)境才能跑起來(lái)，盡量做標(biāo)準(zhǔn)化的操作。比如說(shuō)啟動(dòng)，Dockerfile 里面寫(xiě)好啟動(dòng)的路徑，不要再搞一些特殊的處理，如果有任何特殊的處理都沒(méi)法做統(tǒng)一的調(diào)度和運(yùn)維。統(tǒng)一的業(yè)務(wù)遷移，機(jī)器騰挪也沒(méi)法做。我們的目標(biāo)其實(shí)就是從一開(kāi)始的比較粗放的運(yùn)維，到不斷的開(kāi)發(fā)自動(dòng)化的工具和系統(tǒng)，形成一個(gè)體系，通過(guò)前期人工運(yùn)維的過(guò)程把一些固定的故障處理的流程模式化，***提取出來(lái)一些可以自動(dòng)處理故障，自動(dòng)恢復(fù)的機(jī)制。我們的最終目標(biāo)是無(wú)人職守。所有這些加起來(lái)其實(shí)就是我們引入鏡像化之后，并且要朝著無(wú)人值守的方向演進(jìn)時(shí)，對(duì)研發(fā)和運(yùn)維的新的要求。

上面是 PouchContainer 容器的 Roadmap， 2011 年的時(shí)候 T4上線(xiàn) ，到 2015 年 3 月的T4 覆蓋了交易的大部分應(yīng)用。這個(gè)時(shí)候開(kāi)始引入了 Docker 鏡像機(jī)制，這里面做了很多兼容性的工作。比如說(shuō)原來(lái) T4 輕量化的模板轉(zhuǎn)化成對(duì)應(yīng)的基礎(chǔ)鏡像，里面兼容了很多之前運(yùn)維的習(xí)慣和運(yùn)維的工具，如賬號(hào)推送，安全策略，系統(tǒng)檢測(cè)。我們?cè)?2016 年初上線(xiàn)了***個(gè)鏡像化應(yīng)用，到 5 月份的時(shí)候集團(tuán)決定主站全部應(yīng)用容器化。在做鏡像之前阿里是有一兩百人的團(tuán)隊(duì)做每個(gè)應(yīng)用的部署，運(yùn)維，穩(wěn)定性控制，后來(lái)這個(gè)團(tuán)隊(duì)都沒(méi)有了，全部轉(zhuǎn)成了 DevOps，轉(zhuǎn)向開(kāi)發(fā)工具和運(yùn)維平臺(tái)，通過(guò)代碼的方式，工具的方式解決運(yùn)維的問(wèn)題。之前專(zhuān)職做運(yùn)維的同學(xué)***的負(fù)擔(dān)就是線(xiàn)上環(huán)境的變更，研發(fā)提交變更申請(qǐng)給運(yùn)維同學(xué)，運(yùn)維同學(xué)做線(xiàn)上操作，研發(fā)不知道代碼運(yùn)行環(huán)境具體依賴(lài)了哪些基礎(chǔ)軟件。做了鏡像化的事情后，研發(fā)自己負(fù)責(zé)編寫(xiě) Dockerfile，運(yùn)維就把環(huán)境變更的事情通過(guò) Dockerfile 的機(jī)制移交給了研發(fā)。運(yùn)維和研發(fā)之間的邊界就非常清楚了，這個(gè)邊界就是由 Dockerfile 來(lái)定義的。研發(fā)負(fù)責(zé)把他代碼依賴(lài)的環(huán)境在 Dockerfile 定義好，運(yùn)維保證其構(gòu)建分發(fā)時(shí)沒(méi)有問(wèn)題。我們?cè)?2016 年雙11的時(shí)候完成了交易核心應(yīng)用的鏡像化 PouchContainer 化改造。在 2017 年雙11的時(shí)候交易全部應(yīng)用完成了鏡像化改造。然后我們?cè)?2017 年 11 月 19 日的時(shí)候宣布了 PouchContainer 的正式開(kāi)源。

我們的內(nèi)部 PouchContainer 經(jīng)過(guò)大規(guī)模的運(yùn)行，支持了各種各樣的業(yè)務(wù)場(chǎng)景，各種不同的技術(shù)棧，不同的運(yùn)行形態(tài)，積累了非常多的經(jīng)驗(yàn)。這些經(jīng)驗(yàn)之前跟阿里內(nèi)部的環(huán)境耦合性比較大。比如說(shuō)我們的網(wǎng)絡(luò)模型，我們其實(shí)是嵌入到了阿里內(nèi)部的網(wǎng)絡(luò)管控平臺(tái)，包括IP分配在內(nèi)部都有獨(dú)立的系統(tǒng)去完成。比如什么時(shí)候啟用 IP，什么時(shí)候下發(fā)路由等等，這些是有一個(gè)統(tǒng)一的 SDN 網(wǎng)絡(luò)管理系統(tǒng)來(lái)管理的。還有類(lèi)似的內(nèi)部存儲(chǔ)系統(tǒng)，還有運(yùn)維的一些指令推送系統(tǒng)。內(nèi)部系統(tǒng)耦合性比較大，沒(méi)法直接開(kāi)源。所以我們***選擇的策略是先在外部孵化一個(gè)從零開(kāi)始全新的項(xiàng)目，把內(nèi)部的特性一點(diǎn)點(diǎn)搬上去。這個(gè)過(guò)程中我們內(nèi)部的版本也會(huì)做重構(gòu)，把內(nèi)部的依賴(lài)做一些插件化解耦合的方式，這樣***全新的項(xiàng)目在外部可以跑得很好；在內(nèi)部用一些耦合內(nèi)部環(huán)境的插件也可以跑起來(lái)，最終的目標(biāo)是內(nèi)外用一套開(kāi)源版本。

那么我們的 PouchContainer 容器相對(duì)于其他容器有什么差異呢？主要體現(xiàn)在隔離性、鏡像分發(fā)優(yōu)化、富容器模式、規(guī)模化應(yīng)用和內(nèi)核兼容性幾個(gè)方面。傳統(tǒng)的容器隔離維度就是 namespace、cgroup；在資源可見(jiàn)性方面，我們前幾年是通過(guò)在內(nèi)核上打 patch，在容器內(nèi)看內(nèi)存和 CPU 利用率等數(shù)據(jù)時(shí)，把統(tǒng)計(jì)數(shù)值和當(dāng)前容器的 Cgroup 和 Namespace 關(guān)聯(lián)起來(lái)，使容器能使用的資源和已使用的資源都是容器自己的。18年的時(shí)候我們引入了社區(qū)的lxcfs，這樣就不需要對(duì)特定內(nèi)核 patch 的依賴(lài)了。磁盤(pán)空間的限制也是在低版本內(nèi)核上加了補(bǔ)丁，支持了基于文件目錄的磁盤(pán)空間隔離，能夠把每個(gè)容器的 rootfs 限制住。在 4.9 以上的內(nèi)核上，我們是用 overlay2 文件系統(tǒng)來(lái)完成同樣功能的。我們也在做基于 hypervisor 的容器方案，提升容器的隔離性和安全性，我們?cè)?PouchContainer 里面集成了 RunV，用于一些多租戶(hù)的場(chǎng)景。

阿里內(nèi)部的離在線(xiàn)混部之所以能推進(jìn)，在同一個(gè)機(jī)器上既能跑在線(xiàn)的業(yè)務(wù)又能跑離線(xiàn)的一些任務(wù)，互相之間不會(huì)出現(xiàn)太大的干擾，其核心的技術(shù)就是 PouchContaienr 容器可以根據(jù)優(yōu)先級(jí)，把不同業(yè)務(wù)的資源使用隔離開(kāi)來(lái)，保證在線(xiàn)業(yè)務(wù)優(yōu)先使用資源。這個(gè)資源包括很多的維度，比如 CPU、內(nèi)存，CPU cache、磁盤(pán)、網(wǎng)絡(luò)等等。

這是 PouchContainer 的鏡像分發(fā)設(shè)計(jì)。我們內(nèi)部有很多比較核心的應(yīng)用，體量比較大，實(shí)例會(huì)分布在上萬(wàn)臺(tái)物理機(jī)上。發(fā)布新版本的時(shí)候上萬(wàn)臺(tái)機(jī)器同時(shí)拉鏡像，任何中心的鏡像倉(cāng)庫(kù)都扛不住。因此我們?cè)O(shè)計(jì)了一套鏡像分發(fā)的二級(jí)架構(gòu)，在每個(gè)地域建一個(gè) mirror，在同一個(gè)地域內(nèi)拉鏡像的時(shí)候用 P2P 分發(fā)技術(shù)---我們內(nèi)部的產(chǎn)品名叫蜻蜓，已經(jīng)開(kāi)源；需要拉鏡像的服務(wù)器之間可以分散互相拉文件片段，這樣就直接化解了中心鏡像倉(cāng)庫(kù)的服務(wù)壓力和網(wǎng)絡(luò)壓力。后面其實(shí)還有更好的解決鏡像分發(fā)的思路，我們正在嘗試鏡像的遠(yuǎn)程化，通過(guò)存儲(chǔ)計(jì)算分離技術(shù)，用遠(yuǎn)程盤(pán)的方式掛載鏡像，直接跳過(guò)或者說(shuō)異步化了鏡像分發(fā)這一步，目前正在內(nèi)部環(huán)境灰度運(yùn)行中。

這是 PouchContainer 內(nèi)部版本的體系結(jié)構(gòu)。在***層的宿主機(jī)層面，我們會(huì)做一些管理和運(yùn)維，目的是為了確保容器運(yùn)行依賴(lài)的基礎(chǔ)環(huán)境是健康的，包括宿主機(jī)的一些鏡像清理，包括安全控制、權(quán)限管理等。OS 的低版本內(nèi)核我們是適配到*** 2.6.32 內(nèi)核，包括容器里面的進(jìn)程管理也做了很多的適配。資源隔離前面講過(guò)了，網(wǎng)絡(luò)模型我們內(nèi)部其實(shí)主體用的是 Bridge，但是其他各種各樣的場(chǎng)景也都支持。我們開(kāi)發(fā)了很多插件，PouchContainer 開(kāi)源后，我們才將這些插件逐步做了標(biāo)準(zhǔn)化，兼容適配了社區(qū)的 CNI 標(biāo)準(zhǔn)。最上層是一個(gè)富容器模式的支持，每個(gè)容器里面會(huì)啟動(dòng)一些跟內(nèi)部的運(yùn)維工具，運(yùn)維系統(tǒng)息息相關(guān)的一些組件，包括一些發(fā)布模式的優(yōu)化。可以看到我們內(nèi)部體系結(jié)構(gòu)是比較復(fù)雜的，尤其依賴(lài)內(nèi)部的其他系統(tǒng)比較多，在外部直接跑是跑不起來(lái)的，因此也沒(méi)法直接開(kāi)源。

所以我們開(kāi)源版本是重新開(kāi)始搭建的，這樣會(huì)比較清爽一些。我們引入了contained，支持不同的 runtime 實(shí)現(xiàn)，包括我們自己包裝 lxc 開(kāi)發(fā)的 RunLXC 運(yùn)行時(shí)，可以用來(lái)支持老版本 2.6.32 內(nèi)核。開(kāi)源版 PouchContainer 兼容所有 Docker 的接口，也支持 CRI 協(xié)議，這樣也就同時(shí)支持了比較主流的兩種集群管理系統(tǒng)。網(wǎng)絡(luò)方面我們內(nèi)部基于 libnetwork 做了增強(qiáng)，包括不同場(chǎng)景暴露出來(lái)的一些問(wèn)題，一些穩(wěn)定性，規(guī)模化的時(shí)候各種細(xì)節(jié)的一些優(yōu)化。存儲(chǔ)方面我們支持了多盤(pán)，內(nèi)存盤(pán)，遠(yuǎn)程盤(pán)等各種不同形式的存儲(chǔ)。PouchContainer 可以無(wú)縫集成到上層編排工具中，包括 Kubelet 和 Swarm 等。我們內(nèi)部的 Sigma 調(diào)度系統(tǒng)，不同的版本Docker 協(xié)議和CRI協(xié)議都會(huì)使用。

這是 PouchContainer 的開(kāi)源地址： https://github.com/alibaba/pouch

如何貢獻(xiàn)： https://github.com/alibaba/pou ... NG.md

最近 PouchContainer 開(kāi)源版本 GA 已經(jīng)發(fā)布，PouchContainer 能夠在如此短的時(shí)間內(nèi) GA，離不開(kāi)容器社區(qū)的支持，在超過(guò) 2300 個(gè) commit 的背后，有 80 多位社區(qū)開(kāi)發(fā)者的踴躍貢獻(xiàn)，其中不乏國(guó)內(nèi)一線(xiàn)互聯(lián)網(wǎng)公司、容器明星創(chuàng)業(yè)公司貢獻(xiàn)者的參與。

PouchContainer 開(kāi)源版本發(fā)布 GA 之前，此開(kāi)源容器引擎技術(shù)已在阿里巴巴數(shù)據(jù)中心得到大規(guī)模的驗(yàn)證；GA 之后，相信其一系列的突出特性同樣可以服務(wù)于行業(yè)，作為一種開(kāi)箱即用的系統(tǒng)軟件技術(shù)，幫助行業(yè)服務(wù)在推進(jìn)云原生架構(gòu)轉(zhuǎn)型上占得先機(jī)。

Q：你們是怎么樣做到把阿里巴巴集團(tuán)包括高德還有菜鳥(niǎo)那些，都能把這個(gè)技術(shù)推過(guò)去，因?yàn)榇蠊驹诓煌牟块T(mén)跨部門(mén)甚至是跨子公司之間要想推行你們的某一個(gè)部門(mén)的研究成果是一件比較困難的事情。

A：這是一個(gè)好問(wèn)題，我們其實(shí)也面臨過(guò)這個(gè)問(wèn)題。我們的方法就是首先要和大家宣導(dǎo)這個(gè)理念，讓大家在認(rèn)知上都接受鏡像化運(yùn)維能帶來(lái)的優(yōu)勢(shì)，長(zhǎng)遠(yuǎn)發(fā)展的好處。雖然很難有直接立竿見(jiàn)影的收益，長(zhǎng)遠(yuǎn)來(lái)看一定能提高運(yùn)維效率，降低資源使用的成本。實(shí)際上從這兩年來(lái)看，我們確實(shí)降低了不少運(yùn)維成本。

Q：你好，我想問(wèn)一下容器里面的那些持久化是怎么處理的？

A：容器我們持久化現(xiàn)在大體分兩類(lèi)數(shù)據(jù)，一個(gè)是日志，一種是應(yīng)用自己會(huì)寫(xiě)一些數(shù)據(jù)，像搜索業(yè)務(wù)。要么就是放在本地盤(pán)，放在本地的話(huà)做遷移的時(shí)候要自己處理數(shù)據(jù)的遷移，每個(gè)不同的業(yè)務(wù)處理的都不太一樣。還有一種方式是用遠(yuǎn)程，數(shù)據(jù)遠(yuǎn)程化。我們有分布式存儲(chǔ)系統(tǒng)“盤(pán)古”，通過(guò)容器創(chuàng)建的時(shí)候在遠(yuǎn)程存儲(chǔ)集群建一塊遠(yuǎn)程盤(pán)，我們現(xiàn)在用的是塊設(shè)備，然后掛載到容器里面，容器用完或者是遷移的時(shí)候，數(shù)據(jù)是在遠(yuǎn)端的，可以隨意遷移到另一個(gè)地方，再把這個(gè)數(shù)據(jù)盤(pán)掛載回來(lái)。

搜索也可以放遠(yuǎn)端，對(duì)于阿里各種搜索場(chǎng)景，我理解如果replica數(shù)多的話(huà)，用遠(yuǎn)端存儲(chǔ)是比較經(jīng)濟(jì)劃算的，如果replica數(shù)就1行，或2行，而且遠(yuǎn)端性能又滿(mǎn)足不了部分場(chǎng)景的需求，短時(shí)間內(nèi)就不如本地多塊盤(pán)來(lái)進(jìn)行混部。總體趨勢(shì)來(lái)說(shuō)，如果沒(méi)有性能要求的話(huà)，都放遠(yuǎn)端是趨勢(shì)。

Q：哪種方式會(huì)更多一些？

A：宿主機(jī)直接到容器里面，相對(duì)來(lái)說(shuō)***的場(chǎng)景是在數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)現(xiàn)在大部分是在本地，但是有一部分是放在遠(yuǎn)端的，正在演進(jìn)的過(guò)程中，還沒(méi)有***完成存儲(chǔ)計(jì)算的分離。后面有一天可能就完全沒(méi)有本地?cái)?shù)據(jù)了。

Q：這是云框架，一聽(tīng)到云這個(gè)架構(gòu)就感覺(jué)很大，是一個(gè)什么海量運(yùn)維，海量數(shù)據(jù)，對(duì)于中小型公司規(guī)模可能沒(méi)那么大，對(duì)于要想用這套框架，實(shí)施的成本是多少，用戶(hù)量在多少以下適合或者不適合？

A：很難有明確的臨界點(diǎn)，說(shuō)什么時(shí)候該用云化架構(gòu)了。從中小型公司來(lái)說(shuō)可以從***天就往這個(gè)方向，或者是朝這個(gè)模式去實(shí)現(xiàn)。比如說(shuō)搭一個(gè)很小的資源池，通過(guò)彈性混合云的方式，在云上去擴(kuò)容，這也是一種很好的方式。如果***天完全不考慮這些事情，怎么方便怎么搭建，也不考慮這些單點(diǎn)，容災(zāi)這些彈性的事情，后面改造起來(lái)可能就會(huì)比較痛苦。

Q：這個(gè)部署的成本，兩個(gè)人或者三個(gè)人的研發(fā)團(tuán)隊(duì)，用你這個(gè)東西周期有多長(zhǎng)時(shí)間呢？它的難易度，因?yàn)橐斫庹麄€(gè)框架，你要部署這個(gè)東西要理解這個(gè)東西，我覺(jué)得學(xué)習(xí)的曲線(xiàn)還有部署的難度到底是什么樣的？

A：后面這套系統(tǒng)在做 Sigma 敏捷版就是解決中小企業(yè)的問(wèn)題，兩三個(gè)開(kāi)發(fā)者不可能開(kāi)發(fā)出一套像現(xiàn)在這個(gè)規(guī)模的完整云化架構(gòu)，***的是用云上支持這些場(chǎng)景的產(chǎn)品。云產(chǎn)品本身經(jīng)過(guò)很多用戶(hù)的考驗(yàn)，有這么多云上運(yùn)作的一些經(jīng)驗(yàn)，一些技術(shù)上的沉淀，比自己開(kāi)發(fā)要靠譜得多。

Q：我想問(wèn)一下 PouchContainer 這個(gè)容器跟底層還會(huì)去封裝 Docker 之類(lèi)的東西，我***次接觸這個(gè)，另外鏡像庫(kù)的話(huà)是能夠跟 Docker 兼容嗎？

A：首先鏡像庫(kù)跟 Docker 是完全兼容的，Docker 分了很多層，底層的 runV 和 containerd 都貢獻(xiàn)到了社區(qū)，是開(kāi)源的，我們?cè)?runV 和 containerd 的基礎(chǔ)上做了增強(qiáng)。總體來(lái)說(shuō)是兼容兩個(gè)社區(qū)的兩種主流的技術(shù)路線(xiàn)，兩種集群管理系統(tǒng)，Kubernetes 和 Docker 公司 Swarm，這種兩種路徑都支持。