KubeCon + CloudNativeCon 首次登陸中國上海。這意味著中國Kubernetes 愛好者們齊聚上海來參與這場全球范圍內最大的 Kubernetes 技術盛會。數據平臺部高級工程師宋盛博在大會上介紹了騰訊企業級容器云平臺GaiaStack在機器學習場景的實踐，即《Deep CustomizedKubernetes for Machine Learning in Tencent》

首先簡單介紹一下GaiaStack。GaiaStack是騰訊基于kubernetes打造的容器私有云平臺。服務于騰訊內部各個BG的業務，如廣告、支付、游戲等業務，同時支持騰訊云的各行業客戶做私有云部署。GaiaStack的目標是支持各種類型的應用，包括微服務、devops場景、大數據、有狀態應用、AI平臺、區塊鏈、物聯網等等，并從底層的網絡、存儲到docker、kubernetes，以及部署、監控的產品化等各方面完善了容器平臺的企業級實現。

為了實現大規模企業級機器學習平臺，我們對kubernetes做了不少定制化的優化，因為kubernetes的官方版本并不是專門為ML設計的，比如對GPU拓撲的感知，對一些應用的host devices的使用，對GPU資源的管理，已有的各種workload類型，比如deployment、statefulset、job，cronjob等都不能很好的適應ML等等。

時間關系，今天主要講四個方面：

GPU topology awareness scheduler

GPU通信方式有四種，分別是SOC、PXB、PHB和PIX，他們的通信代價依次降低，由拓撲關系決定。為了讓GPU卡之間的通信開銷占比減小，以下圖為例，運行在GPU-0和GPU-1上的app的運行時間會比運行在GPU0上和GPU3上小很多。因此，Gaia Scheduler實現了GPU集群資源-訪問代價樹算法，來對GPU的拓撲關系進行感知，并且在調度中充分考慮該拓撲關系。具體的實現可以參考我們即將在The IEEE?ISPA?2018發表的論文《GaiaScheduler: A Kubernetes-based Scheduler Framework》。

如下圖這個例子，GaiaStack scheduler實現的對GPU卡的分配是GPU0,1，相對于默認分配到GPU0,2，data transmit speed提升了200%。

GPU resource management

第二部分是GPU的資源管理。我們知道NVIDIA對單個GPU的共享有兩種方式：VM使用的NVIDIA GRID以及進程使用的MPS Service。NVIDIA GRID并不適合Kubernetes的container Runtime場景。MPS Service未實現隔離，且對每個進程使用的GPU資源采用了硬限制的方式，在程序運行中無法修改。分時調度也不是基于容器的資源請求，總之，對GPU是無法實現基于容器級的軟件虛擬化。但由于GPU價格昂貴，對GPU資源的容器級別的軟件虛擬化具有巨大的意義。

實現GPU虛擬化有三個挑戰：第一是Transparency，不對k8s以及用戶的應用程序做入侵，第二是性能，第三是隔離。為了實現對k8s的透明，GaiaStack使用了deviceplugin，來做GPU資源的發現以及為任務分配相應的硬件資源及配置容器運行時環境。在具體實現中，引入了四個核心組件，GPU Manager，GPU Scheduler，vGPU Manager和vGPU Library，如圖所示，實現了雙層資源管理，在主機層，GPU Manager負責創建vGPU，GPUScheduler負責為vGPU分配物理GPU資源。在容器層，vGPU Library負責管理具體容器的GPU資源。用戶的資源請求會通過Manager控制，但程序運行起來后，所有的數據讀寫就不再經過Manager，最大限度的減少overhead。我們選取了不同的深度學習框架進行測試，分別在物理機和容器內使用每一個框架運行MNIST應用，并測試執行時間。Overhead都不超過1%。具體的實現可以參考我們即將在TheIEEE?ISPA?2018發表的論文《GaiaGPU: Sharing GPUs inContainer Clouds》。

為評估GPU資源管理方法的有效性，我們在Tesla P4機器上進行了實驗。如圖所示我們在一個GPU上運行了兩個Tensorflow的AlexNet應用，分別為兩個進程分配30%和70%的GPU資源。NVIDIA默認分配策略將資源均等的分給兩個進程，因此先開始的進程先結束。而我們的分配策略是基于進程資源的，因此擁有較多資源的進程先結束。

Tapp - a CRD of Kubernetes

應用管理方面方面， Kubernetes提供了deployment、statefulset、job等應用類型各司其職，分別運行微服務，有狀態服務和離線作業。這些應用類型看似美好，但是實際使用時會遇到各種各樣的問題，比如在縮容時deployment無法支持按照指定的策略進行，statefulset的升級只能按標號順序依次進行，且一個statefulset不能同時灰度兩個以上的鏡像版本，而所謂的支持離線的job類型，Spark on Kubernetes的實現甚至都沒有用job來運行。

騰訊內部很多業務都是存量業務，需要能按照運維人員的策略控制每個實例的狀態，比如灰度升級場景，和statefulset提供的灰度功能不太一樣，業務可能希望今天對某個聯通VIP的業務實例進行升級，這個VIP下的業務實例的id不一定是有序的，升級完一周后，如果運行穩定，再對其他VIP的實例分批次進行升級，中間可能長時間維持運行多個版本的穩定狀態。Statefulset的功能無法達到這樣的效果，所以我們開發了TApp（Tencent App）的應用類型。TApp是利用Kubernetes CRD功能定義的擴展API，TAppSpec對PodSpec進行了封裝，支持指定每個實例的PodSpec模版和期望的狀態。正是基于這樣的設計，TApp相比Statefulset優勢有：支持指定若干實例多次進行啟動、停止、刪除、原地灰度升級、回退等操作；灰度升級功能不只是修改鏡像版本，甚至可以多加一個容器；單個TAPP應用的Pod支持N個版本。此外TApp與Statefulset應用類型具有一些相同點：Pod具有唯一自增ID；綁定單獨云盤，遷移時數據盤跟隨遷移。

