阿里如何做到線上業務百分百容器化

本文將介紹如何打造百萬級的容器技術。眾所周知，阿里巴巴在 “雙11” 活動之前上線了數以百萬計的容器，面對如此大的規模，阿里巴巴的容器技術到底有哪些功能特性來幫助它快速落地？我將從場景痛點與解決方案的角度同大家分享。

如今，容器和 Kubernetes 的概念炒得很火，但是我相信，還有部分企業在內部並沒有把自己的業務進行容器化，那根據我們們大會現場的反饋結果也是如此。這就說明在容器化的過程中，不管技術如何落地，我們對環境有一些什麼樣的要求，總有一些需要解決的問題。接下來，讓我們一起來看一下，阿里是如何做到線上業務百分之百容器化的。

首先我們瞭解一下線上業務是什麼？比如說大家在淘寶、閒魚上買東西，或利用支付寶支付一些費用，而這些業務都需要提供實時服務。諸如此類的業務在阿里中十分廣泛。其中還包括像視訊（優酷）、搜尋、阿里專有云也都具備容器能力。

PouchContainer 簡介

首先為大家介紹一些 PouchContainer 的歷史。阿里從 2011 年開始打造容器技術，但是這個容器技術並沒有像後來的 Docker 那麼流行。主要是什麼原因呢？主要是我們服務於內部，只是打造一個容器環境，提高集團資源利用率，但是並沒有抽象出來現在社群的映象技術。

大家可以認為映象技術是容器技術爆發的關鍵點之一，因為它給我們的業務帶來了持續交付能力，可以讓我們的業務、應用做到增量增發。2011 年，阿里是基於 LXC 的 CGroup 以及 Namespace 技術來實現。那時我們已經具備做容器的技術，當時採用 LXC 技術，並很快將當時的容器技術推到線上執行。

2015 年，我們發現外部的 Docker 發展越來越火，於是我們將 Docker 的映象技術推到集團內部。將 LXC 與 Docker 兩者整合，再加上必要的技術演進，就形成了現在的 PouchContainer。2017 年的“雙十一”，PouchContainer 宣佈開源。現在包括阿里內部 PouchContainer 任何一個特性與任何一行程式碼的增刪改查，大家都可以在 GitHub 上看到。

說一下阿里容器技術在演進過程中考慮了哪些內容，這可能和社群當中的容器技術又不一樣。比如說 Docker，它倡導的理念是 one process one container（在容器中永遠只執行一個應用），但在企業裡面的應用架構是這樣嗎？可能很多都不是。有很多業務在開發過程中就是為了依賴於一些其他的系統應用。

比如說我們有很多應用很難做到和底層基礎設施的解綁，這些應用會使用底層的一些 systemd 和 crond 等去交付，它的日誌當中可能天生就要去和 syslog 去做交付。甚至為了運維人員的便利，我們需要在這個執行環境當中自行支援一個 SSHD。而 Docker 的理念並不是特別合適這樣的需求，這就需要容器技術來滿足。

我們必須先滿足開發者的要求，再滿足運維人員要求，只有這樣我們提供的新技術才會對現有的技術架構沒有侵入性。一旦新技術沒有侵入性，那它的推廣往往會比較透明且速度較快，企業內推行阻力也會比較小。

但如果說一個基礎設施技術，在提供業務方服務時，對業務方有諸多要求，那這樣推廣往往會面對很多阻力。那我們為什麼要做這樣？我們為什麼要做 PouchContainer （富容器），就是因為我們不能對開發和運維造成任何的侵入性，不能去侵入他們的流程，我們必須提供一個對他們完全透明的技術，這樣就能在很短的時間內迅速容器化所有的業務。這也是我們存在一個比較大的價值。

這是一張 PouchContainer 的知識架構圖：

現在我就此圖為大家進行解讀：如果我們橫向在中間“切一刀”，就會發現部署編排裡的一些概念，比如說 Kubernetes，比如說我們的 CRI、Pod 都是編排的一些概念，我們的 PouchContainer 可以非常方便地支援 Kubernetes，而且我們增強了 Kubernetes 體驗，在本末我將會跟大家展開來說。下一層是 container API。對於 container API，大家可以看到一個 container manager 的管控域，包括網路、儲存。上下是兩層 ，分別是編排和容器域。

如果此圖縱向“切四刀”，大家會比較好理解，左邊是我們的排程域和 Kubernetes；第二層是我們的引擎；第三層是我們的 Runtime 層，包括我們的 runc、runlxc 還有 katacontainer。最右邊是容器的執行載體：Pod ，container 或者說 katacontainer。

從功能角度來講，PouchContainer 幫大家解決了現實場景中的什麼問題？第一點，富容器將業務運維域所看到的所有內容都放到一個容器中。為什麼要這樣做？當我們提供一個容器技術時，我們不希望對應用開發和運維有任何影響，否則在企業中就會很難推廣。在運維團隊方面，運維團隊都會維穩，他們往往不希望你入太多的變數。比如說，運維同學可能會非常依賴於自己使用的那套工具，一旦這套工具在我們新技術面前變得不可用了，在面對新技術時他們會說“不”。

