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

以下為演講內容：

GaiaStack介紹

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

1）騰訊：GaiaStack可服務騰訊內部所有BG的業務；

2）kubernetes：GaiaStack的技術實現主要是依托于kubernetes和容器；

3）私有云：GaiaStack通過騰訊云向外部企業輸出解決方案，并成功在金融、游戲、政務、互聯網等各行業落地。

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

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

從整體架構看，GaiaStack基于kubernetes、ceph、docker、網絡等底層技術，完善了認證鑒權，自動化運維等方面，支持代碼構建、鏡像倉庫、應用管理、服務編排、負載均衡、自動運營等應用場景，并向用戶提供了訪問入口、webshell、日志檢索、配置管理、webportal、操作審計等用戶工具。

我們對GaiaStack的定位是一個Cluster Operation System，因此它需要承載各種各樣的應用類型，即All on GaiaStack，比如開發應用、測試應用、微服務應用、有狀態應用、科學計算應用、GPU應用等等。要支持所有類型的應用，僅僅將原生的kubernetes產品化是遠遠不夠的。

接下來進入第二個部分，介紹一下GaiaStack上的應用全生命周期的管理。

應用生命周期以代碼構建開始，可以關聯代碼倉庫、CI/CD、制作鏡像等。一個項目可以被自動或者手動構建多次，也可以從頁面上看到每次構建的詳細日志。

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

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

鏡像倉庫中的鏡像可以分為個人鏡像、業務鏡像，還可以查看全部的公共鏡像，支持鏡像的導入以及安全掃描。

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

? ??

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

配置管理包括ConfigMap和Secret，主要還是kubernetes自身的機制，但是做了產品化，所以可以直接在界面上對配置做新建、編輯、刪除、關聯應用等等操作。配置也是提供所有業務、所有集群的同一視圖，一個配置組下面的多個配置統一查看和管理。

應用通過GaiaStack發布之后，對應用的運維還遠遠沒有結束，需要對應用做持續的運營操作。

常規操作主要是兩類：擴縮容和升級

擴縮容分為主動擴縮容和自動擴縮容，對于自動擴縮容，因為kubernetes本身支持，這里不再贅述，主要講一下GaiaStack和kubernetes不同的機制。

GaiaStack對應用的縮容可以支持定點裁撤，比如銀行的業務希望對沒有交易處理的實例做縮容，比如游戲的業務希望對沒有連接的實例做縮容，比如我們要裁撤掉集群中的某些計算節點等等。

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

下面以現網上一個提供圖片識別的OCR服務應用為例，查看其中一個實例的事件：

1）2018-02-06 11:46:38 V7版本開時候運行；

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

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

從這個事件流中可以發現有幾個點：

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

第二，灰度升級是一種原地升級，不但提升了效率，還可以復用原來pod的現場，而沒有經過調度器的環節，也消除了調度失敗導致升級失敗的風險。

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

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

事件管理包括應用以及實例的事件，并可以查看歷史的“所有”事件，避免因為kubernetes只保存一段時間事件導致在定位問題時丟失關鍵事件，但并不會增加etcd的壓力。用戶也可以直接通過webshell的方式進入容器，并進行各種操作。所有探測操作都是在認證和鑒權的保護下進行。

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

GaiaStack中的負載均衡實現有幾個特點：

1）負載均衡可以跨集群；

2）負載均衡可以跨app；

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

4）負載均衡的生命周期和應用的生命周期獨立，即可以在創建應用時綁定負載均衡，也可以在應用運行中綁定或解綁負載均衡。

GaiaStack的幾個關鍵技術：

全系統HA、熱升級

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

另外GaiaStack同時服務騰訊內部和外部業務，新版本是騰訊內部先升級試用穩定后才發對外版本，以保證對外版本均是穩定版本。GaiaStack的私有云版本還實現了一套產品化的自動安裝部署工具，提供了全部可視化的操作方式，降低了學習成本，并可以減少運維人員的操作失誤。

全網絡模式支持

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

最終，GaiaStack通過自研的網絡插件，實現了四種網絡模式，GaiaStack之所以提供四種網絡模式，是因為針對不同的應用場景，最適合的網絡模式是不同的，可以對每種網絡模式揚長避短，每種網絡模式都有對應的場景。應用在創建的時候，可以直接選擇想要的網絡模式，同一主機的不同容器可以選擇不同的網絡模式。

多資源管理維度。

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

Docker和kubernetes都默認支持CPU和內存管理，我們將GaiaStack的資源管理緯度擴展到全維度，來保證各種應用可以安全的共享集群和主機的資源。

下面以網絡入帶寬為例：當沒有網絡入帶寬控制時，在同一個主機上的各進程的帶寬和時延都得不到任何保證。

我們對網絡IO的控制目標主要有兩個：

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

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

存儲管理

Kubernetes已經有了一些存儲管理，但主要還是基于PV/PVC的機制，而應用更需要的是把本地存儲能夠像CPU、內存一樣的當作資源來管理，比如一個磁盤有100G空間，可以讓10個需要10G的pod共享，并且每個pod所占用的空間是可控的。但磁盤容量的調度和管理會比CPU、內存更加復雜，因為很多計算節點通常是多個分區，比如騰訊的某些服務器，有十幾個磁盤。

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

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

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

在私有云場景下，云盤的底層實現，我們使用的是ceph，在公有云的場景下，可以和公有云的基礎設施做對接。

為何在私有云中選擇ceph

第一、ceph本身是一個非常優秀的存儲系統。它的RBD幾乎是openstack的事實標準，rgw和fs也得到了越來越廣泛的應用。

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

第三、ceph是GaiaStack的一個子團隊，我們在騰訊內部也運營著服務各個BG的ceph存儲平臺，名為Tethys，也做了非常多的優化，包括在可擴展性方面，實現了多MDS，在性能方面，特別針對大目錄中大量文件的場景做了性能優化，另外，在內核的Cephfs模塊，也fix了大量的內核bug，以及眾多新特性的開發。

P2P registry

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

Tapp應用

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

對GPU的支持

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

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

GaiaStack和社區kubernetes版本的關系

GaiaStack是一個企業版的kubernetes容器平臺，基于生產環境的需求，對可用性做了很多完善，也實現了很多的功能，但是我們也非常謹慎的處理與社區版本的關系。

主要有幾個方面：

第一、跟隨社區。社區的大版本我們都會merge。所以GaiaStack的大多數實現都是非入侵的實現，比如網絡是我們自研的galaxy插件，GPU的管理也是一個gpuManager的插件，等等，方便與社區版本的merge。

第二、貢獻社區。我們在ceph、docker、kubernetes等社區都會積極的貢獻，我們也在騰訊內部連續兩年拿到行業貢獻獎。

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

需要獲取嘉賓演講原版PPT的同學可以直接在公眾號內回復“GaiaStack”即可獲取。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。