6月29日，DevOps國際峰會在北京盛大開幕。騰訊數(shù)據(jù)平臺部高級工程師羅韓梅做了主題為“騰訊基于Kubernetes的企業(yè)級容器云平臺GaiaStack”的演講。

以下為演講內(nèi)容：

GaiaStack介紹

GaiaStack是騰訊基于kubernetes打造的容器私有云平臺。這里有幾個關(guān)鍵詞：

1）騰訊：GaiaStack可服務(wù)騰訊內(nèi)部所有BG的業(yè)務(wù)；

2）kubernetes：GaiaStack的技術(shù)實(shí)現(xiàn)主要是依托于kubernetes和容器；

3）私有云：GaiaStack通過騰訊云向外部企業(yè)輸出解決方案，并成功在金融、游戲、政務(wù)、互聯(lián)網(wǎng)等各行業(yè)落地。

GaiaStack的產(chǎn)品功能主要分為下面兩個部分，分別是集群管理員的集群管理功能，以及集群用戶的應(yīng)用全生命周期管理的功能。

集群管理中包括對集群的部署、監(jiān)控、告警、日志以及規(guī)劃管理等。應(yīng)用全生命周期的管理是從開碼構(gòu)建開始，到交付中心、應(yīng)用的上線、以及后續(xù)對應(yīng)用的自動化運(yùn)維等各種操作。

從整體架構(gòu)看，GaiaStack基于kubernetes、ceph、docker、網(wǎng)絡(luò)等底層技術(shù)，完善了認(rèn)證鑒權(quán)，自動化運(yùn)維等方面，支持代碼構(gòu)建、鏡像倉庫、應(yīng)用管理、服務(wù)編排、負(fù)載均衡、自動運(yùn)營等應(yīng)用場景，并向用戶提供了訪問入口、webshell、日志檢索、配置管理、webportal、操作審計(jì)等用戶工具。

我們對GaiaStack的定位是一個Cluster Operation System，因此它需要承載各種各樣的應(yīng)用類型，即All on GaiaStack，比如開發(fā)應(yīng)用、測試應(yīng)用、微服務(wù)應(yīng)用、有狀態(tài)應(yīng)用、科學(xué)計(jì)算應(yīng)用、GPU應(yīng)用等等。要支持所有類型的應(yīng)用，僅僅將原生的kubernetes產(chǎn)品化是遠(yuǎn)遠(yuǎn)不夠的。

接下來進(jìn)入第二個部分，介紹一下GaiaStack上的應(yīng)用全生命周期的管理。

應(yīng)用生命周期以代碼構(gòu)建開始，可以關(guān)聯(lián)代碼倉庫、CI/CD、制作鏡像等。一個項(xiàng)目可以被自動或者手動構(gòu)建多次，也可以從頁面上看到每次構(gòu)建的詳細(xì)日志。

GaiaStack支持使用代碼倉庫中已有的Dockerfile，以及云Dockerfile，方便直接在線修改。同時，GaiaStack可以和任何基于kubernetes的devops產(chǎn)品做對接，方便適應(yīng)企業(yè)內(nèi)部已有的研發(fā)流程，還可以自定義流水線。

GaiaStack的兩個交付中心：鏡像倉庫和編排模板

鏡像倉庫中的鏡像可以分為個人鏡像、業(yè)務(wù)鏡像，還可以查看全部的公共鏡像，支持鏡像的導(dǎo)入以及安全掃描。

編排支持kubernetes編排和compose編排，鏡像和編排都有權(quán)限管理，都可以作為應(yīng)用創(chuàng)建的入口。編排中可見關(guān)系圖、YAML編碼和操作記錄。在最新的2.9版本，我們又新增了服務(wù)市場的交付中心，里面有各種高可用版本的基礎(chǔ)服務(wù)，比如redis，mysql，zk 等。

? ??

GaiaStack的應(yīng)用分為三個層次，即Stackappinstance。Stack、app、instance都支持創(chuàng)建、刪除操作。其中app還新增了停止、啟動和重啟、復(fù)制等操作，編排、應(yīng)用、實(shí)例列表都是多集群、多租戶視圖，所有視圖都支持查詢和過濾操作。

配置管理包括ConfigMap和Secret，主要還是kubernetes自身的機(jī)制，但是做了產(chǎn)品化，所以可以直接在界面上對配置做新建、編輯、刪除、關(guān)聯(lián)應(yīng)用等等操作。配置也是提供所有業(yè)務(wù)、所有集群的同一視圖，一個配置組下面的多個配置統(tǒng)一查看和管理。

