阿里如何做到在線業(yè)務(wù)百分百容器化-創(chuàng)新互聯(lián)

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

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

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

首先我們了解一下在線業(yè)務(wù)是什么？比如說大家在淘寶、閑魚上買東西，或利用支付寶支付一些費(fèi)用，而這些業(yè)務(wù)都需要提供實(shí)時服務(wù)。諸如此類的業(yè)務(wù)在阿里中十分廣泛。其中還包括像視頻（優(yōu)酷）、搜索、阿里專有云也都具備容器能力。

PouchContainer 簡介

首先為大家介紹一些 PouchContainer 的歷史。阿里從 2011 年開始打造容器技術(shù)，但是這個容器技術(shù)并沒有像后來的 Docker 那么流行。主要是什么原因呢？主要是我們服務(wù)于內(nèi)部，只是打造一個容器環(huán)境，提高集團(tuán)資源利用率，但是并沒有抽象出來現(xiàn)在社區(qū)的鏡像技術(shù)。

大家可以認(rèn)為鏡像技術(shù)是容器技術(shù)爆發(fā)的關(guān)鍵點(diǎn)之一，因?yàn)樗o我們的業(yè)務(wù)帶來了持續(xù)交付能力，可以讓我們的業(yè)務(wù)、應(yīng)用做到增量增發(fā)。2011 年，阿里是基于 LXC 的 CGroup 以及 Namespace 技術(shù)來實(shí)現(xiàn)。那時我們已經(jīng)具備做容器的技術(shù)，當(dāng)時采用 LXC 技術(shù)，并很快將當(dāng)時的容器技術(shù)推到線上運(yùn)行。

2015 年，我們發(fā)現(xiàn)外部的 Docker 發(fā)展越來越火，于是我們將 Docker 的鏡像技術(shù)推到集團(tuán)內(nèi)部。將 LXC 與 Docker 兩者集成，再加上必要的技術(shù)演進(jìn)，就形成了現(xiàn)在的 PouchContainer。2017 年的“雙十一”，PouchContainer 宣布開源?，F(xiàn)在包括阿里內(nèi)部 PouchContainer 任何一個特性與任何一行代碼的增刪改查，大家都可以在 GitHub 上看到。

說一下阿里容器技術(shù)在演進(jìn)過程中考慮了哪些內(nèi)容，這可能和社區(qū)當(dāng)中的容器技術(shù)又不一樣。比如說 Docker，它倡導(dǎo)的理念是 one process one container（在容器中永遠(yuǎn)只運(yùn)行一個應(yīng)用），但在企業(yè)里面的應(yīng)用架構(gòu)是這樣嗎？可能很多都不是。有很多業(yè)務(wù)在開發(fā)過程中就是為了依賴于一些其他的系統(tǒng)應(yīng)用。

比如說我們有很多應(yīng)用很難做到和底層基礎(chǔ)設(shè)施的解綁，這些應(yīng)用會使用底層的一些 systemd 和 crond 等去交付，它的日志當(dāng)中可能天生就要去和 syslog 去做交付。甚至為了運(yùn)維人員的便利，我們需要在這個運(yùn)行環(huán)境當(dāng)中自行支持一個 SSHD。而 Docker 的理念并不是特別合適這樣的需求，這就需要容器技術(shù)來滿足。

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

但如果說一個基礎(chǔ)設(shè)施技術(shù)，在提供業(yè)務(wù)方服務(wù)時，對業(yè)務(wù)方有諸多要求，那這樣推廣往往會面對很多阻力。那我們?yōu)槭裁匆鲞@樣？我們?yōu)槭裁匆?PouchContainer （富容器），就是因?yàn)槲覀儾荒軐﹂_發(fā)和運(yùn)維造成任何的侵入性，不能去侵入他們的流程，我們必須提供一個對他們完全透明的技術(shù)，這樣就能在很短的時間內(nèi)迅速容器化所有的業(yè)務(wù)。這也是我們存在一個比較大的價值。

PouchContainer 架構(gòu)

這是一張 PouchContainer 的知識架構(gòu)圖：

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

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

PouchContainer  技術(shù)特性

富容器

從功能角度來講，PouchContainer 幫大家解決了現(xiàn)實(shí)場景中的什么問題？第一點(diǎn)，富容器將業(yè)務(wù)運(yùn)維域所看到的所有內(nèi)容都放到一個容器中。為什么要這樣做？當(dāng)我們提供一個容器技術(shù)時，我們不希望對應(yīng)用開發(fā)和運(yùn)維有任何影響，否則在企業(yè)中就會很難推廣。在運(yùn)維團(tuán)隊(duì)方面，運(yùn)維團(tuán)隊(duì)都會維穩(wěn)，他們往往不希望你入太多的變量。比如說，運(yùn)維同學(xué)可能會非常依賴于自己使用的那套工具，一旦這套工具在我們新技術(shù)面前變得不可用了，在面對新技術(shù)時他們會說“不”。