富容器技術，就是將運維需要的所有內容打包到這個映象中去。在應用執行過程中，這些運維元件繼續發揮作用。只有這樣之後，富容器技術才能更好地適配應用。可以說，富容器技術是阿里巴巴集團內部真正快速做到百分之一百容器化的一個重要前提。如果說，各位同學覺得在企業中推動容器技術比較慢或者阻礙較大，不妨試用一下富容器技術將流程化簡。

從技術架構角度來看，我們的富容器到底有哪些優勢？第一，我們容器內部會有一個  systemd，很像虛擬機器。這個 systemd 起到什麼作用呢？systemd 主要是來做好容器內部的更細緻化管理。比如說殭屍程式，利用它就很好管理，而 Docker 可能並不能做到這方面的一些工作。同時他也有能力去管控容器內部更多的一些系統服務，包括像 syslogd、SSHD 等。這樣就可以保證運維，而不需要對這個系統做任何修改。

第二，富容器對容器的管控層做了更多細緻化要求，比如說我們的 prestart hook、post stop hook。為了滿足運維人員的一些需求，我們在做一些初始化管控時，會在它啟動前要做一些前置工作，或者說在停止後做一些後置工作。

富容器的價值分為兩點：

• 富容器完全相容容器映象。相容容器映象後，對大家的業務交付效率沒有任何影響；

• 富容器相容了我們的運維體系，充分保障運維體系原有和現有的運維能力，對現有的運維體系沒有任何侵入性。

接下來與大家分享關於 PouchContainer 的隔離性。隔離性方面的問題我會從切身體驗的方向出發：

第一個，資源可見性隔離。如果你是一個深度容器使用者，應該會在生產環境中使用容器。如果你用的是 JAVA 應用感觸應該更深一些。如果在一臺擁有 10G 記憶體的宿主機上建立容器，給它設定 1 個 G 的記憶體，你在容器中的 /proc/meminfo 會顯示宿主機的 10G 記憶體，而並不是你設定的 1 個 G。這樣的顯示會導致什麼影響呢？

在很多情況下，應用啟動往往並不是只要把二進位制檔案啟動起來就行。比如，JAVA 應用，它往往會去判斷宿主機的 /proc/meminfo 中的一些資源，再去動態分配 JVM 堆疊大小。如果容器中的 JAVA 應用通過這種方式去啟動，那麼你設定的任何資源限制都無濟於事。這樣也有可能導致 JAVA 應用的 OOM 異常。這種情況下，我們通過 LXCFS 技術來通用化解決這個問題，對於我們的應用，開發和運維都不需要做任何改動。

其實它做的事情也比較簡單，只要我們對一個容器做一個資源限制，在 CGroup filesystem 當中，就會有這樣一個數值，這是 memory.limit_in_bytes 下面的一個檔案。這樣的一個虛擬檔案，其實 LXCFS 可以把它動態讀出，然後再去生成一個虛擬檔案，再將這個檔案掛載到真實的容器中的相應位置。在容器啟動過程中，他得到的值就是它真正限制的值。

現在資源可見性的隔離就解決了，而 JAVA 的應用也不會有 OOM 異常。那麼問題來了，我們為什麼要做這樣一個東西？電商應用很多都是 JAVA 應用，DiskQuota 主要用來做容器的磁碟限額。

在容器公有服務中，我想簡單給大家介紹幾個問題：

第一，如果我們不是通過 block 來做管理容器儲存，而是通過一些純粹的檔案系統，檔案系統視角可以隔離但是無法做到磁碟 quota。也就是說兩個容器如果共用一個檔案系統，雖然我看不見你，但是我可以用我的檔案系統磁碟導致你無法使用。這也是一種互相干擾的情況。

第二，inode（索引節點）。也就是我在我這個容器裡面拼命建立小檔案，我沒有佔磁碟空間，在我拼命建立小檔案時，另外一個容器就完全無法執行（一些基本命令無法執行)，這都是隔離方面的一些問題。在 PouchContainer 中不少應用在執行時也會遇到這種情況。一個應用程式寫不好，它就有可能通過一個迴圈來寫檔案，導致磁碟寫爆。那我們怎麼來解決這個問題呢？我們通過 DiskQuota 來做這件事情。

容器公有服務就說到這裡。我們接著說增強隔離性的第二個問題。

第二個，隔離特性是 hypervisor-based container。部分同學有這樣的疑問， PouchContainer 是否可以支援一些老核心？在這方面我們也做了一些工作，我們可以在 PouchContainer 建立的 runV 虛擬機器中執行一個老核心。這麼做會有什麼效果呢？

