在今年的KubeCon峯會上海站，作爲開源領域的貢獻者和推進者，華爲開源了面向高性能計算的雲原生批量計算平臺Volcano [vɒlˈkeɪnəʊ]。該項目基於華爲雲容器平臺大規模高性能計算應用管理的最佳實踐，在原生K8s的基礎上，補齊了作業(Job)調度和設備管理等多方面的短板。目前，Volcano在華爲雲上對接了包括一站式AI開發平臺ModelArts、雲容器實例CCI、雲容器引擎CCE在內的多款服務，是整個高性能計算領域不可或缺的基座。自開源以來，項目已經吸引了來自騰訊，百度，快手以及AWS等多個公司的貢獻者。
隨着容器化以及容器編排技術的普及，越來越多的上層業務正開始擁抱K8s生態，但無法否認的是，針對人工智能和大數據作業場景，原生K8s的支持度不高，終端用戶如果想要將現有的業務遷移到K8s平臺，很有可能會遇到下面的問題:
- 成組調度(Gang Scheduling)：一個BigData/AI的作業通常會包含多個任務，而業務邏輯一般要求Pod要麼同時啓動，要麼不啓動。比如，一個Tensorflow作業如果僅單獨拉起一種角色的任務(Ps or Worker)是沒法正常執行的。
- 資源公平調度(Fair-share)：部署的K8s集羣會存在多個Namespace，而每個Namespace也可能提交多個作業，如何調度資源才能避免某個Namespace的資源被無限制壓縮，又如何才能確保作業之間的資源調度公平？
- GPU Topology感知(GPU Topology Awareness)：一個常見的AI訓練和推理作業，爲了達到更高的性能，往往需要使用多個GPU共同完成，此時GPU的Topology結構以及設備之間的傳輸性能會對計算性能造成很大影響。目前, K8s提供的擴展資源調度機制還無法滿足調度時Topology感知的問題。
- 集羣自動配置(Cluster Configuration)：許多上層工具在業務啓動之前，需要用戶配置工具的集羣狀態，方便系統內部節點互通和識別，以MPI(Message Passing Interface)作業爲例，需要用戶以命令行參數“—host”配置集羣的所有節點信息，並且還依賴節點之間SSH互通。所以，用戶還要考慮怎樣自動配置和管理業務集羣。
此外，如何監控整個作業集羣的狀態？單個Pod失敗如何處理？怎麼解決任務依賴的問題等，都是需要處理的問題。
基於此，Volcano在解決此類問題的基礎上提供了一個針對BigData和AI場景下，通用、可擴展、高性能、穩定的原生批量計算平臺，方便以Kubeflow、KubeGene、Spark爲代表的上層業務組件集成和使用。
概述
如圖2所示，Volcano在K8s之上抽象了一個批量計算的通用基礎層，向下彌補K8s調度能力的不足，向上提供靈活通用的Job抽象。目前，該項目最重要的兩個組件分別是Volcano-Scheduler和Volcano-Controller。
Volcano-Scheduler：這個組件最開始來自社區的Scheduling SIG子項目項目Kube-Batch， 是一個可擴展的增強調度器，主要支持的能力有：
Actions:
- Allocate: 正常的資源分配動作。
- Preempt: 搶佔，當系統中存在高優先級作業，且系統資源無法滿足請求時，會觸發資源搶佔操作。
- Reclaim: 資源回收, Kube-Batch會使用隊列(queue)將資源按照比例分配，當系統中新增或移除隊列時，Reclaim會負責回收和重新分配資源到剩餘隊列中去。
Plugins:
- DRF: 即Domaint Resource Fairness, 目的是爲了確保在多種類型資源共存的環境下，儘可能滿足分配的公平原則，其理論最早來自於UC伯克利大學的論文《Dominant Resource Fairness: Fair Allocation of Multiple Resource Types》[5]。
- Conformance: 資源一致性，確保系統關鍵資源不被強制回收使用。
- Gang: 資源成組,確保作業內的成組Pod資源不被強制驅逐。
而Volcano-Scheduler在Kube-Batch的基礎上又更進一步，引入了更多領域性的動作和插件，包括BinPack、GPUShare、GPUTopoAware等。
Volcano-Controller：Volcano通過CRD的方式提供了通用靈活的Job抽象Volcano Job (batch.volcano.sh/jobs)，Controller則負責與Scheduler配合，管理Job的整個生命週期。主要功能包括:
- 自定義的Job資源: 跟K8s內置的Job(作業)資源相比，Volcano Job有了更多增強配置，比如: 任務配置，提交重試，最小調度資源數，作業優先級, 資源隊列等。
- Job生命週期管理: Volcano Controller會監控Job的創建，創建和管理對應的子資源(Pod, ConfigMap, Service)，刷新作業的進度概要，提供CLI方便用戶查看和管理作業資源等。
- 任務執行策略: 單個Job下面往往會關聯多個任務(Task)，而且任務之間可能存在相互依賴關係，Volcano Controller支持配置任務策略，方便異常情況下的任務間關聯性重試或終止。
- 擴展插件: 在提交作業、創建Pod等多個階段，Controller支持配置插件用來執行自定義的環境準備和清理的工作，比如常見的MPI作業，在提交前就需要配置SSH插件，用來完成Pod資源的SSH信息配置。
下面以一個MPI Job作業的YAML片段爲例，帶大家從整體上了解Job Controller的功能(擴展功能相關字段已添加註釋，方便理解)。
有了上面的介紹，回過頭來參照圖5梳理Volcano一次普通作業的執行流程也就很容易理解了。
-
用戶通過kubectl創建Volcano Job資源。
-
Volcano Controller監測到Job資源創建，校驗資源有效性，依據JobSpec創建依賴的Pod， Service， ConfigMap等資源，執行配置的插件。
-
Volcano Scheduler監聽Pod資源的創建，依據策略，完成Pod資源的調度和綁定。
-
Kubelet負責Pod資源的創建，業務開始執行。
-
Volcano Controller負責Job後續的生命週期管理(狀態監控，事件響應，資源清理等)。
調度效率
除去易用性和擴展性，在BigData和AI場景下，資源調度的效率(成功率)通常能有效減少業務的運行時間，提高底層硬件設備的使用率，從而降低使用成本，我們以Volcano Scheduler和原生Scheduler在Gang Scheduling的場景下做了一個簡單的TF Job 執行時間對比:
參考圖6發現，單個作業的執行環境，兩種執行方式在運行時間上並無明顯區別，但是當集羣中存在多個作業時，因爲原生Scheduler無法保證調度的成組性，直接導致極端的情況出現: 作業之間出現資源競爭，互相等待，上層業務無法正常運行，直至超時，此時的調度效率大打折扣。
社區和貢獻
Volcano項目目前還在不斷的發展壯大中，更多特性也在設計和開發階段，如果廣大開發者有興趣，歡迎隨時加入Slack討論，提問題給意見或者貢獻代碼。