這篇文章給大家介紹Volcano架構(gòu)設(shè)計與原理是什么，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

東明網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,東明網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為東明數(shù)千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的東明做網(wǎng)站的公司定做！

Volcano產(chǎn)生的背景

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

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

而現(xiàn)在，每天要收集大量的數(shù)據(jù)，它需要spark去做數(shù)據(jù)分析，甚至需要一些數(shù)據(jù)湖的產(chǎn)品去建立數(shù)據(jù)倉庫，然后去做分析，產(chǎn)生報表。同時它還會用 AI的一些系統(tǒng)，來簡化業(yè)務(wù)流程等。

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

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

Volcano要解決什么樣的問題？

挑戰(zhàn) 1: 面向高性能負載的調(diào)度策略

	e.g. fair-share, gang-scheduling

挑戰(zhàn) 2: 支持多種作業(yè)生命周期管理

	e.g. multiple pod template, error handling

挑戰(zhàn) 3: 支持多種異構(gòu)硬件

	e.g. GPU, FPGA

挑戰(zhàn) 4: 面向高性能負載的性能優(yōu)化

	e.g. scalability, throughput, network, runtime

挑戰(zhàn) 5：支持資源管理及分時共享

	e.g. Queue, Reclaim

Volcano架構(gòu)體系

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

作業(yè)提交流程：

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

2、JobController 根據(jù) Job 的配置創(chuàng)建 相應(yīng)的 Pods e.g. replicas

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

4、獲取信息后，vc-scheduler 將根據(jù)其配置的調(diào)度策略為每一個 Pod 選取合適節(jié)點

5、在為Pod分配節(jié)點后，kubelet 將從kube-apiserver中取得Pod的配置，啟動相應(yīng)的容器

需要強調(diào)的幾點：

vc-scheduler 中的調(diào)度策略都以插件的形式存在, e.g. DRF, Priority, Gang

vc-controllers 包含了 QueueController, JobController，PodGroupController 以及 gc-controller

vc-scheduler 不僅可以調(diào)度批量計算的作業(yè)，也可以調(diào)度微服務(wù)作業(yè)；并且可以通過 multi-scheduler 功能與 kube-scheduler 共存

部分組件介紹

Controller

左邊為Volcano Job Controller，不只調(diào)度使用的Volcano，Job的生命周期管理、作業(yè)管理都在這里面包含。我們提供了統(tǒng)一的作業(yè)管理，你只要使用Volcano，也不需要創(chuàng)建各種各樣的操作，就可以直接運行作業(yè)。

右邊為CRD Job Controller，通過下面的PodGroup去做集成。

scheduler架構(gòu)體系

Scheduler支持動態(tài)配置和加載。左邊為apiserver,右邊為整個Scheduler,apiserver里有Job、Pod、Pod Group；Scheduler分為三部分，第一層為Cache,中間層為整個調(diào)度的過程，右邊是以插件形式存在的調(diào)度算法。Cache會將apiserver里創(chuàng)建的Pod、Pod Group這些信息存儲并加工為Jobinfors。中間層的OpenSession會從Cache里拉取Pod、Pod Group，同時將右邊的算法插件一起獲取，從而運行它的調(diào)度工作。

狀態(tài)之間根據(jù)不同的操作進行轉(zhuǎn)換，見下圖。

另外，我們在Pod和Pod的狀態(tài)方面增加了很多狀態(tài)，圖中藍色部分為K8s自帶的狀態(tài)；綠色部分是session級別的狀態(tài)，一個調(diào)度周期，我們會創(chuàng)建一個session，它只在調(diào)度周期內(nèi)發(fā)揮作用，一旦過了調(diào)度周期，這幾個狀態(tài)它是失效的；黃色部分的狀態(tài)是放在Cache內(nèi)的。我們加這些狀態(tài)的目的是減少調(diào)度和API之間的一個交互，從而來優(yōu)化調(diào)度性能。

Pod的這些狀態(tài)為調(diào)度器提供了更多優(yōu)化的可能。例如，當(dāng)進行Pod驅(qū)逐時，驅(qū)逐在Binding和Bound狀態(tài)的Pod要比較驅(qū)逐Running狀態(tài)的Pod的代價要小 (思考：還有其它狀態(tài)的Pod可以驅(qū)逐嗎？)；并且狀態(tài)都是記錄在Volcano調(diào)度內(nèi)部，減少了與kube-apiserver的通信。但目前Volcano調(diào)度器僅使用了狀態(tài)的部分功能，比如現(xiàn)在的preemption/reclaim僅會驅(qū)逐Running狀態(tài)下的Pod；這主要是由于分布式系統(tǒng)中很難做到完全的狀態(tài)同步，在驅(qū)逐B(yǎng)inding和Bound狀態(tài)的Pod會有很多的狀態(tài)競爭。