在后來的推廣中我們發現TApp不僅僅是騰訊的需求，很多企業都有類似的需求，因此我們現在稱TApp為“通用服務”。目前GaiaStack上運行的絕大多數任務，不論是在線服務，離線業務，都使用的我們自研的通用服務類型。

Galaxy - a powerful CNIplugin

存量業務往往要求IP端口固定，而微服務對這些沒有要求。在線服務相比離線業務一般單臺服務器的虛擬化比低，但是對網絡性能的要求高。為支持這些不同的需求，GaiaStack自研的Galaxy網絡插件為用戶提供兩種網絡類型：Underlay 網絡，即基于宿主機物理網絡環境的方案。這種方案下容器與現有網絡可以直接互通，不需要經過封包解包或是NAT，其性能最好。但是缺點也很明顯，其普適性較差，且受宿主機網絡架構的制約，比如IP可能不夠用。Overlay 網絡，即通用的虛擬化網絡方案。這種方案不依賴于宿主機底層網絡架構，可以適應任何的應用場景，方便快速體驗。因為在原有網絡的基礎上疊加了一層Overlay網絡，封包解包或者NAT對網絡性能都是有一定損耗的。

在實現Underlay網絡方案時，考慮到GaiaStack面臨騰訊內部場景，共有云場景和外部企業客戶私有化場景，而每個場景的底層網絡架構都是不一樣的，所以我們的Underlay方案不會對底層網絡有入侵。我們目前支持了Linuxbridge/MacVlan和SRIOV，根據業務場景和硬件環境，具體選擇使用哪種網橋。下面這兩幅圖就是生產環境使用SRIOV替換bridge網橋后帶來的性能提升，CPU使用降低約1/3，包量反而增加6%。

我們通過實現Kubernetes調度器插件galaxy-ipam，支持了存量業務使用Underlay網絡IP不變的功能，圖中Floatingip即指Underlay IP。

另外我們最開始就希望能夠將在線和離線混部以節省服務器資源，事實上也運營著這樣的集群，所以網絡最開始就被設計為：不同的應用可以選擇不同的網絡模式；同一主機的不同容器可以選擇不同的網絡模式。

對于Overlay網絡，我們調研了很多開源容器網絡項目，發現其各有利弊。在綜合考慮上述各方案優缺點后，我們汲取了flannel/calico容器網絡開源項目的優處，實現了基于IPIP和Host Gateway的混合方案。同節點的容器報文無橋接方式，利用主機路由表進行轉發，避免跨主機容器訪問時bridge的二層端口查詢。二層相連節點的容器報文無封包，利用主機路由表進行轉發，因為無封包所以性能最優。跨網段節點容器報文利用IPIP協議封包，IPIP外層額外包頭僅20字節，開銷較vxlan 50字節更小，所以性能好于vxlan。我們的方案提交到了flannel官方，并被社區合并

https://github.com/coreos/flannel/pull/842。

下面的柱狀圖是在千兆網卡的環境使用netperf對這種方案進行了測試，圖中長連接和短連接都是64字節，從圖中可以看出IPIP和Hostgateway相比Vxlan帶來14%到40%的性能提升。

網絡隔離方面，我們基于iptables和ipset實現了Kubernetes網絡策略，為業務提供了細粒度的隔離能力。網絡策略的設計如下圖所示，充分利用ipset和iptables multiport extension減少iptables規則條數。

其他

除了上面講的這幾個方面之外，為了更好的支持ML，我們對底層的分布式存儲也做了大量的優化，比如對ceph引入了quota管理，優化了掛載權限，并可以動態修改規則，實現了回收站的功能，對大目錄的優化、多mds的優化等等。更好的保證了ML類型業務對底層存儲性能要求。

另外，由于很多ML作業運行時間較長，而且GaiaStack還要同時支持在線應用，所以對可用性要求更高，因此GaiaStack實現了完全的熱升級，即GaiaStack系統本身的跨版本升級對上面運行的應用完全沒有影響，不但pod不會丟失，而且也不會重啟。

在資源管理方面，除了這里講的對GPU資源的優化，我們還增加了多磁盤的本地磁盤容量管理、網絡帶寬管理，并且將所有的資源維度都納入quota管理，以及資源調度等，更好的完善了容器云的資源管理能力。

對于大規模的ML集群，我們也實現了零入侵的P2P registry，大大提升了鏡像下載的效率，并且通過優化算法，大大減少了registry流量的比例，詳細可以參考《FID: A Faster Image Distribution System for Docker Platform》2017 IEEE2nd International Workshops on FASW。

目前，GaiaStack在騰訊內部服務于所有BG，在公司外部，GaiaStack已經落地了多家標桿客戶，比如建行、招行、數字廣東、公安部等。除了作為獨立的容器私有云產品之外，還和騰訊內的很多重量級平臺一起對接出海，強強聯合，比如專有云TCE，GaiaStack不但支持騰訊專有云TCE上六十多個基礎產品，300多個應用，本身也是TCE的一個子產品，此外，GaiaStack還對接了微服務治理框架TSF，機器學習平臺TiOne，虛擬機私有云Tstack等重要產品。

總結

以上是生活随笔為你收集整理的腾讯容器云平台GaiaStack亮相kubeCon的全部內容，希望文章能夠幫你解決所遇到的問題。

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