富容器技術(shù)，就是將運(yùn)維需要的所有內(nèi)容打包到這個鏡像中去。在應(yīng)用運(yùn)行過程中，這些運(yùn)維組件繼續(xù)發(fā)揮作用。只有這樣之后，富容器技術(shù)才能更好地適配應(yīng)用?？梢哉f，富容器技術(shù)是阿里巴巴集團(tuán)內(nèi)部真正快速做到百分之一百容器化的一個重要前提。如果說，各位同學(xué)覺得在企業(yè)中推動容器技術(shù)比較慢或者阻礙較大，不妨試用一下富容器技術(shù)將流程化簡。

從技術(shù)架構(gòu)角度來看，我們的富容器到底有哪些優(yōu)勢？第一，我們?nèi)萜鲀?nèi)部會有一個  systemd，很像虛擬機(jī)。這個 systemd 起到什么作用呢？systemd 主要是來做好容器內(nèi)部的更細(xì)致化管理。比如說僵尸進(jìn)程，利用它就很好管理，而 Docker 可能并不能做到這方面的一些工作。同時他也有能力去管控容器內(nèi)部更多的一些系統(tǒng)服務(wù)，包括像 syslogd、SSHD 等。這樣就可以保證運(yùn)維，而不需要對這個系統(tǒng)做任何修改。

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

富容器的價值分為兩點(diǎn)：

• 富容器完全兼容容器鏡像。兼容容器鏡像后，對大家的業(yè)務(wù)交付效率沒有任何影響；

• 富容器兼容了我們的運(yùn)維體系，充分保障運(yùn)維體系原有和現(xiàn)有的運(yùn)維能力，對現(xiàn)有的運(yùn)維體系沒有任何侵入性。

增強(qiáng)的隔離性

接下來與大家分享關(guān)于 PouchContainer 的隔離性。隔離性方面的問題我會從切身體驗(yàn)的方向出發(fā)：

第一個，資源可見性隔離。如果你是一個深度容器使用者，應(yīng)該會在生產(chǎn)環(huán)境中使用容器。如果你用的是 JAVA 應(yīng)用感觸應(yīng)該更深一些。如果在一臺擁有 10G 內(nèi)存的宿主機(jī)上創(chuàng)建容器，給它設(shè)置 1 個 G 的內(nèi)存，你在容器中的 /proc/meminfo 會顯示宿主機(jī)的 10G 內(nèi)存，而并不是你設(shè)定的 1 個 G。這樣的顯示會導(dǎo)致什么影響呢？

在很多情況下，應(yīng)用啟動往往并不是只要把二進(jìn)制文件啟動起來就行。比如，JAVA 應(yīng)用，它往往會去判斷宿主機(jī)的 /proc/meminfo 中的一些資源，再去動態(tài)分配 JVM 堆棧大小。如果容器中的 JAVA 應(yīng)用通過這種方式去啟動，那么你設(shè)置的任何資源限制都無濟(jì)于事。這樣也有可能導(dǎo)致 JAVA 應(yīng)用的 OOM 異常。這種情況下，我們通過 LXCFS 技術(shù)來通用化解決這個問題，對于我們的應(yīng)用，開發(fā)和運(yùn)維都不需要做任何改動。

其實(shí)它做的事情也比較簡單，只要我們對一個容器做一個資源限制，在 CGroup filesystem 當(dāng)中，就會有這樣一個數(shù)值，這是 memory.limit_in_bytes 下面的一個文件。這樣的一個虛擬文件，其實(shí) LXCFS 可以把它動態(tài)讀出，然后再去生成一個虛擬文件，再將這個文件掛載到真實(shí)的容器中的相應(yīng)位置。在容器啟動過程中，他得到的值就是它真正限制的值。

現(xiàn)在資源可見性的隔離就解決了，而 JAVA 的應(yīng)用也不會有 OOM 異常。那么問題來了，我們?yōu)槭裁匆鲞@樣一個東西？電商應(yīng)用很多都是 JAVA 應(yīng)用，DiskQuota 主要用來做容器的磁盤限額。

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

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

第二，inode（索引節(jié)點(diǎn)）。也就是我在我這個容器里面拼命創(chuàng)建小文件，我沒有占磁盤空間，在我拼命創(chuàng)建小文件時，另外一個容器就完全無法運(yùn)行（一些基本命令無法執(zhí)行)，這都是隔離方面的一些問題。在 PouchContainer 中不少應(yīng)用在運(yùn)行時也會遇到這種情況。一個應(yīng)用程序?qū)懖缓?，它就有可能通過一個循環(huán)來寫文件，導(dǎo)致磁盤寫爆。那我們怎么來解決這個問題呢？我們通過 DiskQuota 來做這件事情。

容器公有服務(wù)就說到這里。我們接著說增強(qiáng)隔離性的第二個問題。

第二個，隔離特性是 hypervisor-based container。部分同學(xué)有這樣的疑問， PouchContainer 是否可以支持一些老內(nèi)核？在這方面我們也做了一些工作，我們可以在 PouchContainer 創(chuàng)建的 runV 虛擬機(jī)中運(yùn)行一個老內(nèi)核。這么做會有什么效果呢？

