騰訊基於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

第1、Ceph自己是一個很是優秀的存儲系統。它的RBD幾乎是OpenStack的事實標準，RGW和FS也獲得了愈來愈普遍的應用。

第2、容器平臺用到了Ceph的全部場景，好比雲盤使用的是RBD，共享雲盤使用了CephFS，Registry的後端存儲用的是Ceph RGW，而Ceph是一個統一的分佈式存儲，咱們就不須要爲每種場景去選擇和維護不一樣的存儲系統了，大大下降了咱們的管理成本和實現複雜度。

第3、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容器平臺，基於生產環境的需求，對可用性作了不少完善，也實現了不少的功能，可是咱們也很是謹慎的處理與社區版本的關係。

主要有幾個方面：

第1、跟隨社區。社區的大版本咱們都會Merge。因此GaiaStack的大多數實現都是非入侵的實現，好比網絡是咱們自研的Galaxy插件，GPU的管理也是一個GPU Manager的插件，等等，方便與社區版本的Merge。

第2、貢獻社區。咱們在Ceph、Docker、Kubernetes等社區都會積極的貢獻，咱們也在騰訊內部連續兩年拿到行業貢獻獎。

第3、兼容社區Kubernetes的全部原生接口，不對用戶作特殊要求。