星辰算力平臺實現百萬CPU核的管理調度，大規模GPU卡的高低優先級調度和算力超賣，并以云原生的方式提供大規模、高效率、低成本的CPU、GPU算力服務。

騰訊業務及組織架構現狀

先簡單和大家介紹一下騰訊內部的業務及相關組織架構的現狀，有助于幫助大家理解為什么我們會基于后面的架構來設計整套方案。

下圖的應用大多數人經常會用到，比如微信、騰訊視頻、游戲等等APP，其背后承載的技術也不盡相同，涉及了NLP、計算機視覺、強化學習、語音等不同的AI技術。

比如我們玩的《王者榮耀》或者下圍棋，背后所對應的就是用強化學習訓練出來的一個機器人，玩游戲沒有隊友陪同時，機器人可以滿足我們對戰合作等游戲需求。

不同的業務部門，APP對外需求也不同，均會針對自己的業務場景做一些AI平臺的定制。我們做的是底層算力，給業務部門提供服務時，在考慮整體資源利用率的情況下，也要為各業務便捷地去做些定制服務，這就是騰訊內部的一個多租戶的現狀。

業務特點與規模

接下來，介紹一下騰訊內部業務的一些特點以及大概規模。

目前的環境是基于開源項目TKEStack，TKEStack是騰訊公有云TKE的開源版本，是一個開源的容器云平臺解決方案，用的KubernetesV1.14版本，操作系統是騰訊自研的Linux操作系統，已經為GPU或者騰訊內部業務做了一層性能的調優和bugfix。

GPU節點是NVIDIA的V100、P100，個別會有一些M40的機器。網絡聯通使用100G的RoCE，既能夠提供以太網的支持，又能夠提供RDMA的網絡協議支持，對于用戶去做一些多機通信的優化有事半功倍的效果，也從硬件層面保證了整體的使用效率。

完整流程設計思路

接下來介紹一下我們是怎么完善、開發以及設計這一整套流程的。

Kubeflow 是什么

這里先介紹一下關于Kubeflow以及Kubeflow里面一些主要的組件，幫助大家理解其中的一些具體業務，或者設計。

Kubeflow自從2017年底發布，目前逐漸成為主流的在Kubernetes上面跑機器學習、深度學習等訓練或者推理任務的主要工具。

Kubeflow包含非常多的組件，比較多的像Operator ，或者像自動調參的工具。

Operator

先介紹一下Operator，它是Kubernetes中的一種概念，主要是用來打包、部署以及管理用戶的任務。但在Kubeflow里面，Operator主要用來管理機器學習或者深度學習里面的任務。

那么它能幫用戶做什么呢？

比如在多機的任務下面，如何去管理和維護一個任務的多個節點，以及之前通信是怎么做的，怎么能夠幫助用戶管理整個Pod以及任務的生命周期，比如某一個Pod失敗了，整個任務是終止還是有一些其他的容錯辦法，這個都是由Operator來完成。

目前主流的Operator有幾種，會對應每一種框架。比如用的最多的TF-Operator，主要對應的是tensorflow，MPI-Operator主要對應Horovod，Pytorch和Caffe2的Operator，它們針對各自的框架都有一些定制的場景。

這里著重介紹兩種Operator以及我們對它做的一些重點優化，也是我們用的比較多的兩個Operator以及框架任務。

MPI-Operator

MPI-Operator是為了MPI的任務或者Horovod的任務提供一個多機的管理工作。它有V1 α1、V1 α2以及V1的版本，V1正在大規模開發中，所以我們推薦用V1 α2 。未來V1 release之后，可以推薦使用。

在這種版本下面，它有兩個概念：一個Launcher，另一個是Worker。Launcher相當于一個啟動器的角色，它會等Worker都就位之后，去啟動MPI的任務。但是在這里，Launcher本身就會占用一些CPU的資源，其實我們是可以將它合并到一起的，也確實做了一些改進并提交到社區，去掉一些無用的CPU的Pod，讓某一個GPU節點起到這種角色。

此外，為了提升Pod的創建速度，以及提升Job的啟動速度，我們也做了一些優化。

比如Launcher在等待其他Worker就位的時候，是從其他Shell腳本的版本變成了多線程的工具，可以極大提升整體的等待時間。

除此之外，比如再增加一個額外的init container去下載用戶的docker鏡像，這樣來做docker鏡像類似于并行加載這種方式。

我們推薦是直接參照Kubeflow的MPI Operator的GitHub去查看更多的詳情，大體的流程也在上圖右側展示出來，主要是將MPI Job換成對應的Kubernetes可以識別的一些資源，比如使用CRD、使用Configmap以及RBAC控制權限等等。