在功能上面能帶來哪些好處？

1. 支持多種類型作業(yè)混合部署

2. 支持多隊列用于多租戶資源共享，資源規(guī)劃；并分時復(fù)用資源

3. 支持多種高級調(diào)度策略，有效提升整集群資源利用率

4. 支持資源實時監(jiān)控，用于高精度資源調(diào)度，例如 熱點，網(wǎng)絡(luò)帶寬；容器引擎，網(wǎng)絡(luò)性能優(yōu)化, e.g. 免加載

分布式訓(xùn)練場景：

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是在沒有足夠的資源的情況下同時運行兩個作業(yè)，如果沒有 gang-scheduling，其中的一個作業(yè)會出現(xiàn)忙等 ；Case 3當(dāng)作業(yè)數(shù)漲到5后，很大概率出現(xiàn)死鎖；一般只能完成2個作業(yè)。

IOAware

3個作業(yè)的執(zhí)行時間總和; 每個作業(yè)帶2ps + 4workers

默認調(diào)度器執(zhí)行時間波動較大

執(zhí)行時間的提高量依據(jù)數(shù)據(jù)在作業(yè)中的比例而定

減少 Pod Affinity/Anti-Affinity，提高調(diào)度器的整體性能

大數(shù)據(jù)場景

Spark-sql-perf (TP-DCS, master)

104 queries concurrently

(8cpu, 64G, 1600SSD) * 4nodes

Kubernetes 1.13

Driver: 1cpu,4G; Executor: (1cpu,4G)*5

如果沒有固定的driver節(jié)點，最多同時運行 26 條查詢語句

由于Volcano提供了作業(yè)級的資源預(yù)留，總體性能提高了~30%

HPC場景

MPI on Volcano

規(guī)劃

GPU共享特性

1）算力優(yōu)化：

• GPU硬件加速，TensorCore

• GPU共享

• 昇騰改造

2）調(diào)度算法優(yōu)化：

Job/Task模型，提供AI類Job統(tǒng)一批量調(diào)度

多任務(wù)排隊，支持多租戶/部門共享集群

單Job內(nèi)多任務(wù)集群中最優(yōu)化親和性調(diào)度、Gang Scheduling等

主流的PS-Worker、Ring AllReduce等分布式訓(xùn)練模型

3）流程優(yōu)化

• 容器鏡像

• CICD流程

• 日志監(jiān)控

Volcano可以支持更大規(guī)模的一個集群調(diào)度，我們現(xiàn)在是1萬個節(jié)點百萬容器，調(diào)度的性能每秒達到2000個Pod。

1)編排：

Etcd 分庫分表，e.g. Event 放到單獨庫，wal/snapshot 單獨掛盤

通過一致性哈希分散處理，實現(xiàn) controller-manager 多活

Kube-apiserver 基于工作負載的彈性擴容

2)調(diào)度：

通過 EquivalenceCache，算法剪枝 等技術(shù)提升單調(diào)度器的吞吐性能

通過共享資源視圖實現(xiàn)調(diào)度器多活，提升調(diào)度速率

3)網(wǎng)絡(luò)：

通過trunkport提升單節(jié)點容器密度及單集群ENI容量

通過 Warm Pool 預(yù)申請網(wǎng)口，提升網(wǎng)口發(fā)放速度

基于eBPF/XDP 支持大規(guī)模、高度變化的云原生應(yīng)用網(wǎng)絡(luò)，e.g. Service, network policy

4)引擎：

containerd 并發(fā) 啟動優(yōu)化

支持shimv2，提升單節(jié)點容器密度

鏡像下載加速 Lazy loading

Cromwell社區(qū)集成

Cromwell是一個流程調(diào)度軟件，它可以定義不同的作業(yè)，這個軟件在基因測序以及基因計算領(lǐng)域里應(yīng)用是比較廣泛的。

Cromwell 社區(qū)原生支持Volcano

企業(yè)版已經(jīng)上線 華為云 GCS

通過 cromwell 支持作業(yè)依賴

Volcano 提供面向作業(yè)、數(shù)據(jù)依賴的調(diào)度

Volcano CLI

KubeSim

簡介：

集群進行性能測試及調(diào)度的描述工具

不受資源限制，模擬大規(guī)模K8S集群

完整的K8S API調(diào)用，不會真正創(chuàng)建pod

已經(jīng)支持產(chǎn)品側(cè)大規(guī)模專項及調(diào)度專項的模擬工作

總體結(jié)構(gòu)：

Worker cluster：承載kubemark虛擬節(jié)點，hollow pod

Master cluster：管理kubemark虛擬節(jié)點，hollow node

Hollow pod = hollow kubelet + hollow proxy

關(guān)于Volcano架構(gòu)設(shè)計與原理是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。