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

10余年的坡頭網站建設經驗，針對設計、前端、開發、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。網絡營銷推廣的優勢是能夠根據用戶設備顯示端的尺寸不同，自動調整坡頭建站的顯示方式，使網站能夠適用不同顯示終端，在瀏覽器中調整網站的寬度，無論在任何一種瀏覽器上瀏覽網站，都能展現優雅布局與設計，從而大程度地提升瀏覽體驗。創新互聯從事“坡頭網站設計”,“坡頭網站推廣”以來，每個客戶項目都認真落實執行。

如今，容器和 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 架構

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

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

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

PouchContainer  技術特性

富容器

從功能角度來講，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 虛擬機中。這樣就完全可以讓整個數據中心的基礎技術架構升級。在傳統行業中我相信這樣的操作很有殺傷力。因為大家都在考慮怎么解決這個存量異構操作系統的問題。

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

P2P 鏡像分發

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

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

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

• 分發的效率；

• 分發的流控；

• 分發的安全。

容器的原地升級功能

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

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

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

那究竟什么東西是要升級的呢？從技術的角度來講，我們一般認為鏡像是需要升級的。在運行的過程中我們把一個容器真正停掉，然后在組建這個文件系統過程中把原來老的鏡像給撤掉，把新的鏡像填進來；然后再去啟動原有的 command，這樣能保證完全做到原地升級。目前，我們正把這一功能集成進我們自身的調度系統中，包括我們內部的 Sigma 也是依賴于這樣的一個功能來做業務升級的。

原生支持 Kubernetes

這里介紹下 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

本文標題：阿里如何做到在線業務百分百容器化-創新互聯
本文URL：http://m.newbst.com/article24/dsgice.html

成都網站建設公司_創新互聯，為您提供品牌網站設計、微信公眾號、網站內鏈、用戶體驗、網站改版、ChatGPT

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