TF-Operator

除了MPI-Operator，還有另外一個用得更多的是TF-Operator，TF-Operator主要就是幫助用戶啟動多機的一個PS-Worker這種架構的情況下的一個多機的任務，因為這個集群全部是GPU相關的集群，所以我們推薦用戶是將PS和Worker放在一個Pod里面啟動，減少一些通信的成本。

除此之外，我們還做了一些額外的優化。比如像就近部署的方案以及脫庫調度的方案。為了加快image加載的時間，也是用IfNotPresent這種方式去加快整個的速度。

目前TF-Operator還是比較完善的，其他各家公司也都會有比較多的投入。

多租戶場景下使用Kubeflow構建訓練平臺

介紹完Kubeflow目前的一些Operator，言歸正傳，今天的主題也是多租戶的場景下面使用Kubeflow構建一個訓練平臺。

常規構建方案

先來看一下目前Kubeflow的多租戶平臺是如何構建的。

目前，在這個平臺有兩種方式，一種是用原生的Kubernetes RBAC，就是Role based access control去做權限的管控。另外一種是使用Istio，Istio這種方式更偏向于推理場景。通過這種方式對用戶的訪問進行一個控制。

可以簡單來看這張圖，當我們為用戶提供一個集群，一般有兩種方式。一種是通過命令行的方式使用，另外一種就是提供Web端，Web端通過Istio的gateway接入整個集群，然后Istio的RBAC去做權限管控、去做流量的分發、去維護整個集群的權限。

另外一點，如果是客戶端，除了集成的客戶端，另外還引入Kubernetes的RBAC去做允許或禁止，幫助用戶解決權限管控的問題。

但它有一個小的問題，就是所有的用戶都會共用所有這些資源，像Operator、Controller，用戶只能使用定義好的資源，比如我們設計好一種Job的類型或者Operator的類型，那么用戶就必須這么使用。

但是對于多個事業群，大家會有一些自定義的需求或者定制的Operator，在這種場景下，就會有些捉襟見肘。為此，我們也引入了一些其他的方式改善這種需求。

優化構建方案

用戶分層

現在我們做的多租戶的Kubeflow訓練平臺，首先在資源層將GPU資源聚集到一個或多個集群，在此GPU集群之上提供多個用戶的集群，也是K8s的集群。用戶可以通過Virtual Kubelet，然后接入到底層的算力集群，分成兩層：

1.?在用戶的集群，這些租戶的管理員去管理或者去創建，去自己定義一些Operator或者Controller，用戶接入的是這些租戶的K8s原生的KPI；

2.?在底層算力集群 ，我們統一集中調度，提升資源利用率。

當有任務下發的時候，通過Virtual Kubelet，或者用Kubernetes實現的Virtual Node轉發到算力集群，在底層算力層面而言，可以通過Namespace隔離不同的租戶以及不同租戶的任務，將一些特定需求的節點劃分形成一些小的資源池，更多就是通過Namespace進行隔離。

但是對于上層用戶而言，他們有一些自定義的權限，也可以自己開發一些自己的組件，相當于將權限分離開。

我們這里實現的Virtual node，相當于用Virtual Kubelet實現的，Virtual Kubelet相當于Kubernetes上面一個開源的Kubernetes kubelet實現，最開始是由微軟的一個團隊開發并維護，后捐獻給了CNCF成為sandbox的項目。Virtual Kubelet后面是可以接入像ACI、AWS forgate、IOT等等可擴展的組件或者服務。比如OpenStack也是可以接入的。

而我們這里其實相當于接入了一個新的功能，它是一個比較簡單的，主要定義為用戶有一個Pod下發請求或者有一個其他資源下發請求，我們直接轉發到底層的一個K8s，同時Virtual Kubelet也會監控底層它關注的資源狀態，并將狀態匯報給上層，它相當于一個橋梁的作用，承上啟下去同步整體的狀態。

這張圖就是一個比較完善的用戶的集群或者用戶的一個架構圖。在左側有用戶的集群，對應的是通過Virtual Kubelet連接到底層不同的算力集群，這些算力集群都是有GPU資源的算力集群，也是K8s的集群。

如果用戶比較簡單，可以直接接入我們推薦的組件，形成一個整體的簡單管控策略。比如用戶想跑一些任務，以及有自己的controller去定義整個的規則，其實可以接入像MPI-Operator、TF-Operator等operator資源。

這里也多提一句，當用戶下發一個MPI的Job，MPI-Operator就會轉換成像Configmap、Secret，像RollBinding ，以及像多個Pod這種資源。

