摘要：Volcano主要是基於Kubernetes作的一個批處理系統，但願上層的HPC、中間層大數據的應用以及最下面一層AI可以在統一Kubernetes上面運行的更高效。
Volcano產生的背景
上圖是咱們作的一個分析，咱們將其分爲三層，最下面爲資源管理層，中間爲領域的框架，包括AI的體系、HPC、Batch， WKflow的管理以及像如今的一些微服務及流量治理等。再往上是行業以及一些行業的應用。node
隨着一些行業的應用變得複雜，它對所需求的解決方案也愈來愈高。舉個例子在10多年之前，在金融行業提供解決方案時，它的架構是很是簡單的，可能須要一個數據庫，一個ERP的中間件，就能夠解決銀行大部分的業務。算法
而如今，天天要收集大量的數據，它須要spark去作數據分析，甚至須要一些數據湖的產品去創建數據倉庫，而後去作分析，產生報表。同時它還會用 AI的一些系統，來簡化業務流程等。sql
所以，如今的一些行業應用與10年前比，變得很複雜，它可能會應用到下面這些領域框架裏面的一個或多個。其實對於行業應用，它的需求是在多個領域框架做爲一個融合，領域框架的訴求是下面的資源管理層可以提供統一的資源管理。數據庫
Kubernetes如今愈來愈多的承載了統一的資源管理的角色，它能夠爲 HPC這些行業領域框架提供服務，也能夠做爲大數據領域的資源管理層。Volcano主要是基於Kubernetes作的一個批處理系統，但願上層的HPC、中間層大數據的應用以及最下面一層AI可以在統一Kubernetes上面運行的更高效。api
Volcano要解決什麼樣的問題？
挑戰 1: 面向高性能負載的調度策略性能優化
e.g. fair-share, gang-scheduling
挑戰 2: 支持多種做業生命週期管理網絡
e.g. multiple pod template, error handling
挑戰 3: 支持多種異構硬件session
e.g. GPU, FPGA
挑戰 4: 面向高性能負載的性能優化架構
e.g. scalability, throughput, network, runtime
挑戰 5：支持資源管理及分時共享併發
e.g. Queue, Reclaim
Volcano架構體系
藍色部分是 K8s自己的組件，綠色的部分是Volcano新加的一些組件。
做業提交流程：
一、經過 Admission 後，kubectl 將在 kube-apiserver中建立 Job (Volcano CRD) 對像
二、JobController 根據 Job 的配置建立 相應的 Pods e.g. replicas
三、Pod及PodGroup建立 後，vc-scheduler 會到 kube-apiserver 獲取Pod/PodGroup 以及 node 信息
四、獲取信息後，vc-scheduler 將根據其配置的調度策略爲每個 Pod 選取合適節點
五、在爲Pod分配節點後，kubelet 將從kube-apiserver中取得Pod的配置，啓動相應的容器
須要強調的幾點：
vc-scheduler 中的調度策略都以插件的形式存在, e.g. DRF, Priority, Gang
vc-controllers 包含了 QueueController, JobController，PodGroupController 以及 gc-controller
vc-scheduler 不只能夠調度批量計算的做業，也能夠調度微服務做業；而且能夠經過 multi-scheduler 功能與 kube-scheduler 共存
部分組件介紹
Controller
左邊爲Volcano Job Controller，不僅調度使用的Volcano，Job的生命週期管理、做業管理都在這裏麪包含。咱們提供了統一的做業管理，你只要使用Volcano，也不須要建立各類各樣的操做，就能夠直接運行做業。
右邊爲CRD Job Controller，經過下面的PodGroup去作集成。
scheduler架構體系
Scheduler支持動態配置和加載。左邊爲apiserver,右邊爲整個Scheduler,apiserver裏有Job、Pod、Pod Group；Scheduler分爲三部分，第一層爲Cache,中間層爲整個調度的過程，右邊是以插件形式存在的調度算法。Cache會將apiserver裏建立的Pod、Pod Group這些信息存儲並加工爲Jobinfors。中間層的OpenSession會從Cache里拉取Pod、Pod Group，同時將右邊的算法插件一塊兒獲取，從而運行它的調度工做。
狀態之間根據不一樣的操做進行轉換，見下圖。
另外，咱們在Pod和Pod的狀態方面增長了不少狀態，圖中藍色部分爲K8s自帶的狀態；綠色部分是session級別的狀態，一個調度週期，咱們會建立一個session，它只在調度週期內發揮做用，一旦過了調度週期，這幾個狀態它是失效的；黃色部分的狀態是放在Cache內的。咱們加這些狀態的目的是減小調度和API之間的一個交互，從而來優化調度性能。
Pod的這些狀態爲調度器提供了更多優化的可能。例如，當進行Pod驅逐時，驅逐在Binding和Bound狀態的Pod要比較驅逐Running狀態的Pod的代價要小 (思考：還有其它狀態的Pod能夠驅逐嗎？)；而且狀態都是記錄在Volcano調度內部，減小了與kube-apiserver的通訊。但目前Volcano調度器僅使用了狀態的部分功能，好比如今的preemption/reclaim僅會驅逐Running狀態下的Pod；這主要是因爲分佈式系統中很難作到徹底的狀態同步，在驅逐Binding和Bound狀態的Pod會有不少的狀態競爭。
在功能上面能帶來哪些好處？
- 支持多種類型做業混合部署
- 支持多隊列用於多租戶資源共享，資源規劃；並分時複用資源
- 支持多種高級調度策略，有效提高整集羣資源利用率
- 支持資源實時監控，用於高精度資源調度，例如 熱點，網絡帶寬；容器引擎，網絡性能優化, e.g. 免加載
分佈式訓練場景：
Gang-scheduler
Case 1: 1 job with 2ps + 4workers
Case 2: 2 jobs with 2ps + 4workers
Case 3: 5 jobs with 2ps + 4workers
在Volcano和 kubeflow+kube-scheduler作對比，Case 1在資源充足的時候效果是差很少的；Case 2是在沒有足夠的資源的狀況下同時運行兩個做業，若是沒有 gang-scheduling，其中的一個做業會出現忙等 ；Case 3看成業數漲到5後，很大機率出現死鎖；通常只能完成2個做業。
IOAware
3個做業的執行時間總和; 每一個做業帶2ps + 4workers
默認調度器執行時間波動較大
執行時間的提升量依據數據在做業中的比例而定
減小 Pod Affinity/Anti-Affinity，提升調度器的總體性能
大數據場景
Spark-sql-perf (TP-DCS, master)
104 queries concurrently
(8cpu, 64G, 1600SSD) * 4nodes
Kubernetes 1.13
Driver: 1cpu,4G; Executor: (1cpu,4G)*5
若是沒有固定的driver節點，最多同時運行 26 條查詢語句
因爲Volcano提供了做業級的資源預留，整體性能提升了~30%
HPC場景
MPI on Volcano
規劃
GPU共享特性
1）算力優化：
- GPU硬件加速，TensorCore
- GPU共享
- 昇騰改造
2）調度算法優化：
Job/Task模型，提供AI類Job統一批量調度
多任務排隊，支持多租戶/部門共享集羣
單Job內多任務集羣中最優化親和性調度、Gang Scheduling等
主流的PS-Worker、Ring AllReduce等分佈式訓練模型
3）流程優化
- 容器鏡像
- CICD流程
- 日誌監控
Volcano能夠支持更大規模的一個集羣調度，咱們如今是1萬個節點百萬容器，調度的性能每秒達到2000個Pod。
1)編排：
Etcd 分庫分表，e.g. Event 放到單獨庫，wal/snapshot 單獨掛盤
經過一致性哈希分散處理，實現 controller-manager 多活
Kube-apiserver 基於工做負載的彈性擴容
2)調度：
經過 EquivalenceCache，算法剪枝 等技術提高單調度器的吞吐性能
經過共享資源視圖實現調度器多活，提高調度速率
3)網絡：
經過trunkport提高單節點容器密度及單集羣ENI容量
經過 Warm Pool 預申請網口，提高網口發放速度
基於eBPF/XDP 支持大規模、高度變化的雲原生應用網絡，e.g. Service, network policy
4)引擎：
containerd 併發 啓動優化
支持shimv2，提高單節點容器密度
鏡像下載加速 Lazy loading
Cromwell社區集成
Cromwell是一個流程調度軟件，它能夠定義不一樣的做業，這個軟件在基因測序以及基因計算領域裏應用是比較普遍的。
Cromwell 社區原生支持Volcano
企業版已經上線 華爲雲 GCS
經過 cromwell 支持做業依賴
Volcano 提供面向做業、數據依賴的調度
Volcano CLI
KubeSim
簡介：
集羣進行性能測試及調度的描述工具
不受資源限制，模擬大規模K8S集羣
完整的K8S API調用，不會真正建立pod
已經支持產品側大規模專項及調度專項的模擬工做
整體結構：
Worker cluster：承載kubemark虛擬節點，hollow pod
Master cluster：管理kubemark虛擬節點，hollow node
Hollow pod = hollow kubelet + hollow proxy
社區活躍度：
• 1.4k star，300+ fork，150+ 貢獻者
• 3 Maintainer，7 Reviewer
• 30 家企業、科研機構
目前使用Volcano的部分企業