如此我們存量的業務全部可以擁抱 Kubernetes 。企業當中一定會有很多基於 2.6.32  核心的應用。這些應用至今都跟 Docker 和 Kubernetes 一點關係都沒有，為什麼會出現這種現象？

因為那些技術都對核心有要求，即新技術對核心有要求，而依賴於低版本核心的應用完全無法使用新技術。對於企業而言，到底想不想上 Kubernetes 呢？肯定是想上的。又該如何上呢？有沒有一種能力能夠把我們 Host OS 全都升級，升級到 3.10 或者 3.19、4.4、4.9 這樣的一些核心。但為什麼現在還沒有人去嘗試呢？

因為運維團隊無法承擔升級後對上層業務造成的一些影響。但是有一種方式，如果說我們這種 runV 虛擬機器中執行的是老核心，而我們在 host 上可以執行升級後的核心，那我們完全有能力把資料中心物理機的核心完全升級。

因為宿主機核心跟我們的業務已經不耦合了，這樣就可以完全升級。但是我們的 runV 虛擬機器中執行的還是老核心，應用還在 runV 虛擬機器中。這樣就完全可以讓整個資料中心的基礎技術架構升級。在傳統行業中我相信這樣的操作很有殺傷力。因為大家都在考慮怎麼解決這個存量異構作業系統的問題。

如果你的核心無法升級，那你就無法去迎接一些新的技術，數字化轉型程式也會比較慢。

這個是阿里巴巴的映象分發技術，我們認為映象分發是一個非常大的專題。你知道容器映象的平均大小是多少嗎？有沒有哪個企業的平均映象大小都小於 500M？實際這種情況很少，這就說明映象很大。那映象很大時會出現什麼樣的問題？比如說在阿里的一些大促，例如雙十一，我們需要把映象大量的分發到各個機器上，其中分發效率是我們需要考慮的一個關鍵。

如果不考慮這個問題，你會發現 1000 臺機器上都在向一個 registry 傳送下載映象請求，那這個 registry 可能就會出現問題。我們從問題入手，需要做的是 Dragonfly(P2P的智慧檔案分發系統),它有這方面的一些特性，主要是來解決一些分發瓶頸。現在開源的 Dragonfly 也有我們的一些使用者，包括像 Lazada 的公司。

它主要的一些功能特性主要是盯住了雲原生應用的分發方面，在分發方面有三個維度：

• 分發的效率；

• 分發的流控；

• 分發的安全。

這是針對有狀態應用做的一個功能，PouchContainer 在容器引擎層面提供了一個  Upgrade  介面，用於實現容器的原地升級功能。在 CNCF 倡導的理念中很多 container 都是 stateless 也就是無狀態的。但是企業中真的有那麼多無狀態的應用嗎？可能未必，現實情況是有相當一部分還是有狀態的。

那這些有狀態的業務我們應該怎麼去升級，怎麼去更新呢？在更新的過程當中，能不能把之前的那些狀態給繼A承下來呢？這個是我們需要考慮的。在升級過程中 ，我們做了容器的 Upgrade 這樣一個操作。其實據我所知，國內的網際網路公司中應用的架構走的比較靠前，但是大部分公司仍然利用一些有狀態容器，其實他們各自都實現了這樣一個功能。

究竟應該如何實現容器的原地升級呢？其實很簡單，所有有狀態的東西保留不變，升級要升級的東西即可。

那究竟什麼東西是要升級的呢？從技術的角度來講，我們一般認為映象是需要升級的。在執行的過程中我們把一個容器真正停掉，然後在組建這個檔案系統過程中把原來老的映象給撤掉，把新的映象填進來；然後再去啟動原有的 command，這樣能保證完全做到原地升級。目前，我們正把這一功能整合進我們自身的排程系統中，包括我們內部的 Sigma 也是依賴於這樣的一個功能來做業務升級的。

這裡介紹下 PouchContainer 原生支援 Kubernetes。說到原生支援 Kubernetes，我們主要是實現了 CRI 容器執行時介面。大家今天聽到了很多遍 CRI（Container Runtime Interface）它主要是用來解耦 Kubernetes 對於底層 container Runtime 的依賴。那我們為什麼要去實踐 CRI 呢？

原因很簡單：因為我們要把 PouchContainer 這麼多生產級別的功能，全都透傳到 Kubernetes 體系當中去。大家知道 Kubernetes 支援 LXCFS，那它支援我們這個升級嗎？肯定是不支援的。既然不被 Kubernetes 支援，那 Kubernetes 可以直接在阿里巴巴內部落地嗎？往往很難，我們必須要把 Runtime 的這些增強透傳到我們 Kubernetes 當中去，之後才能讓容器技術更好的落地。

以上就是阿里巴巴在容器領域的實踐，歡迎後續大家一起交流

原文連結：https://mp.weixin.qq.com/s/cBJT1C3YzXCsXwORQs1ovw

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2220967/，如需轉載，請註明出處，否則將追究法律責任。