應(yīng)用通過GaiaStack發(fā)布之后，對應(yīng)用的運(yùn)維還遠(yuǎn)遠(yuǎn)沒有結(jié)束，需要對應(yīng)用做持續(xù)的運(yùn)營操作。

常規(guī)操作主要是兩類：擴(kuò)縮容和升級

擴(kuò)縮容分為主動擴(kuò)縮容和自動擴(kuò)縮容，對于自動擴(kuò)縮容，因?yàn)閗ubernetes本身支持，這里不再贅述，主要講一下GaiaStack和kubernetes不同的機(jī)制。

GaiaStack對應(yīng)用的縮容可以支持定點(diǎn)裁撤，比如銀行的業(yè)務(wù)希望對沒有交易處理的實(shí)例做縮容，比如游戲的業(yè)務(wù)希望對沒有連接的實(shí)例做縮容，比如我們要裁撤掉集群中的某些計(jì)算節(jié)點(diǎn)等等。

而kubernetes的縮容，主要是實(shí)例數(shù)的減少，縮掉的是哪些實(shí)例由系統(tǒng)自動決定的。對于升級，GaiaStack除了支持kubernetes的滾動升級之外，還增加了對應(yīng)用灰度升級的支持。即選擇某一個或N個實(shí)例先升級到新版本，在充分的穩(wěn)定性或者功能性驗(yàn)證后，再考慮升級其他實(shí)例，該灰度的過程可以分為任意批次。有時為了驗(yàn)證多個版本，一個應(yīng)用內(nèi)也可以同時有多個版本并行存在，充分保證現(xiàn)網(wǎng)的服務(wù)質(zhì)量以及版本的可控性。

下面以現(xiàn)網(wǎng)上一個提供圖片識別的OCR服務(wù)應(yīng)用為例，查看其中一個實(shí)例的事件：

1）2018-02-06 11:46:38 V7版本開時候運(yùn)行；

2）2018-02-09 09:33:02 對該實(shí)例做灰度升級，從V7版本升級到V8版本；

3）2018-02-09 09:33:02 開始pull V8版本的image。

從這個事件流中可以發(fā)現(xiàn)有幾個點(diǎn)：

第一，GaiaStack記錄了每個實(shí)例的所有歷史事件，而不是新的pod開始后就看不到舊的pod，所以可以跟蹤從V1到V8的所有版本歷史；

第二，灰度升級是一種原地升級，不但提升了效率，還可以復(fù)用原來pod的現(xiàn)場，而沒有經(jīng)過調(diào)度器的環(huán)節(jié)，也消除了調(diào)度失敗導(dǎo)致升級失敗的風(fēng)險。

第三，每次升級可以靈活的選擇要升級的實(shí)例個數(shù)以及具體哪些(個)實(shí)例。

應(yīng)用提交到GaiaStack之后，絕不希望進(jìn)入到一個黑盒子，而是想對其做各種探測，GaiaStack為用戶提供了多種探測方式。操作記錄中記錄了對應(yīng)用的所有操作記錄，特別是當(dāng)操作失敗時，會有失敗原因的提示，也可以對用戶的操作進(jìn)行審計(jì)。

事件管理包括應(yīng)用以及實(shí)例的事件，并可以查看歷史的“所有”事件，避免因?yàn)閗ubernetes只保存一段時間事件導(dǎo)致在定位問題時丟失關(guān)鍵事件，但并不會增加etcd的壓力。用戶也可以直接通過webshell的方式進(jìn)入容器，并進(jìn)行各種操作。所有探測操作都是在認(rèn)證和鑒權(quán)的保護(hù)下進(jìn)行。

為了簡化應(yīng)用的使用門檻，GaiaStack默認(rèn)為每一個app提供了自動的應(yīng)用和實(shí)例的訪問入口，方便查看應(yīng)用頁面，如下圖中的TensorFlow作業(yè)。也可以將一個已有域名綁定在訪問入口。除了訪問入口，GaiaStack還提供了和主流負(fù)載均衡的自動對接。如在騰訊內(nèi)部實(shí)現(xiàn)了與tgw和l5的自動對接，在騰訊云和黑石環(huán)境上，也和對應(yīng)的負(fù)載均衡做了對接。

GaiaStack中的負(fù)載均衡實(shí)現(xiàn)有幾個特點(diǎn)：

1）負(fù)載均衡可以跨集群；

2）負(fù)載均衡可以跨app；

3）負(fù)載均衡可以對單個實(shí)例做操作，即可以對某一個或者多個實(shí)例做綁定、解綁以及再綁定等操作。