當這些轉換發生完成之后，Pod經過調度器到具體的某一個Virtual Kubelet，Virtual Kubelet發現資源到自己的節點后，會將其轉發到具體的某一個Kubernetes集群，并關注這些Pod或者其他資源的狀態，形成整個的一個轉發和傳遞的效果。

對于上層集群的管理員，不再需要關注底層集群的情況以及權限管控等，只要關注上一層即可。底層的管理員需要關注更多整體資源的使用情況，形成上下層的分離。

提升資源利用率

介紹完上下層分離以及怎么做多租戶這種場景，轉到我們之前提到的集群全部資源歸集到一起，主要目標是為了提升資源的利用率。當整個資源打通以后，怎么提升資源利用率？而且通過前面介紹的多租戶的機制，讓用戶也不用感知到。

在深度學習或者機器學習場景下，大部分任務都需要批量調度功能，也就是需要保證多個Pod同時地調度。它主要算法就是all or nothing的算法，保證整個資源要么可以調度，要么就不要調度，如果無法調度那么就排隊，保證整個資源不會被餓死。這是一個比較常見的需求。

這里面主要是用volcano去做gang-scheduling。

引入任務優先級

除此之外，我們也引入了一個優先級的任務。顧名思義，就是我們給每個用戶或者每個租戶都開放高優先級的任務，他們可以在一個固定時間之內被調度。當整個集群的利用率不太高的時候或者分配還有一些空間的時候，就可以開發一些低優的任務給用戶，用戶可以提交整個的彈性任務或者叫低優的任務。

這種任務下發下來之后，就可以以低優的任務占據這些空閑資源，當高優任務下發的時候，就可以搶占這些低優資源，保證整個資源池是最滿的狀態。

策略優化

最后一點是一些優化的策略，如基于網絡拓撲架構或者GPU的拓撲架構的拓撲調度或者使用binpack，減少底層集群的碎片，保證更多的資源是可以盡快被調度的。

其他的優化，如提升MPIJob的一個啟動速度，能夠盡快地將任務下發下去，將底層空閑的算力資源變得越來越少。

除此之外，眾所周知，我們跑GPU任務一般都會用nvidia—docker2版本，我們分析了一下，其實nvidia—docker2對應的版本，它的Pod啟動速度相比于一般的runC的這種啟動速度還是慢不少，分析原因，主要集中在每次啟動的Pod或者container，它都會去查詢CUDA或者Nvidia驅動的版本對應的信息，然后供Nvidia Container的CLI Prehook去操作。

但是在我們場景里面，其實不太能用得上，因為我們是一個私有云的平臺，私有云的平臺里面不涉及特別多的經常更換硬件或者驅動版本經常變化的場景。所以我們可以簡化。

怎么簡化呢？最簡單一種辦法，就相當于將CUDA、INVIDA這種驅動信息全部緩存下來，然后保存到某一個固定的文件，當機器重啟或者將驅動變化，CUDA的版本發生變化的時候，才會重新觸發這個動作，獲取更新的信息緩存下來，這樣可以大大減少每一次Pod創建的時候都會獲取這些信息的次數。

這個信息的時間，如圖中所示大約在幾百毫秒。

經過這樣一個優化，我們是?可以將整個Pod的啟動時間提升大概30%到40%的時間?。對于用戶體驗還是非常友好的。

當然這個只能說做幾百毫秒的優化，像深度學習的場景，CUDA的版本、Nvidia的版本，Nvidia驅動本身就比較大，所以如何能夠優化這個docker image的加載，或者能夠減少它的鏡像拉取，做一些預分發、預部署，這個也是我們非常關注的一點。除了一些調度層面可以做的事情，其實業界也有一個比較流行的方式就是做一種延遲加載。

docker image是分多層的，以及它分metadata。調查發現，基本上大多數的鏡像里面的內容一般不會被用上，能用上的也就10到20%。

我們做一些延遲加載，當它在用的時候才去加載，當然這個也是一個比較前沿或者時間性質的功能，我們也在重度參與。后面有一些進展，大家可以持續關注我們，會不斷和大家來分享。

總結

基于kubeflow目前的架構或者一些現有的組件支持多租戶以及一些后面優化的策略，為了提升整個用戶體驗，我們其實還是有很多工作去要去做。比如現在比較流行的彈性訓練任務，像基于kubeflow、基于horovod本身的可以動態伸縮，去占用更多的資源，能夠減少用戶的訓練時間，都是非常關鍵的。

另外一點，MPI-Operator本身V1.0的版本我們也在重點參與，希望它能盡快被release。

總結

以上是生活随笔為你收集整理的基于Kubeflow建立的星辰算力训练平台背后的技术架构的全部內容，希望文章能夠幫你解決所遇到的問題。

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