騰訊業務及組織架構現狀
先簡單和大家介紹一下騰訊內部的業務及相關組織架構的現狀，有助於幫助大家理解為什麼我們會基於後面的架構來設計整套方案。
下圖的應用大多數人經常會用到，比如微信、騰訊視訊、遊戲等等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是什麼呢？
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-OperatorMPI-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，然後接入到底層的算力叢集，分成兩層：
當有任務下發的時候，通過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。