4）負(fù)載均衡的生命周期和應(yīng)用的生命周期獨(dú)立，即可以在創(chuàng)建應(yīng)用時綁定負(fù)載均衡，也可以在應(yīng)用運(yùn)行中綁定或解綁負(fù)載均衡。

GaiaStack的幾個關(guān)鍵技術(shù)：

全系統(tǒng)HA、熱升級

GaiaStack保證全平臺無單點(diǎn)，任何管理節(jié)點(diǎn)異常都不會導(dǎo)致平臺不可用。所有組件都支持熱升級，所謂的熱升級是指，GaiaStack自身做升級時，其上面運(yùn)行的業(yè)務(wù)可以完全不受影響，不但不會丟失pod，也不會對pod有重啟操作。

另外GaiaStack同時服務(wù)騰訊內(nèi)部和外部業(yè)務(wù)，新版本是騰訊內(nèi)部先升級試用穩(wěn)定后才發(fā)對外版本，以保證對外版本均是穩(wěn)定版本。GaiaStack的私有云版本還實(shí)現(xiàn)了一套產(chǎn)品化的自動安裝部署工具，提供了全部可視化的操作方式，降低了學(xué)習(xí)成本，并可以減少運(yùn)維人員的操作失誤。

全網(wǎng)絡(luò)模式支持

容器的網(wǎng)絡(luò)一直是kubernetes的一個重點(diǎn)和難點(diǎn)。GaiaStack在設(shè)計(jì)容器網(wǎng)絡(luò)時有幾個原則。第一是要具有普適性，方便GaiaStack適應(yīng)各種環(huán)境。比如Calico性能不錯，但是跨二層網(wǎng)絡(luò)需配置交換機(jī)BGP路由信息，對底層網(wǎng)絡(luò)有較大侵入性。第二是要兼顧性能，比如GaiaStack的overlay的實(shí)現(xiàn)，我們汲取了flannel/calico容器網(wǎng)絡(luò)開源項(xiàng)目的優(yōu)處，實(shí)現(xiàn)了基于IPIP和Host Gateway的Overlay網(wǎng)絡(luò)方案。同節(jié)點(diǎn)容器報(bào)文無橋接方式，利用主機(jī)路由表進(jìn)行轉(zhuǎn)發(fā)，避免跨主機(jī)容器訪問時bridge的二層端口查詢。同網(wǎng)段節(jié)點(diǎn)容器報(bào)文無封包，跨網(wǎng)段節(jié)點(diǎn)容器報(bào)文利用IPIP協(xié)議封包。下面的柱狀圖是在千兆網(wǎng)卡的環(huán)境使用netperf對這種方案進(jìn)行了測試，圖中長連接和短連接都是64字節(jié)。

最終，GaiaStack通過自研的網(wǎng)絡(luò)插件，實(shí)現(xiàn)了四種網(wǎng)絡(luò)模式，GaiaStack之所以提供四種網(wǎng)絡(luò)模式，是因?yàn)獒槍Σ煌膽?yīng)用場景，最適合的網(wǎng)絡(luò)模式是不同的，可以對每種網(wǎng)絡(luò)模式揚(yáng)長避短，每種網(wǎng)絡(luò)模式都有對應(yīng)的場景。應(yīng)用在創(chuàng)建的時候，可以直接選擇想要的網(wǎng)絡(luò)模式，同一主機(jī)的不同容器可以選擇不同的網(wǎng)絡(luò)模式。

多資源管理維度。

大家聽到了很多容器相對于虛擬機(jī)的優(yōu)勢，但是不可避免的，我們也要注意一下容器相對于虛擬機(jī)的劣勢，比如安全方面，比如隔離維度方面。這一節(jié)我們中重點(diǎn)講一下資源管理維度。GaiaStack將所有的資源都納入了quota管理維度中，如下圖所示。

Docker和kubernetes都默認(rèn)支持CPU和內(nèi)存管理，我們將GaiaStack的資源管理緯度擴(kuò)展到全維度，來保證各種應(yīng)用可以安全的共享集群和主機(jī)的資源。

下面以網(wǎng)絡(luò)入帶寬為例：當(dāng)沒有網(wǎng)絡(luò)入帶寬控制時，在同一個主機(jī)上的各進(jìn)程的帶寬和時延都得不到任何保證。

我們對網(wǎng)絡(luò)IO的控制目標(biāo)主要有兩個：

一是保證配額資源，第二是當(dāng)有空閑資源時，不要浪費(fèi)，可以借用其他cgroups的空閑帶寬。當(dāng)然還有優(yōu)先級相關(guān)的控制，以及性能的要求。加入了GaiaStack的網(wǎng)絡(luò)入帶寬控制之后，對于資源需求分別是50M和800M的兩個cgroups，機(jī)器可供分配的總帶寬是850M，也就是沒有空閑帶寬，兩個cgroups都按照自己的資源需求得到了帶寬。

