进击的 Kubernetes 调度系统（二）：支持批任务的 Coscheduling/Gang scheduling
作者 | 王慶璨（阿里云技術(shù)專家）、張凱（阿里云高級(jí)技術(shù)專家）
**導(dǎo)讀：**阿里云容器服務(wù)團(tuán)隊(duì)結(jié)合多年 Kubernetes 產(chǎn)品與客戶支持經(jīng)驗(yàn)，對(duì) Kube-scheduler 進(jìn)行了大量?jī)?yōu)化和擴(kuò)展，逐步使其在不同場(chǎng)景下依然能穩(wěn)定、高效地調(diào)度各種類型的復(fù)雜工作負(fù)載。《進(jìn)擊的 Kubernetes 調(diào)度系統(tǒng)》系列文章將把我們的經(jīng)驗(yàn)、技術(shù)思考和實(shí)現(xiàn)細(xì)節(jié)全面地展現(xiàn)給 Kubernetes 用戶和開發(fā)者，期望幫助大家更好地了解 Kubernetes 調(diào)度系統(tǒng)的強(qiáng)大能力和未來(lái)發(fā)展方向。本文為該系列文章的第二篇。
前言
什么是 Coscheduling 和 Gang scheduling。Wikipedia 對(duì) Coscheduling 的定義是“在并發(fā)系統(tǒng)中將多個(gè)相關(guān)聯(lián)的進(jìn)程調(diào)度到不同處理器上同時(shí)運(yùn)行的策略”。在 Coscheduling 的場(chǎng)景中，最主要的原則是保證所有相關(guān)聯(lián)的進(jìn)程能夠同時(shí)啟動(dòng)。防止部分進(jìn)程的異常，導(dǎo)致整個(gè)關(guān)聯(lián)進(jìn)程組的阻塞。這種導(dǎo)致阻塞的部分異常進(jìn)程，稱之為“碎片（fragement）”。
在 Coscheduling 的具體實(shí)現(xiàn)過(guò)程中，根據(jù)是否允許“碎片”存在，可以細(xì)分為 Explicit Coscheduling，Local Coscheduling 和 Implicit Coscheduling。 其中 Explicit Coscheduling 就是大家常聽(tīng)到的 Gang Scheduling。Gang Scheduling 要求完全不允許有“碎片”存在， 也就是“All or Nothing”。
我們將上述定義的概念對(duì)應(yīng)到 Kubernetes 中，就可以理解 Kubernetes 調(diào)度系統(tǒng)支持批任務(wù) Coscheduling 的含義了。 一個(gè)批任務(wù)（關(guān)聯(lián)進(jìn)程組）包括了 N 個(gè) Pod（進(jìn)程），Kubernetes 調(diào)度器負(fù)責(zé)將這 N 個(gè) Pod 調(diào)度到 M 個(gè)節(jié)點(diǎn)（處理器）上同時(shí)運(yùn)行。如果這個(gè)批任務(wù)需要部分 Pod 同時(shí)啟動(dòng)即可運(yùn)行，我們稱需啟動(dòng) Pod 的最小數(shù)量為 min-available。特別地，當(dāng) min-available=N 時(shí)，批任務(wù)要求滿足 Gang Scheduling。
為什么 Kubernetes 調(diào)度系統(tǒng)需要 Coscheduling？
Kubernetes 目前已經(jīng)廣泛的應(yīng)用于在線服務(wù)編排，為了提升集群的的利用率和運(yùn)行效率，我們希望將 Kubernetes 作為一個(gè)統(tǒng)一的管理平臺(tái)來(lái)管理在線服務(wù)和離線作業(yè)。默認(rèn)的調(diào)度器是以 Pod 為調(diào)度單元進(jìn)行依次調(diào)度，不會(huì)考慮 Pod 之間的相互關(guān)系。但是很多數(shù)據(jù)計(jì)算類的離線作業(yè)具有組合調(diào)度的特點(diǎn)，即要求所有的子任務(wù)都能夠成功創(chuàng)建后，整個(gè)作業(yè)才能正常運(yùn)行。如果只有部分子任務(wù)啟動(dòng)的話，啟動(dòng)的子任務(wù)將持續(xù)等待剩余的子任務(wù)被調(diào)度。這正是 Gang Scheduling 的場(chǎng)景。
如下圖所示，JobA 需要 4 個(gè) Pod 同時(shí)啟動(dòng)，才能正常運(yùn)行。Kube-scheduler 依次調(diào)度 3 個(gè) Pod 并創(chuàng)建成功。到第 4 個(gè) Pod 時(shí)，集群資源不足，則 JobA 的 3 個(gè) Pod 處于空等的狀態(tài)。但是它們已經(jīng)占用了部分資源，如果第 4 個(gè) Pod 不能及時(shí)啟動(dòng)的話，整個(gè) JobA 無(wú)法成功運(yùn)行，更糟糕的是導(dǎo)致集群資源浪費(fèi)。
如果出現(xiàn)更壞的情況的話，如下圖所示，集群其他的資源剛好被 JobB 的 3 個(gè) Pod 所占用，同時(shí)在等待 JobB 的第 4 個(gè) Pod 創(chuàng)建，此時(shí)整個(gè)集群就出現(xiàn)了死鎖。
社區(qū)相關(guān)的方案
社區(qū)目前有 Kube-batch 以及基于 Kube-batch 衍生的 Volcano 2 個(gè)項(xiàng)目來(lái)解決上文中提到的痛點(diǎn)。實(shí)現(xiàn)的方式是通過(guò)開發(fā)新的調(diào)度器將 Scheduler 中的調(diào)度單元從 Pod 修改為 PodGroup，以組的形式進(jìn)行調(diào)度。使用方式是如果需要 Coscheduling 功能的 Pod 走新的調(diào)度器，其他的例如在線服務(wù)的 Pod 走 Kube-scheduler 進(jìn)行調(diào)度。
這些方案雖然能夠解決 Coscheduling 的問(wèn)題，但是同樣引入了新的問(wèn)題。如大家所知，對(duì)于同一集群資源，調(diào)度器需要中心化。但如果同時(shí)存在兩個(gè)調(diào)度器的話，有可能會(huì)出現(xiàn)決策沖突，例如分別將同一塊資源分配給兩個(gè)不同的 Pod，導(dǎo)致某個(gè) Pod 調(diào)度到節(jié)點(diǎn)后因?yàn)橘Y源不足，導(dǎo)致無(wú)法創(chuàng)建的問(wèn)題。解決的方式只能是通過(guò)標(biāo)簽的形式將節(jié)點(diǎn)強(qiáng)行的劃分開來(lái)，或者部署多個(gè)集群。這種方式通過(guò)同一個(gè) Kubernetes 集群來(lái)同時(shí)運(yùn)行在線服務(wù)和離線作業(yè)，勢(shì)必會(huì)導(dǎo)致整體集群資源的浪費(fèi)以及運(yùn)維成本的增加。再者，Volcano 運(yùn)行需要啟動(dòng)定制的 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。這些 Webhooks 本身存在單點(diǎn)風(fēng)險(xiǎn)，一旦出現(xiàn)故障，將影響集群內(nèi)所有 pod 的創(chuàng)建。另外，多運(yùn)行一套調(diào)度器，本身也會(huì)帶來(lái)維護(hù)上的復(fù)雜性，以及與上游 Kube-scheduler 接口兼容上的不確定性。
基于 Scheduling Framework 的方案
《進(jìn)擊的 Kubernetes 調(diào)度系統(tǒng) （一）：Scheduling Framework?》介紹了 Kubernetes Scheduling Framework 的架構(gòu)原理和開發(fā)方法。在此基礎(chǔ)上，我們擴(kuò)展實(shí)現(xiàn)了 Coscheduling 調(diào)度插件，幫助 Kubernetes 原生調(diào)度器支持批作業(yè)調(diào)度，同時(shí)避免上述方案存在的問(wèn)題。Scheduling framework 的內(nèi)容在前一篇文章詳細(xì)介紹，歡迎大家翻閱。
Kubernetes 負(fù)責(zé) Kube-scheduler 的小組 sig-scheduler 為了更好的管理調(diào)度相關(guān)的 Plugin，新建了項(xiàng)目 scheduler-plugins 管理不同場(chǎng)景的 Plugin。我們基于 scheduling framework 實(shí)現(xiàn)的 Coscheduling Plugin 成為該項(xiàng)目的第一個(gè)官方插件，下面我將詳細(xì)的介紹 Coscheduling Plugin 的實(shí)現(xiàn)和使用方式。
技術(shù)方案
總體架構(gòu)
PodGroup
我們通過(guò) label 的形式來(lái)定義 PodGroup 的概念，擁有同樣 label 的 Pod 同屬于一個(gè) PodGroup。min-available 是用來(lái)標(biāo)識(shí)該 PodGroup 的作業(yè)能夠正式運(yùn)行時(shí)所需要的最小副本數(shù)。
labels:pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpupod-group.scheduling.sigs.k8s.io/min-available: "2"備注: 要求屬于同一個(gè) PodGroup 的 Pod 必須保持相同的優(yōu)先級(jí)
Permit
Framework 的 Permit 插件提供了延遲綁定的功能，即 Pod 進(jìn)入到 Permit 階段時(shí)，用戶可以自定義條件來(lái)允許 Pod 通過(guò)、拒絕 Pod 通過(guò)以及讓 Pod 等待狀態(tài) (可設(shè)置超時(shí)時(shí)間)。Permit 的延遲綁定的功能，剛好可以讓屬于同一個(gè) PodGruop 的 Pod 調(diào)度到這個(gè)節(jié)點(diǎn)時(shí)，進(jìn)行等待，等待積累的 Pod 數(shù)目滿足足夠的數(shù)目時(shí)，再統(tǒng)一運(yùn)行同一個(gè) PodGruop 的所有 Pod 進(jìn)行綁定并創(chuàng)建。
舉個(gè)實(shí)際的例子，當(dāng) JobA 調(diào)度時(shí)，需要 4 個(gè) Pod 同時(shí)啟動(dòng)，才能正常運(yùn)行。但此時(shí)集群僅能滿足 3 個(gè) Pod 創(chuàng)建，此時(shí)與 Default Scheduler 不同的是，并不是直接將 3 個(gè) Pod 調(diào)度并創(chuàng)建。而是通過(guò) Framework 的 Permit 機(jī)制進(jìn)行等待。
此時(shí)當(dāng)集群中有空閑資源被釋放后，JobA 的中 Pod 所需要的資源均可以滿足。
則 JobA 的 4 個(gè) Pod 被一起調(diào)度創(chuàng)建出來(lái)，正常運(yùn)行任務(wù)。
QueueSort
由于 Default Scheduler 的隊(duì)列并不能感知 PodGroup 的信息，所以 Pod 在出隊(duì)時(shí)處于無(wú)序性 (針對(duì) PodGroup 而言)。如下圖所示，a 和 b 表示兩個(gè)不同的 PodGroup，兩個(gè) PodGroup 的 Pod 在進(jìn)入隊(duì)列時(shí)，由于創(chuàng)建的時(shí)間交錯(cuò)導(dǎo)致在隊(duì)列中以交錯(cuò)的順序排列。
當(dāng)一個(gè)新的 Pod 創(chuàng)建后，入隊(duì)后，無(wú)法跟與其相同的 PodGroup 的 Pod 排列在一起，只能繼續(xù)以混亂的形式交錯(cuò)排列。
這種無(wú)序性就會(huì)導(dǎo)致如果 PodGroupA 在 Permit 階段處于等待狀態(tài)，此時(shí) PodGroupB 的 Pod 調(diào)度完成后也處于等待狀態(tài)，相互占有資源使得 PodGroupA 和 PodGroupB 均無(wú)法正常調(diào)度。這種情況即是把死鎖現(xiàn)象出現(xiàn)的位置從 Node 節(jié)點(diǎn)移動(dòng)到 Permit 階段，無(wú)法解決前文提到的問(wèn)題。
針對(duì)如上所示的問(wèn)題，我們通過(guò)實(shí)現(xiàn) QueueSort 插件， 保證在隊(duì)列中屬于同一個(gè) PodGroup 的 Pod 能夠排列在一起。我們通過(guò)定義 QueueSort 所用的 Less 方法，作用于 Pod 在入隊(duì)后排隊(duì)的順序：
func Less(podA *PodInfo, podB *PodInfo) bool首先，繼承了默認(rèn)的基于優(yōu)先級(jí)的比較方式，高優(yōu)先級(jí)的 Pod 會(huì)排在低優(yōu)先級(jí)的 Pod 之前。
然后，如果兩個(gè) Pod 的優(yōu)先級(jí)相同，我們定義了新的排隊(duì)邏輯來(lái)支持 PodGroup 的排序。
- 如果兩個(gè) Pod 都是 regularPod(普通的 Pod)，則誰(shuí)先創(chuàng)建誰(shuí)在隊(duì)列里邊排在前邊；
- 如果兩個(gè) Pod 一個(gè)是 regularPod，另一個(gè)是 pgPod(屬于某個(gè) PodGroup 的 Pod), 我們比較的是 regularPod 的創(chuàng)建時(shí)間和 pgPod 所屬 PodGroup 的創(chuàng)建時(shí)間，則誰(shuí)先創(chuàng)建誰(shuí)在隊(duì)列里邊排在前邊；
- 如果兩個(gè) Pod 都是 pgPod，我們比較兩個(gè) PodGroup 的創(chuàng)建時(shí)間，則誰(shuí)先創(chuàng)建誰(shuí)在隊(duì)列里邊排在前邊。同時(shí)有可能兩個(gè) PodGroup 的創(chuàng)建時(shí)間相同，我們引入了自增 Id，使得 PodGroup 的 Id 誰(shuí)小誰(shuí)排在前邊 (此處的目的是為了區(qū)分不同的 PodGroup)。
通過(guò)如上的排隊(duì)策略，我們實(shí)現(xiàn)屬于同一個(gè) PodGroup 的 Pod 能夠同一個(gè) PodGroup 的 Pod 能夠排列在一起。
當(dāng)一個(gè)新的 Pod 創(chuàng)建后，入隊(duì)后，會(huì)跟與其相同的 PodGroup 的 Pod 排列在一起。
Prefilter
為了減少無(wú)效的調(diào)度操作，提升調(diào)度的性能，我們?cè)?Prefilter 階段增加一個(gè)過(guò)濾條件，當(dāng)一個(gè) Pod 調(diào)度時(shí)，會(huì)計(jì)算該 Pod 所屬 PodGroup 的 Pod 的 Sum(包括 Running 狀態(tài)的)，如果 Sum 小于 min-available 時(shí)，則肯定無(wú)法滿足 min-available 的要求，則直接在 Prefilter 階段拒絕掉，不再進(jìn)入調(diào)度的主流程。
UnReserve
如果某個(gè) Pod 在 Permit 階段等待超時(shí)了，則會(huì)進(jìn)入到 UnReserve 階段，我們會(huì)直接拒絕掉所有跟 Pod 屬于同一個(gè) PodGroup 的 Pod，避免剩余的 Pod 進(jìn)行長(zhǎng)時(shí)間的無(wú)效等待。
Coscheduling 試用
安裝部署
用戶既可以在自己搭建的 Kubernetes 集群中，也可以在任一個(gè)公有云提供的標(biāo)準(zhǔn) Kubernetes 服務(wù)中來(lái)試用 Coscheduling。需要注意的是集群版本 1.16+， 以及擁有更新集群 master 的權(quán)限。
本文將使用 阿里云容器服務(wù) ACK 提供的 Kubernetes 集群來(lái)進(jìn)行測(cè)試。
前提條件
- 支持 Kubernetes 1.16 以上版本
- 選擇創(chuàng)建 ACK 提供的標(biāo)準(zhǔn)專有集群（Dedicated cluster）
- 保證集群節(jié)點(diǎn)可以訪問(wèn)公網(wǎng)
- helm v3：ACK 在 master 節(jié)點(diǎn)上默認(rèn)安裝 helm，請(qǐng)確認(rèn)版本是否為 helm v3，如果是 helm v2 請(qǐng)升級(jí)值 helm v3，安裝 helm v3 請(qǐng)參考 helm v3 安裝。
部署 Coscheduling
我們已經(jīng)將 Coscheduling 插件和原生調(diào)度器代碼統(tǒng)一構(gòu)建成新的容器鏡像。并提供了一個(gè) helm chart 包 ack-coscheduling 來(lái)自動(dòng)安裝。它會(huì)啟動(dòng)一個(gè)任務(wù)，自動(dòng)用 Coscheduling scheduler 替換集群默認(rèn)安裝的原生 scheduler，并且會(huì)修改 scheduler 的相關(guān) Config 文件，使 scheduling framework 正確地加載 Coscheduling 插件。完成試用后，用戶可通過(guò)下文提示的卸載功能恢復(fù)集群默認(rèn) scheduler 及相關(guān)配置。
下載 helm chart 包，執(zhí)行命令安裝：
$ wget http://kubeflow.oss-cn-beijing.aliyuncs.com/ack-coscheduling.tar.gz $ tar zxvf ack-coscheduling.tar.gz $ helm install ack-coscheduling -n kube-system ./ack-coscheduling NAME: ack-coscheduling LAST DEPLOYED: Mon Apr 13 16:03:57 2020 NAMESPACE: kube-system STATUS: deployed REVISION: 1 TEST SUITE: None驗(yàn)證 Coscheduling
在 Master 節(jié)點(diǎn)上，使用 helm 命令驗(yàn)證是否安裝成功。
$ helm get manifest ack-coscheduling -n kube-system | kubectl get -n kube-system -f - NAME COMPLETIONS DURATION AGE scheduler-update-clusterrole 1/1 8s 35s scheduler-update 3/1 of 3 8s 35s卸載 Coscheduling
通過(guò) helm 卸載，將 kube-scheduler 的版本及配置回滾到集群默認(rèn)的狀態(tài)。
$ helm uninstall ack-coscheduling -n kube-system使用方式
使用 Coscheduling 時(shí)，只需要在創(chuàng)建任務(wù)的 yaml 描述中配置 pod-group.scheduling.sigs.k8s.io/name 和 pod-group.scheduling.sigs.k8s.io/min-available 這兩個(gè) label 即可。
labels:pod-group.scheduling.sigs.k8s.io/name: tf-smoke-gpupod-group.scheduling.sigs.k8s.io/min-available: "3"- pod-group.scheduling.sigs.k8s.io/name：用于表示 PodGroup 的 Name；
- pod-group.scheduling.sigs.k8s.io/min-available: 用于表示當(dāng)前集群資源至少滿足 min-available 個(gè) pod 啟動(dòng)時(shí)，才能整體調(diào)度該任務(wù)。
備注: 屬于同一個(gè) PodGroup 的 Pod 必須保持相同的優(yōu)先級(jí)。
Demo 展示
接下來(lái)我們通過(guò)運(yùn)行 Tensorflow 的分布式訓(xùn)練作業(yè)來(lái)演示 Coscheduling 的效果。當(dāng)前測(cè)試集群有 4 個(gè) GPU 卡
- 通過(guò) Kubeflow 的 Arena 工具在已有 Kubernetes 集群中部署 Tensorflow 作業(yè)運(yùn)行環(huán)境。
Arena 是基于 Kubernetes 的機(jī)器學(xué)習(xí)系統(tǒng)開源社區(qū) Kubeflow 中的子項(xiàng)目之一。Arena 用命令行和 SDK 的形式支持了機(jī)器學(xué)習(xí)任務(wù)的主要生命周期管理（包括環(huán)境安裝，數(shù)據(jù)準(zhǔn)備，到模型開發(fā)，模型訓(xùn)練，模型預(yù)測(cè)等），有效提升了數(shù)據(jù)科學(xué)家工作效率。
git clone https://github.com/kubeflow/arena.git kubectl create ns arena-system kubectl create -f arena/kubernetes-artifacts/jobmon/jobmon-role.yaml kubectl create -f arena/kubernetes-artifacts/tf-operator/tf-crd.yaml kubectl create -f arena/kubernetes-artifacts/tf-operator/tf-operator.yaml檢查是否部署成功：
$ kubectl get pods -n arena-system NAME READY STATUS RESTARTS AGE tf-job-dashboard-56cf48874f-gwlhv 1/1 Running 0 54s tf-job-operator-66494d88fd-snm9m 1/1 Running 0 54s- 用戶向集群中提交 Tensorflow 作業(yè) (TFJob)，如下示例，包含 1 個(gè) Parameter Server pod 和 4 個(gè) Worker pod，每個(gè) Worker 需要 2 個(gè) GPU。配置了 pod group，需要至少 5 個(gè) pod 啟動(dòng)后才能運(yùn)行。
- 當(dāng)用戶不使用 Coscheduling 功能時(shí)
刪除上述 TFJob yaml 中的 pod-group.scheduling.sigs.k8s.io/name 和 pod-group.scheduling.sigs.k8s.io/min-available 標(biāo)簽，表示該任務(wù)不使用 Coscheduling。創(chuàng)建任務(wù)后，集群資源只能滿足 2 個(gè) Worker 啟動(dòng)，剩余兩個(gè)處于 Pending 狀態(tài)。
$ kubectl get pods NAME READY STATUS RESTARTS AGE tf-smoke-gpu-ps-0 1/1 Running 0 6m43s tf-smoke-gpu-worker-0 1/1 Running 0 6m43s tf-smoke-gpu-worker-1 1/1 Running 0 6m43s tf-smoke-gpu-worker-2 0/1 Pending 0 6m43s tf-smoke-gpu-worker-3 0/1 Pending 0 6m43s查看其中正在運(yùn)行的 Worker 的日志，都處于等待剩余那兩個(gè) Worker 啟動(dòng)的狀態(tài)。此時(shí)，4 個(gè) GPU 都被占用卻沒(méi)有實(shí)際執(zhí)行任務(wù)。
$ kubectl logs -f tf-smoke-gpu-worker-0 INFO|2020-05-19T07:02:18|/opt/launcher.py|27| 2020-05-19 07:02:18.199696: I tensorflow/core/distributed_runtime/master.cc:221] CreateSession still waiting for response from worker: /job:worker/replica:0/task:3 INFO|2020-05-19T07:02:28|/opt/launcher.py|27| 2020-05-19 07:02:28.199798: I tensorflow/core/distributed_runtime/master.cc:221] CreateSession still waiting for response from worker: /job:worker/replica:0/task:2- 當(dāng)用戶使用 Coscheduling 功能時(shí)
添加 pod-group 相關(guān)標(biāo)簽后創(chuàng)建任務(wù)，因?yàn)榧旱馁Y源無(wú)法滿足用戶設(shè)定的 min-available 要求，則 PodGroup 無(wú)法正常調(diào)度，所有的 Pod 一直處于 Pending 狀態(tài)。
$ kubectl get pods NAME READY STATUS RESTARTS AGE tf-smoke-gpu-ps-0 0/1 Pending 0 43s tf-smoke-gpu-worker-0 0/1 Pending 0 43s tf-smoke-gpu-worker-1 0/1 Pending 0 43s tf-smoke-gpu-worker-2 0/1 Pending 0 43s tf-smoke-gpu-worker-3 0/1 Pending 0 43s此時(shí)，如果通過(guò)集群擴(kuò)容，新增 4 個(gè) GPU 卡，資源能滿足用戶設(shè)定的 min-available 要求，則 PodGroup 正常調(diào)度，4 個(gè) Worker 開始運(yùn)行。
$ kubectl get pods NAME READY STATUS RESTARTS AGE tf-smoke-gpu-ps-0 1/1 Running 0 3m16s tf-smoke-gpu-worker-0 1/1 Running 0 3m16s tf-smoke-gpu-worker-1 1/1 Running 0 3m16s tf-smoke-gpu-worker-2 1/1 Running 0 3m16s tf-smoke-gpu-worker-3 1/1 Running 0 3m16s查看其中一個(gè) Worker 的日志，顯示訓(xùn)練任務(wù)已經(jīng)開始：
$ kubectl logs -f tf-smoke-gpu-worker-0 INFO|2020-05-19T07:15:24|/opt/launcher.py|27| Running warm up INFO|2020-05-19T07:21:04|/opt/launcher.py|27| Done warm up INFO|2020-05-19T07:21:04|/opt/launcher.py|27| Step Img/sec loss INFO|2020-05-19T07:21:05|/opt/launcher.py|27| 1 images/sec: 31.6 +/- 0.0 (jitter = 0.0) 8.318 INFO|2020-05-19T07:21:15|/opt/launcher.py|27| 10 images/sec: 31.1 +/- 0.4 (jitter = 0.7) 8.343 INFO|2020-05-19T07:21:25|/opt/launcher.py|27| 20 images/sec: 31.5 +/- 0.3 (jitter = 0.7) 8.142后續(xù)工作
利用 Kubernetes Scheduling Framework 的機(jī)制實(shí)現(xiàn)了 Coscheduling，解決了 AI、數(shù)據(jù)計(jì)算類的批任務(wù)需要組合調(diào)度，同時(shí)減少資源浪費(fèi)的問(wèn)題。從而提升集群整體資源利用率。
作者介紹：
王慶璨，阿里云技術(shù)專家，專注于大規(guī)模集群資源管理和調(diào)度。Kubernetes 社區(qū)成員，主要參與 Kube-scheduler 社區(qū)開發(fā)。目前負(fù)責(zé)阿里云容器服務(wù) ACK?資源調(diào)度和云原生 AI 相關(guān)工作。
張凱，阿里云高級(jí)技術(shù)專家，從事容器服務(wù)?ACK?和云原生 AI 解決方案的研發(fā)和客戶支持，以及相關(guān)領(lǐng)域的開源建設(shè)。擁有 10 余年大規(guī)模深度學(xué)習(xí)平臺(tái)，云計(jì)算，SOA 等領(lǐng)域經(jīng)驗(yàn)。
“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號(hào)。”
總結(jié)
以上是生活随笔為你收集整理的进击的 Kubernetes 调度系统（二）：支持批任务的 Coscheduling/Gang scheduling的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 如何在工作中快速成长？致工程师的 10
- 下一篇： 记录一次 Arthas 使用