Volcano架構設計與原理解讀

Volcano產生的背景

上圖是我們做的一個分析，我們將其分為三層，最下面為資源管理層，中間為領域的框架，包括AI的體系、HPC、Batch， WKflow的管理以及像現在的一些微服務及流量治理等。再往上是行業以及一些行業的應用。

隨著一些行業的應用變得復雜，它對所需求的解決方案也越來越高。舉個例子在10多年以前，在金融行業提供解決方案時，它的架構是非常簡單的，可能需要一個數據庫，一個ERP的中間件，就可以解決銀行大部分的業務。

而現在，每天要收集大量的數據，它需要spark去做數據分析，甚至需要一些數據湖的產品去建立數據倉庫，然后去做分析，產生報表。同時它還會用 AI的一些系統，來簡化業務流程等。

因此，現在的一些行業應用與10年前比，變得很復雜，它可能會應用到下面這些領域框架里面的一個或多個。其實對于行業應用，它的需求是在多個領域框架作為一個融合，領域框架的訴求是下面的資源管理層能夠提供統一的資源管理。

Kubernetes現在越來越多的承載了統一的資源管理的角色，它可以為 HPC這些行業領域框架提供服務，也可以作為大數據領域的資源管理層。Volcano主要是基于Kubernetes做的一個批處理系統，希望上層的HPC、中間層大數據的應用以及最下面一層AI能夠在統一Kubernetes上面運行的更高效。

Volcano要解決什么樣的問題？

挑戰 1: 面向高性能負載的調度策略

e.g. fair-share, gang-scheduling

挑戰 2: 支持多種作業生命周期管理

e.g. multiple pod template, error handling

挑戰 3: 支持多種異構硬件

e.g. GPU, FPGA

挑戰 4: 面向高性能負載的性能優化

e.g. scalability, throughput, network, runtime

挑戰 5：支持資源管理及分時共享

e.g. Queue, Reclaim

Volcano架構體系

藍色部分是 K8s本身的組件，綠色的部分是Volcano新加的一些組件。

作業提交流程：

1、通過 Admission 后，kubectl 將在 kube-apiserver中創建 Job (Volcano CRD) 對像

2、JobController 根據 Job 的配置創建 相應的 Pods e.g. replicas

3、Pod及PodGroup創建 后，vc-scheduler 會到 kube-apiserver 獲取Pod/PodGroup 以及 node 信息

4、獲取信息后，vc-scheduler 將根據其配置的調度策略為每一個 Pod 選取合適節點

5、在為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的部分企業

AI 架構設計

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。