第二個圖，機(jī)器上仍然是850M的總帶寬，兩個cgroups分別是20和70M，那么有130M的空閑帶寬，我們可以看到兩個cgroups可以用到超過自己配額的資源。

存儲管理

Kubernetes已經(jīng)有了一些存儲管理，但主要還是基于PV/PVC的機(jī)制，而應(yīng)用更需要的是把本地存儲能夠像CPU、內(nèi)存一樣的當(dāng)作資源來管理，比如一個磁盤有100G空間，可以讓10個需要10G的pod共享，并且每個pod所占用的空間是可控的。但磁盤容量的調(diào)度和管理會比CPU、內(nèi)存更加復(fù)雜，因?yàn)楹芏嘤?jì)算節(jié)點(diǎn)通常是多個分區(qū)，比如騰訊的某些服務(wù)器，有十幾個磁盤。

為了得到更精確的調(diào)度和控制，我們將所有分區(qū)的可用資源信息都做了上報(bào)和管理。也將磁盤容量作為GaiaStack應(yīng)用提交時可以指定的一個資源維度，讓用戶可以按照需求來申請。

有了磁盤容量管理之后，解決了用戶的日志等本地存儲的需求，但是我們發(fā)現(xiàn)仍然不能解決所有的存儲場景。比如，當(dāng)用戶需要更大的磁盤空間時，可能這個空間已經(jīng)超出了單機(jī)的范圍。比如當(dāng)pod發(fā)生遷移時，需要帶數(shù)據(jù)遷移。比如當(dāng)業(yè)務(wù)發(fā)現(xiàn)申請的磁盤容量不足，需要在線擴(kuò)容時等等，此時，云硬盤就是一個很好的解決方案。但通常的云硬盤操作是由用戶來申請，然后在創(chuàng)建應(yīng)用的時候關(guān)聯(lián)，在需要回收的時候清理掉。我們線上有些app有4k多個實(shí)例，用戶無法實(shí)現(xiàn)這么大規(guī)模的云盤管理和操作。

因此，GaiaStack又引入了輕盤的概念，即由系統(tǒng)來維護(hù)輕盤的生命周期，用戶只需要指定輕盤的size和文件系統(tǒng)類型，就可以無需改動代碼而使用云盤的好處。在具體的云盤實(shí)現(xiàn)支持中，GaiaStack還可以支持獨(dú)占型和共享型的云盤，來滿足不同的場景需要。

在私有云場景下，云盤的底層實(shí)現(xiàn)，我們使用的是ceph，在公有云的場景下，可以和公有云的基礎(chǔ)設(shè)施做對接。

為何在私有云中選擇ceph

第一、ceph本身是一個非常優(yōu)秀的存儲系統(tǒng)。它的RBD幾乎是openstack的事實(shí)標(biāo)準(zhǔn)，rgw和fs也得到了越來越廣泛的應(yīng)用。

第二、容器平臺用到了ceph的所有場景，比如云盤使用的是RBD，共享云盤使用了cephfs，registry的后端存儲用的是ceph rgw，而ceph是一個統(tǒng)一的分布式存儲，我們就不需要為每種場景去選擇和維護(hù)不同的存儲系統(tǒng)了，大大降低了我們的管理成本和實(shí)現(xiàn)復(fù)雜度。

第三、ceph是GaiaStack的一個子團(tuán)隊(duì)，我們在騰訊內(nèi)部也運(yùn)營著服務(wù)各個BG的ceph存儲平臺，名為Tethys，也做了非常多的優(yōu)化，包括在可擴(kuò)展性方面，實(shí)現(xiàn)了多MDS，在性能方面，特別針對大目錄中大量文件的場景做了性能優(yōu)化，另外，在內(nèi)核的Cephfs模塊，也fix了大量的內(nèi)核bug，以及眾多新特性的開發(fā)。

P2P registry

Registry是GaiaStack的基本組件，我們服務(wù)在線應(yīng)用時，一般沒有什么問題，但在離線應(yīng)用中，需要大規(guī)模的應(yīng)用部署時，性能問題就暴露的比較明顯了，為此，我們開發(fā)了P2P的Registry。在鏡像下載過程中，引入BT協(xié)議，在blob上傳時，對blob生成種子，在下載鏡像的blob時，先下載種子，再通過種子文件下載數(shù)據(jù)。而在具體的實(shí)現(xiàn)中，我們采用了一個外部的agent組件，這樣不需要修改Docker daemon，對Docker做到了零入侵，并且也優(yōu)化了peer選取算法，盡量減少registry的流量。

