GaiaStack是騰訊基於Kubernetes打造的容器私有雲平臺。這裡有幾個關鍵詞：
-
騰訊：GaiaStack可服務騰訊內部所有BG的業務；
-
Kubernetes：GaiaStack的技術實現主要是依託於Kubernetes和容器；
-
私有雲：GaiaStack透過騰訊雲向外部企業輸出解決方案，併成功在金融、遊戲、政務、網際網路等各行業落地。
GaiaStack的產品功能主要分為下麵兩個部分，分別是叢集管理員的叢集管理功能，以及叢集使用者的應用全生命週期管理的功能。
叢集管理中包括對叢集的部署、監控、告警、日誌以及規劃管理等。應用全生命週期的管理是從開碼構建開始，到交付中心、應用的上線、以及後續對應用的自動化運維等各種操作。
從整體架構看，GaiaStack基於Kubernetes、Ceph、Docker、網路等底層技術，完善了認證鑒權，自動化運維等方面，支援程式碼構建、映象倉庫、應用管理、服務編排、負載均衡、自動運營等應用場景，並向用戶提供了訪問入口、WebShell、日誌檢索、配置管理、WebPortal、操作審計等使用者工具。
我們對GaiaStack的定位是一個Cluster Operation System，因此它需要承載各種各樣的應用型別，即All on GaiaStack，比如開發應用、測試應用、微服務應用、有狀態應用、科學計算應用、GPU應用等等。要支援所有型別的應用，僅僅將原生的Kubernetes產品化是遠遠不夠的。
應用生命週期以程式碼構建開始，可以關聯程式碼倉庫、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服務應用為例，檢視其中一個實體的事件：
-
2018-02-06 11:46:38 V7版本開時候執行；
-
2018-02-09 09:33:02 對該實體做灰度升級，從V7版本升級到V8版本；
-
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的自動對接，在騰訊雲和黑石環境上，也和對應的負載均衡做了對接。
-
負載均衡可以跨叢集；
-
負載均衡可以跨App；
-
負載均衡可以對單個實體做操作，即可以對某一個或者多個實體做系結、解綁以及再系結等操作；
-
負載均衡的生命週期和應用的生命週期獨立，即可以在建立應用時系結負載均衡，也可以在應用執行中系結或解綁負載均衡。
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的資源管理緯度擴充套件到全維度，來保證各種應用可以安全的共享叢集和主機的資源。
下麵以網路入頻寬為例：當沒有網路入頻寬控制時，在同一個主機上的各行程的頻寬和時延都得不到任何保證。
一是保證配額資源，第二是當有空閑資源時，不要浪費，可以借用其他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本身是一個非常優秀的儲存系統。它的RBD幾乎是OpenStack的事實標準，RGW和FS也得到了越來越廣泛的應用。
第二、容器平臺用到了Ceph的所有場景，比如雲盤使用的是RBD，共享雲盤使用了CephFS，Registry的後端儲存用的是Ceph RGW，而Ceph是一個統一的分散式儲存，我們就不需要為每種場景去選擇和維護不同的儲存系統了，大大降低了我們的管理成本和實現複雜度。
第三、Ceph是GaiaStack的一個子團隊，我們在騰訊內部也運營著服務各個BG的ceph儲存平臺，名為Tethys，也做了非常多的最佳化，包括在可擴充套件性方面，實現了多MDS，在效能方面，特別針對大目錄中大量檔案的場景做了效能最佳化，另外，在內核的CephFS模組，也fix了大量的核心bug，以及眾多新特性的開發。
Registry是GaiaStack的基本元件，我們服務線上應用時，一般沒有什麼問題，但在離線應用中，需要大規模的應用部署時，效能問題就暴露的比較明顯了，為此，我們開發了P2P的Registry。在映象下載過程中，引入BT協議，在blob上傳時，對blob生成種子，在下載映象的blob時，先下載種子，再透過種子檔案下載資料。而在具體的實現中，我們採用了一個外部的agent元件，這樣不需要修改Docker daemon，對Docker做到了零入侵，並且也優化了peer選取演演算法，儘量減少Registry的流量。
Kubernetes已經支援了很多的應用型別，如deployment、statefulset、job等等，但是這些應用型別對於騰訊的很多業務還是不夠，經過多年的海量運營教育，我們已經有了騰訊獨有的應用樣式，為此，我們擴充套件了Kubernetes的應用，增加了Tapp（Tencent App）型別。不過在後來的推廣中發現，Tapp不僅僅是騰訊的需求，很多企業都有類似的需求，因此我們現在稱Tapp為“通用服務”。如實體具有可以標識的ID。實體有了ID，業務就可以將很多狀態或者配置邏輯和該id做關聯；每個實體可以系結自己的雲硬碟；可以 實現真正的灰度升級/回退；可以指定實體id做刪除、停止、重啟等操作；對每個實體都有生命週期的跟蹤。
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的管理也是一個GPU Manager的外掛，等等，方便與社群版本的Merge。
第二、貢獻社群。我們在Ceph、Docker、Kubernetes等社群都會積極的貢獻，我們也在騰訊內部連續兩年拿到行業貢獻獎。
第三、相容社群Kubernetes的所有原生介面，不對使用者做特殊要求。
本次培訓包括：Docker介紹、Docker映象、網路、儲存、容器安全；Kubernetes架構、設計理念、常用物件、網路、儲存、網路隔離、服務發現與負載均衡；Kubernetes核心元件、Pod、外掛、微服務、雲原生、Kubernetes Operator、叢集災備等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
![]()
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
