GitHub:?GitHub - volcano-sh/volcano: A Kubernetes Native Batch System (Project under CNCF)
官網：Volcano
背景：
原生k8s對高性能應用場景的支持度較差，為支持TensorFlow、Spark适瓦、MindSpore等多個領域框架乔妈，Volcano作為容器調度系統(tǒng)努溃，不僅包括了作業(yè)調度册招，還包含了作業(yè)生命周期管理、多集群調度漾月、命令行根时、數據管理瘦赫、作業(yè)視圖及硬件加速等功能。
HPW 的常見調度場景 :
?Batch scheduling 例如：
????gang-scheduling?
? ? ? 運行批處理作業(yè)（如Tensorflow/MPI）時蛤迎，必須協(xié)調作業(yè)的所有任務才能一起啟動确虱；否則，將不會啟動任何任務替裆。如果有足夠的資源并行運行作業(yè)的所有任務校辩，則該作業(yè)將正確執(zhí)行； 但是辆童，在大多數情況下召川，尤其是在prem環(huán)境中，情況并非如此胸遇。在最壞的情況下，由于死鎖汉形，所有作業(yè)都掛起纸镊。其中每個作業(yè)只成功啟動了部分任務倍阐，并等待其余任務啟動。
? ? job-based fair-share
? ? ? 當運行多個彈性作業(yè)（如流媒體）時逗威，需要公平地為每個作業(yè)分配資源峰搪，以滿足多個作業(yè)競爭附加資源時的SLA/QoS要求。在最壞的情況下凯旭，單個作業(yè)可能會啟動大量的pod資源利用率低概耻， 從而阻止其他作業(yè)由于資源不足而運行。為了避免分配過泄藓簟（例如鞠柄，為每個作業(yè)啟動一個Pod），彈性作業(yè)可以利用協(xié)同調度來定義應該啟動的Pod的最小可用數量嫉柴。 超過指定的最小可用量的任何pod都將公平地與其他作業(yè)共享集群資源厌杜。
Enhanced job management, e.g. multiple pod template, job dependency, job lifecycle management
Alternative container runtime, e.g. Singularity
Enhancement for heterogeneous computing
Enhancement for high performance workload, e.g. performance, throughput
? ? Queue 隊列
? ? ? 隊列還廣泛用于共享彈性工作負載和批處理工作負載的資源。隊列的主要目的是：
? ? ? ? ? ?1 在不同的“租戶”或資源池之間共享資源
? ? ? ? ? ?2 為不同的“租戶”或資源池支持不同的調度策略或算法
? ? ? ?這些功能可以通過層次隊列進一步擴展计螺，在層次隊列中夯尽，項目被賦予額外的優(yōu)先級，這將允許它們比隊列中的其他項目“跳轉”登馒。在kube批處理中匙握，隊列被實現(xiàn)為集群范圍的CRD。 這允許將在不同命名空間中創(chuàng)建的作業(yè)放置在共享隊列中陈轿。隊列資源根據其隊列配置（kube batch#590）按比例劃分圈纺。當前不支持分層隊列，但正在進行開發(fā)济欢。
? ? ? ?集群應該能夠在不減慢任何操作的情況下處理隊列中的大量作業(yè)赠堵。其他的HPC系統(tǒng)可以處理成百上千個作業(yè)的隊列，并隨著時間的推移緩慢地處理它們法褥。如何與庫伯內特斯達成這樣的行為是一個懸而未決的問題茫叭。支持跨越多個集群的隊列可能也很有用，在這種情況下半等，這是一個關于數據應該放在哪里以及etcd是否適合存儲隊列中的所有作業(yè)或pod的問題揍愁。
? ? 面向用戶的, 跨隊列的公平調度 (Namespace-based fair-share Cross Queue)
? ? ? ? 在隊列中，每個作業(yè)在調度循環(huán)期間有幾乎相等的調度機會杀饵，這意味著擁有更多作業(yè)的用戶有更大的機會安排他們的作業(yè)莽囤，這對其他用戶不公平。 例如切距，有一個隊列包含少量資源朽缎，有10個pod屬于UserA，1000個pod屬于UserB。在這種情況下话肖，UserA的pod被綁定到節(jié)點的概率較小北秽。
? ? ? ? ?為了平衡同一隊列中用戶之間的資源使用，需要更細粒度的策略最筒『孛ィ考慮到Kubernetes中的多用戶模型，使用名稱空間來區(qū)分不同的用戶床蜘， 每個命名空間都將配置一個權重辙培，作為控制其資源使用優(yōu)先級的手段。
????基于時間的公平調度 (Fairness over time)
????????對于批處理工作負載邢锯，通常不要求在某個時間點公平地分配資源扬蕊，而是要求在長期內公平地分配資源。例如弹囚，如果有用戶提交大作業(yè)厨相，則允許用戶（或特定隊列）在一定時間內使用整個集群的一半， 這是可以接受的鸥鹉，但在下一輪調度（可能是作業(yè)完成后數小時）中蛮穿，應懲罰此用戶（或隊列）而不是其他用戶（或隊列）。在 HTCondor 中可以看到如何實現(xiàn)這種行為的好例子毁渗。
????面向作業(yè)的優(yōu)先級調度 (Job-based priority)
????????Pod優(yōu)先級/搶占在1.14版本中被中斷践磅，它有助于確保高優(yōu)先級的pod在低優(yōu)先級的pod之前綁定。不過灸异，在job/podgroup級別的優(yōu)先級上仍有一些工作要做府适，例如高優(yōu)先級job/podgroup應該嘗試以較低優(yōu)先級搶占整個job/podgroup，而不是從不同job/podgroup搶占幾個pod肺樟。
????搶占 (Preemption & Reclaim)
????????通過公平分享來支持借貸模型檐春，一些作業(yè)/隊列在空閑時會過度使用資源。但是么伯，如果有任何進一步的資源請求疟暖，資源“所有者”將“收回”。 資源可以在隊列或作業(yè)之間共享：回收用于隊列之間的資源平衡田柔，搶占用于作業(yè)之間的資源平衡俐巴。
????預留與回填 (Reservation & Backfill)
????????當一個請求大量資源的“巨大”作業(yè)提交給kubernetes時，當有許多小作業(yè)在管道中時硬爆，該作業(yè)可能會餓死欣舵，并最終根據當前的調度策略/算法被殺死。為了避免饑餓缀磕， 應該有條件地為作業(yè)保留資源缘圈，例如超時劣光。當資源被保留時，它們可能會處于空閑和未使用狀態(tài)糟把。為了提高資源利用率赎线，調度程序將有條件地將“較小”作業(yè)回填到那些保留資源中。 保留和回填都是根據插件的反饋觸發(fā)的：volcano調度器提供了幾個回調接口糊饱，供開發(fā)人員或用戶決定哪些作業(yè)應該被填充或保留。
Volcano重要組件??
華為云Volcano：讓企業(yè)AI算力像火山一樣爆發(fā)_華為云官方博客-CSDN博客_華為火山
? Volcano-Scheduler
? ? ? Volcano-Scheduler在Kube-Batch的基礎上颠黎，又更進一步另锋，引入了更多領域性的動作和插件，包括BinPack狭归，GPUShare夭坪，GPUTopoAware等。
? ? ?關于kube-batch过椎，詳見
? Volcano-Controller
Volcano通過CRD的方式提供了通用靈活的Job抽象Volcano Job (batch.volcano.sh/jobs), Controller則負責跟Scheduler配合室梅，管理Job的整個生命周期。主要功能包括:
①: 自定義的Job資源: 跟K8s內置的Job(作業(yè))資源相比疚宇，Volcano Job有了更多增強配置亡鼠，比如：任務配置，提交重試敷待，最小調度資源數间涵，作業(yè)優(yōu)先級, 資源隊列等。
②: Job生命周期管理: Volcano Controller會監(jiān)控Job的創(chuàng)建榜揖，創(chuàng)建和管理對應的子資源(Pod, ConfigMap, Service)勾哩，刷新作業(yè)的進度概要，提供CLI方便用戶查看和管理作業(yè)資源等举哟。
③: 任務執(zhí)行策略: 單個Job下面往往會關聯(lián)多個任務(Task)思劳，而且任務之間可能存在相互依賴關系，Volcano Controller支持配置任務策略妨猩，方便異常情況下的任務間關聯(lián)性重試或終止潜叛。
④: 擴展插件: 在提交作業(yè)、創(chuàng)建Pod等多個階段册赛，Controller支持配置插件用來執(zhí)行自定義的環(huán)境準備和清理的工作钠导，比如常見的MPI作業(yè)，在提交前就需要配置SSH插件森瘪，用來完成Pod資源的SSH信息配置牡属。
job管理
Volcano中job管理 - 簡書?中文文檔