Tapp應(yīng)用

Kubernetes已經(jīng)支持了很多的應(yīng)用類型，如deployment、statefulset、job等等，但是這些應(yīng)用類型對于騰訊的很多業(yè)務(wù)還是不夠，經(jīng)過多年的海量運(yùn)營教育，我們已經(jīng)有了騰訊獨(dú)有的應(yīng)用模式，為此，我們擴(kuò)展了kubernetes的應(yīng)用，增加了Tapp（Tencent App）類型。不過在后來的推廣中發(fā)現(xiàn)，Tapp不僅僅是騰訊的需求，很多企業(yè)都有類似的需求，因此我們現(xiàn)在稱Tapp為“通用服務(wù)”。如實(shí)例具有可以標(biāo)識的id。實(shí)例有了id，業(yè)務(wù)就可以將很多狀態(tài)或者配置邏輯和該id做關(guān)聯(lián)；每個實(shí)例可以綁定自己的云硬盤；可以?實(shí)現(xiàn)真正的灰度升級/回退；可以指定實(shí)例id做刪除、停止、重啟等操作；對每個實(shí)例都有生命周期的跟蹤。

對GPU的支持

GaiaStack從2015年起就支持騰訊的AI平臺，GPU的場景對GaiaStack也提出了非常多的要求。通過GaiaStack來實(shí)現(xiàn)云化的GPU管理，提升效率和易用性。我們使用Tapp來支持GPU的應(yīng)用，讓GPU應(yīng)用可以更好的云存儲打通。智能感知GPU拓?fù)?#xff0c;支持GPU的拓?fù)湔{(diào)度，提升了應(yīng)用執(zhí)行效率。鏡像與驅(qū)動分離，使得更新驅(qū)動版本對用戶透明。經(jīng)過幾年的發(fā)展，很多GPU集群已經(jīng)變成了異構(gòu)集群，不同型號的GPU，價格和性能差異都很大，為此我們在quota管理中，不但有卡數(shù)的維度，也同時引入了卡的類型。由于GPU應(yīng)用大部分是離線業(yè)務(wù)，所以GaiaStack實(shí)現(xiàn)了業(yè)務(wù)組之間的彈性quota管理，用以提升整個集群的整體使用率。最近我們還上線了GPU軟件虛擬化的特性，進(jìn)一步提升了GPU卡的使用率。

如下圖是兩個實(shí)驗(yàn)場景：左圖實(shí)驗(yàn)是vcuda-1容器?申請了0.5個卡，7680MB，運(yùn)?行行在0號GPU，vcuda-2容器?獨(dú)占卡，運(yùn)行在1號GPU；vcuda-1的訓(xùn)練速率是平均43.8/s，vcuda-2的訓(xùn)練速度是平均86.6/s。右圖實(shí)驗(yàn)是vcuda-1容器?申請了了0.3卡，7680MB，運(yùn)行在0號GPU，vcuda-2容器?申請了60%利用率，12800MB，運(yùn)行在0號GPU；vcuda-1的的訓(xùn)練速率是平均25.22/s， vcuda-2的訓(xùn)練速度是平均54.7/s。

GaiaStack和社區(qū)kubernetes版本的關(guān)系

GaiaStack是一個企業(yè)版的kubernetes容器平臺，基于生產(chǎn)環(huán)境的需求，對可用性做了很多完善，也實(shí)現(xiàn)了很多的功能，但是我們也非常謹(jǐn)慎的處理與社區(qū)版本的關(guān)系。

主要有幾個方面：

第一、跟隨社區(qū)。社區(qū)的大版本我們都會merge。所以GaiaStack的大多數(shù)實(shí)現(xiàn)都是非入侵的實(shí)現(xiàn)，比如網(wǎng)絡(luò)是我們自研的galaxy插件，GPU的管理也是一個gpuManager的插件，等等，方便與社區(qū)版本的merge。

第二、貢獻(xiàn)社區(qū)。我們在ceph、docker、kubernetes等社區(qū)都會積極的貢獻(xiàn)，我們也在騰訊內(nèi)部連續(xù)兩年拿到行業(yè)貢獻(xiàn)獎。

第三、兼容社區(qū)kubernetes的所有原生接口，不對用戶做特殊要求。

需要獲取嘉賓演講原版PPT的同學(xué)可以直接在公眾號內(nèi)回復(fù)“GaiaStack”即可獲取。

總結(jié)

以上是生活随笔為你收集整理的腾讯GaiaStack容器平台负责人罗韩梅：All on GaiaStack的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。