如此我們存量的業(yè)務(wù)全部可以擁抱 Kubernetes 。企業(yè)當(dāng)中一定會有很多基于 2.6.32  內(nèi)核的應(yīng)用。這些應(yīng)用至今都跟 Docker 和 Kubernetes 一點(diǎn)關(guān)系都沒有，為什么會出現(xiàn)這種現(xiàn)象？

因?yàn)槟切┘夹g(shù)都對內(nèi)核有要求，即新技術(shù)對內(nèi)核有要求，而依賴于低版本內(nèi)核的應(yīng)用完全無法使用新技術(shù)。對于企業(yè)而言，到底想不想上 Kubernetes 呢？肯定是想上的。又該如何上呢？有沒有一種能力能夠把我們 Host OS 全都升級，升級到 3.10 或者 3.19、4.4、4.9 這樣的一些內(nèi)核。但為什么現(xiàn)在還沒有人去嘗試呢？

因?yàn)檫\(yùn)維團(tuán)隊(duì)無法承擔(dān)升級后對上層業(yè)務(wù)造成的一些影響。但是有一種方式，如果說我們這種 runV 虛擬機(jī)中運(yùn)行的是老內(nèi)核，而我們在 host 上可以運(yùn)行升級后的內(nèi)核，那我們完全有能力把數(shù)據(jù)中心物理機(jī)的內(nèi)核完全升級。

因?yàn)樗拗鳈C(jī)內(nèi)核跟我們的業(yè)務(wù)已經(jīng)不耦合了，這樣就可以完全升級。但是我們的 runV 虛擬機(jī)中運(yùn)行的還是老內(nèi)核，應(yīng)用還在 runV 虛擬機(jī)中。這樣就完全可以讓整個數(shù)據(jù)中心的基礎(chǔ)技術(shù)架構(gòu)升級。在傳統(tǒng)行業(yè)中我相信這樣的操作很有殺傷力。因?yàn)榇蠹叶荚诳紤]怎么解決這個存量異構(gòu)操作系統(tǒng)的問題。

如果你的內(nèi)核無法升級，那你就無法去迎接一些新的技術(shù)，數(shù)字化轉(zhuǎn)型進(jìn)程也會比較慢。

P2P 鏡像分發(fā)

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

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

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

• 分發(fā)的效率；

• 分發(fā)的流控；

• 分發(fā)的安全。

容器的原地升級功能

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

那這些有狀態(tài)的業(yè)務(wù)我們應(yīng)該怎么去升級，怎么去更新呢？在更新的過程當(dāng)中，能不能把之前的那些狀態(tài)給繼A承下來呢？這個是我們需要考慮的。在升級過程中 ，我們做了容器的 Upgrade 這樣一個操作。其實(shí)據(jù)我所知，國內(nèi)的互聯(lián)網(wǎng)公司中應(yīng)用的架構(gòu)走的比較靠前，但是大部分公司仍然利用一些有狀態(tài)容器，其實(shí)他們各自都實(shí)現(xiàn)了這樣一個功能。

究竟應(yīng)該如何實(shí)現(xiàn)容器的原地升級呢？其實(shí)很簡單，所有有狀態(tài)的東西保留不變，升級要升級的東西即可。

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

原生支持 Kubernetes

這里介紹下 PouchContainer 原生支持 Kubernetes。說到原生支持 Kubernetes，我們主要是實(shí)現(xiàn)了 CRI 容器運(yùn)行時接口。大家今天聽到了很多遍 CRI（Container Runtime Interface）它主要是用來解耦 Kubernetes 對于底層 container Runtime 的依賴。那我們?yōu)槭裁匆?shí)踐 CRI 呢？

原因很簡單：因?yàn)槲覀円?PouchContainer 這么多生產(chǎn)級別的功能，全都透傳到 Kubernetes 體系當(dāng)中去。大家知道 Kubernetes 支持 LXCFS，那它支持我們這個升級嗎？肯定是不支持的。既然不被 Kubernetes 支持，那 Kubernetes 可以直接在阿里巴巴內(nèi)部落地嗎？往往很難，我們必須要把 Runtime 的這些增強(qiáng)透傳到我們 Kubernetes 當(dāng)中去，之后才能讓容器技術(shù)更好的落地。

結(jié)語

以上就是阿里巴巴在容器領(lǐng)域的實(shí)踐，歡迎后續(xù)大家一起交流

原文鏈接：https://mp.weixin.qq.com/s/cBJT1C3YzXCsXwORQs1ovw

本文標(biāo)題：阿里如何做到在線業(yè)務(wù)百分百容器化-創(chuàng)新互聯(lián)
本文URL：http://muchs.cn/article24/dsgice.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站設(shè)計(jì)、微信公眾號、網(wǎng)站內(nèi)鏈、用戶體驗(yàn)、網(wǎng)站改版、ChatGPT

廣告

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