本文解讀了字節(jié)跳動(dòng)基礎(chǔ)架構(gòu)編排調(diào)度團(tuán)隊(duì)發(fā)表在國際云計(jì)算頂級(jí)會(huì)議 SoCC 2023 上的論文“G?del: Unified Large-Scale Resource Managment and Scheduling at Bytedance”。

論文鏈接: dl.acm.org/doi/proceedings/10.1145/3620678

論文介紹了字節(jié)跳動(dòng)內(nèi)部基于 Kubernetes 提出的一套支持在線任務(wù)和離線任務(wù)混部的高吞吐任務(wù)調(diào)度系統(tǒng)，旨在有效解決大規(guī)模數(shù)據(jù)中心中不同類型任務(wù)的資源分配問題，提高數(shù)據(jù)中心的資源利用率、彈性和調(diào)度吞吐率。

目前，該調(diào)度系統(tǒng)支持管理著數(shù)萬節(jié)點(diǎn)的超大規(guī)模集群，提供包括微服務(wù)、batch、流式任務(wù)、AI 在內(nèi)的多種類型任務(wù)的資源并池能力。自 2022 年開始在字節(jié)跳動(dòng)內(nèi)部各數(shù)據(jù)中心批量部署，G?del 調(diào)度器已經(jīng)被驗(yàn)證可以在高峰期提供 >60%的 CPU 利用率和 >95%的 GPU 利用率，峰值調(diào)度吞吐率接近 5,000 pods/sec。

引言

在過去的幾年里，隨著字節(jié)跳動(dòng)各業(yè)務(wù)線的高速發(fā)展，公司內(nèi)部的業(yè)務(wù)種類也越來越豐富，包括微服務(wù)、推廣搜（推薦/廣告/搜索）、大數(shù)據(jù)、機(jī)器學(xué)習(xí)、存儲(chǔ)等業(yè)務(wù)規(guī)模迅速擴(kuò)大，其所需的計(jì)算資源體量也在飛速膨脹。

早期字節(jié)跳動(dòng)的在線業(yè)務(wù)和離線業(yè)務(wù)有獨(dú)立的資源池，業(yè)務(wù)之間采用分池管理。為了應(yīng)對(duì)重要節(jié)日和重大活動(dòng)時(shí)在線業(yè)務(wù)請(qǐng)求的爆炸性增長，基礎(chǔ)設(shè)施團(tuán)隊(duì)往往需要提前做預(yù)案，將部分離線業(yè)務(wù)的資源拆借到在線業(yè)務(wù)的資源池中。雖然這種方法可以應(yīng)對(duì)一時(shí)之需，但不同資源池之間的資源拆借流程長，操作復(fù)雜，效率很低。同時(shí)，獨(dú)立的資源池導(dǎo)致在離線業(yè)務(wù)之間混部成本很高，資源利用率提升的天花板也非常有限。

為了應(yīng)對(duì)這一問題，論文中提出了在離線統(tǒng)一調(diào)度器 G?del，旨在使用同一套調(diào)度器來統(tǒng)一調(diào)度和管理在離線業(yè)務(wù)，實(shí)現(xiàn)資源并池，從而在提升資源利用率和資源彈性的同時(shí)，優(yōu)化業(yè)務(wù)成本和體驗(yàn)，降低運(yùn)維壓力。G?del 調(diào)度器基于 Kubernetes 平臺(tái)，可以無縫替換 Kubernetes 的原生調(diào)度器，在性能和功能上優(yōu)于 Kubernetes 原生調(diào)度器和社區(qū)中其他調(diào)度器。

開發(fā)動(dòng)機(jī)

字節(jié)跳動(dòng)運(yùn)營著數(shù)十個(gè)超大規(guī)模的多集群數(shù)據(jù)中心，每天有數(shù)以千萬計(jì)容器化的任務(wù)被創(chuàng)建和刪除，晚高峰時(shí)單個(gè)集群的平均任務(wù)吞吐 >1000 pods/sec。這些任務(wù)的業(yè)務(wù)優(yōu)先級(jí)、運(yùn)行模式和資源需求各不相同，如何高效、合理地調(diào)度這些任務(wù)，在保證高優(yōu)任務(wù) SLA 和不同任務(wù)資源需求的同時(shí)維持較高的資源利用率和彈性是一項(xiàng)很有挑戰(zhàn)的工作。

通過調(diào)研，目前社區(qū)常用的集群調(diào)度器都不能很好地滿足字節(jié)跳動(dòng)的要求：

• Kubernetes 原生調(diào)度器雖然很適合微服務(wù)調(diào)度，也提供多種靈活的調(diào)度語義，但是它對(duì)離線業(yè)務(wù)的支持不盡如人意，同時(shí)因?yàn)?Kubernetes 原生調(diào)度器調(diào)度吞吐率低（< 200 pods/sec），支持的集群規(guī)模也有限（通常 <= 5000 nodes），它也無法滿足字節(jié)跳動(dòng)內(nèi)部龐大的在線業(yè)務(wù)調(diào)度需求。
• CNCF 社區(qū)的 Volcano 是一款主要針對(duì)離線業(yè)務(wù)的調(diào)度器，可以滿足離線業(yè)務(wù)（e.g. batch, offline training 等）的調(diào)度需求（e.g. Gang scheduling）。但是其調(diào)度吞吐率也比較低，而且不能同時(shí)支持在線業(yè)務(wù)。
• YARN 是另一款比較流行的集群資源管理工具，在過去很長一段時(shí)間一直是離線業(yè)務(wù)調(diào)度的首選。它不僅對(duì) batch、offline training 等離線業(yè)務(wù)所需的調(diào)度語義有很好的支持，而且調(diào)度吞吐率也很高，可以支持很大規(guī)模的集群。但其主要弊端是對(duì)微服務(wù)等在線業(yè)務(wù)的支持不好，不能同時(shí)滿足在線和離線業(yè)務(wù)的調(diào)度需求。

因此，字節(jié)跳動(dòng)希望能夠開發(fā)一款結(jié)合 Kubernetes 和 YARN 優(yōu)點(diǎn)的調(diào)度器來打通資源池、統(tǒng)一管理所有類型的業(yè)務(wù)?；谏鲜鲇懻?，該調(diào)度器被期望具有下述特點(diǎn)：

• Unified Resource Pool

集群中的所有計(jì)算資源對(duì)在線和離線的各種任務(wù)均可見、可分配。降低資源碎片率，和集群的運(yùn)維成本。

• Improved Resource Utilization

在集群和節(jié)點(diǎn)維度混部不同類型、不同優(yōu)先級(jí)的任務(wù)，提高集群資源的利用率。

• High Resource Elasticiy

在集群和節(jié)點(diǎn)維度，計(jì)算資源可以在不同優(yōu)先級(jí)的業(yè)務(wù)之間靈活且迅速地流轉(zhuǎn)。在提高資源利用率的同時(shí)，任何時(shí)候都保證高優(yōu)業(yè)務(wù)的資源優(yōu)先分配權(quán)和 SLA。

• High Scheduling Throughput

相比于 Kubernetes 原生調(diào)度器和社區(qū)的 Volcano 調(diào)度器，不論是在線還是離線業(yè)務(wù)都要大幅提高調(diào)度吞吐率。滿足 > 1000 pods/sec 的業(yè)務(wù)需求。

• Topology-aware Scheduling

在做調(diào)度決策時(shí)而不是 kubelet admit 時(shí)就識(shí)別到候選節(jié)點(diǎn)的資源微拓?fù)?，并根?jù)業(yè)務(wù)需求選擇合適的節(jié)點(diǎn)進(jìn)行調(diào)度。

G?del 介紹

G?del Scheduler 是一個(gè)應(yīng)用于 Kubernetes 集群環(huán)境、能統(tǒng)一調(diào)度在線和離線業(yè)務(wù)的分布式調(diào)度器，能在滿足在離線業(yè)務(wù)功能和性能需求的前提下，提供良好的擴(kuò)展性和調(diào)度質(zhì)量。

如下圖所示，G?del Scheduler 和 Kubernetes 原生調(diào)度器的結(jié)構(gòu)類似，由三個(gè)組件組成：Dispatcher、Scheduler 和 Binder。不一樣的是，為了支持更大規(guī)模的集群和提供更高的調(diào)度吞吐，它的 Scheduler 組件可以是多實(shí)例的，采用樂觀并發(fā)調(diào)度， Dispatcher 和 Binder 則是單實(shí)例運(yùn)行。

核心組件

Dispatcher 是整個(gè)調(diào)度流程的入口，主要負(fù)責(zé)任務(wù)排隊(duì)、任務(wù)分發(fā)、節(jié)點(diǎn)分區(qū)等工作。它主要由幾個(gè)部分構(gòu)成：Sorting Policy Manager、Dispatching Policy Manager、Node Shuffler、Scheduler Maintainer。

• Sort Policy Manager：主要負(fù)責(zé)對(duì)任務(wù)進(jìn)行排隊(duì)，現(xiàn)在實(shí)現(xiàn)了 FIFO、DRF、FairShare 等排隊(duì)策略，未來會(huì)添加更多排隊(duì)策略，如：priority value based 等。
• Dispatching Policy Manager：主要負(fù)責(zé)分發(fā)任務(wù)到不同的 Scheduler 實(shí)例，通過插件化配置支持不同的分發(fā)策略。現(xiàn)階段的默認(rèn)策略是基于 LoadBalance。
• Node Shuffler：主要負(fù)責(zé)基于 Scheduler 實(shí)例個(gè)數(shù)，對(duì)集群節(jié)點(diǎn)進(jìn)行 Partition 分片。每個(gè)節(jié)點(diǎn)只能在一個(gè) Partition 里面。每個(gè) Scheduler 實(shí)例對(duì)應(yīng)一個(gè) Partition，一個(gè) Scheduler 實(shí)例工作的時(shí)候會(huì)優(yōu)先選擇自己 Partition 內(nèi)的節(jié)點(diǎn)，沒有找到符合要求的節(jié)點(diǎn)時(shí)才會(huì)去找其他 Partition 的節(jié)點(diǎn)。如果集群狀態(tài)發(fā)生變化，例如增加或者刪除節(jié)點(diǎn)，又或者 Scheduler 個(gè)數(shù)改變，node shuffle 會(huì)基于實(shí)際情況重新劃分節(jié)點(diǎn)。
• Scheduler Maintainer：主要負(fù)責(zé)對(duì)每個(gè) Scheduler 實(shí)例狀態(tài)進(jìn)行維護(hù)，包括 Scheduler 實(shí)例健康狀況、負(fù)載情況、Partition 節(jié)點(diǎn)數(shù)等。

Scheduler 從Dispatcher 接收任務(wù)請(qǐng)求，負(fù)責(zé)為任務(wù)做出具體的調(diào)度和搶占決策，但是不真正執(zhí)行。和 Kubernetes 原生調(diào)度器一樣，G?del 的 Scheduler 也是通過一系列不同環(huán)節(jié)上的 plugins 來決定一個(gè)調(diào)度決策，例如通過下面兩個(gè) plugins 來尋找符合要求的節(jié)點(diǎn)。

• Filtering plugins：基于任務(wù)的資源請(qǐng)求，過濾掉不符合要求的節(jié)點(diǎn)；
• Scoring plugins：對(duì)上面篩選出來的節(jié)點(diǎn)進(jìn)行打分，選出最合適的節(jié)點(diǎn)。

和 Kubernetes 原生調(diào)度器不同的是，G?del 的 Scheduler 允許多實(shí)例分布式運(yùn)行。對(duì)于超大規(guī)模的集群和對(duì)高吞吐有要求的場景，我們可以配置多個(gè) scheduler 實(shí)例來滿足需求。此時(shí)每個(gè) scheduler 實(shí)例獨(dú)立、并行地進(jìn)行調(diào)度，選擇節(jié)點(diǎn)時(shí)，優(yōu)先從該實(shí)例所屬的 partition 中選擇，這樣性能更好，但只能保證局部最優(yōu)；本地 partition 沒有合適的節(jié)點(diǎn)時(shí)，會(huì)從其他實(shí)例的 partition 中選擇節(jié)點(diǎn)，但這可能會(huì)引起 conflict，即多個(gè) scheduler 實(shí)例同時(shí)選中同一個(gè)節(jié)點(diǎn)，scheduler 實(shí)例數(shù)量越多，發(fā)生 conflict 的幾率越大。因此，要合理設(shè)置實(shí)例的數(shù)量，不是越多越好。

另外，為了同時(shí)支持在線和離線任務(wù)，G?del Scheduler 采用了兩層調(diào)度語義，即支持代表 Pod Group 或 ReplicaSet 等業(yè)務(wù)部署的 Scheduling Unit 和 Pod 的 Running Unit 的兩級(jí)調(diào)度。具體用法將在后面介紹。

Binder 主要負(fù)責(zé)樂觀沖突檢查，執(zhí)行具體的搶占操作，進(jìn)行任務(wù)綁定前的準(zhǔn)備工作，比如動(dòng)態(tài)創(chuàng)建存儲(chǔ)卷等，以及最終執(zhí)行綁定操作?？偟膩碚f，它和 Kubernetes 的 Binder 工作流程類似，但在 G?del 中，Binder 要處理更多由于多 Scheduler 實(shí)例導(dǎo)致的沖突。一旦發(fā)現(xiàn)沖突，立即打回，重新調(diào)度。對(duì)于搶占操作，Binder 檢查是否存在多個(gè) Schduler 實(shí)例嘗試搶占同一個(gè)實(shí)例（i.e. Victim Pod）。如果存在這樣的問題，Binder 只處理第一個(gè)搶占并拒絕其余 Schduler 實(shí)例發(fā)出的搶占訴求。對(duì)于 Gang/Co-scheduling 而言，Binder 必須為 Pod Group 中的所有 Pod 處理沖突（如果存在的話）。要么所有 Pod 的沖突都得到解決，分別綁定每個(gè) Pod；要么拒絕整個(gè)Pod Group 的調(diào)度。

CNR 代表 Custom Node Resource，是字節(jié)跳動(dòng)為補(bǔ)充節(jié)點(diǎn)實(shí)時(shí)信息創(chuàng)建的一個(gè) CRD。它雖然本身不是 G?del Scheduler 的一部分，但可以增強(qiáng) G?del 的調(diào)度語義。該 CRD 不僅定義了一個(gè)節(jié)點(diǎn)的資源量和狀態(tài)，還定義了資源的微拓?fù)?，比?dual-socket 節(jié)點(diǎn)上每個(gè) socket 上的 CPU/Memory 消耗量和資源剩余量。使得調(diào)度器在調(diào)度有微拓?fù)溆H和需求的任務(wù)時(shí)，可以根據(jù) CNR 描述的節(jié)點(diǎn)狀態(tài)篩選合適的節(jié)點(diǎn)。

相比于只使用 topology-manager 的原生 Kubernetes，使用 CNR 可以避免將 Pod 調(diào)度到不滿足 topology 限制的節(jié)點(diǎn)上時(shí) kubelet 碰到的 scheduling failure。如果一個(gè) Pod 成功地在節(jié)點(diǎn)上創(chuàng)建，CNR 將會(huì)被隸屬于 Katalyst 的 node agent 更新。

相關(guān)閱讀：《Katalyst：字節(jié)跳動(dòng)云原生成本優(yōu)化實(shí)踐》

兩層調(diào)度

字節(jié)跳動(dòng)在設(shè)計(jì) G?del 之初，一個(gè)主要的目標(biāo)就是能夠同時(shí)滿足在線和離線業(yè)務(wù)的調(diào)度需求。為了實(shí)現(xiàn)這一目標(biāo)，G?del 引入了兩層調(diào)度語義，即 Scheduling Unit 和 Running Unit。

前者對(duì)應(yīng)一個(gè)部署的 job，由一個(gè)或多個(gè) Running Unit 組成。例如，當(dāng)用戶通過 Kubernetes Deployment 部署一個(gè) job 時(shí)，這個(gè) job 映射為一個(gè) Scheduling Unit，每個(gè)運(yùn)行 task 的 Pod 對(duì)應(yīng)一個(gè) Running Unit。和原生 Kubernetes 直接面向 Pod 的調(diào)度不同，G?del 的兩級(jí)調(diào)度框架會(huì)始終以 Scheduling Unit 的整體狀態(tài)為準(zhǔn)入原則。當(dāng)一個(gè) Scheduling Unit 被認(rèn)為可調(diào)度時(shí)，其包含的 Running Unit（i.e. Pod）才會(huì)被依次調(diào)度。

判斷一個(gè) Scheduling Unit 是否可調(diào)度的規(guī)則是有 >= Min_Member 個(gè) Running Unit 滿足調(diào)度條件，即調(diào)度器能夠?yàn)橐粋€(gè) job 中足夠多的 Pod 找到符合資源要求的節(jié)點(diǎn)時(shí)，該 job 被認(rèn)為是可以被調(diào)度的。此時(shí)，每個(gè) Pod 才會(huì)被調(diào)度器依次調(diào)度到指定的節(jié)點(diǎn)上。否則，所有的 Pod 均不會(huì)被調(diào)度，整個(gè) job 部署被拒絕。

可以看出，Scheduling Unit 的 Min_Member 是一個(gè)非常重要的參數(shù)。設(shè)置不同的 Min_Member 可以應(yīng)對(duì)不同場景的需求。Min_Member 的取值范圍是[1， Number of Running Units]。

比如，當(dāng)面向微服務(wù)的業(yè)務(wù)時(shí)，Min_Member 設(shè)置為 1。每個(gè) Scheduling Unit 中只要有一個(gè) Running Unit/Pod 的資源申請(qǐng)能夠被滿足，即可進(jìn)行調(diào)度。此時(shí)，G?del 調(diào)度器的運(yùn)行和原生 Kubernetes 調(diào)度器基本一致。

當(dāng)面向諸如 Batch、offline training 等需要 Gang 語義的離線業(yè)務(wù)時(shí)，Min_Member 的值等于 Running Unit/Pod 的個(gè)數(shù)（有些業(yè)務(wù)也可以根據(jù)實(shí)際需求調(diào)整為 1 到 Number of Running Units 之間的某個(gè)值），即所有 Pod 都能滿足資源請(qǐng)求時(shí)才開始調(diào)度。Min_Member 的值會(huì)根據(jù)業(yè)務(wù)類型和業(yè)務(wù)部署 template 中的參數(shù)被自動(dòng)設(shè)置。

性能優(yōu)化

因?yàn)樽止?jié)跳動(dòng)自身業(yè)務(wù)的需求，對(duì)調(diào)度吞吐的要求很高。G?del 的設(shè)計(jì)目標(biāo)之一就是提供高吞吐。為此，G?del 調(diào)度器把最耗時(shí)的篩選節(jié)點(diǎn)部分放在可并發(fā)運(yùn)行的多實(shí)例 Scheduler 中。一方面因?yàn)槎鄬?shí)例會(huì)碰到 conflict 的原因，Schduler 的實(shí)例數(shù)量不是越多越好；另一方面僅僅多實(shí)例帶來的性能提高不足以應(yīng)對(duì)字節(jié)單一集群上晚高峰 1000 - 2000 pods/s 的吞吐要求。為了進(jìn)一步提高調(diào)度效率，G?del 在以下幾個(gè)方面做了進(jìn)一步優(yōu)化。

• 緩存候選節(jié)點(diǎn)

在篩選節(jié)點(diǎn)的過程中，F(xiàn)ilter 和 Prioritize 是最耗時(shí)的兩個(gè)部分。前者根據(jù)資源請(qǐng)求篩選可用的節(jié)點(diǎn)，后者給候選節(jié)點(diǎn)打分尋找最適宜的節(jié)點(diǎn)。如果這兩個(gè)部分的運(yùn)行速度能夠提高，則整個(gè)調(diào)度周期會(huì)被大幅壓縮。

字節(jié)跳動(dòng)開發(fā)團(tuán)隊(duì)觀察到，雖然計(jì)算資源被來自不同業(yè)務(wù)部門的不同應(yīng)用所使用，但是來自某一個(gè)業(yè)務(wù)用戶的某個(gè)應(yīng)用的所有或者大部分 Pods 通常有著相同的資源訴求。

例：某個(gè)社交 APP 申請(qǐng)創(chuàng)建 20,000 個(gè) HTTP Server，每個(gè) Server 需要 4 CPU core 和 8GB 內(nèi)存。某個(gè) Big Data 團(tuán)隊(duì)需要運(yùn)行一個(gè)擁有 10,000 個(gè)子任務(wù)的數(shù)據(jù)分析程序，每個(gè)子任務(wù)需要 1 CPU core 和 4GB 內(nèi)存。

這些大量創(chuàng)建的任務(wù)中多數(shù) Pod 擁有相同的資源申請(qǐng)、相同的網(wǎng)段和設(shè)備親和等需求。那么 Filter Plugin 篩選出來的候選節(jié)點(diǎn)符合第一個(gè) Pod 的需求，也大概率滿足該任務(wù)其他 Pod 的需求。

因此，G?del 調(diào)度器會(huì)在調(diào)度第一個(gè) Pod 后緩存候選節(jié)點(diǎn)，并在下一輪調(diào)度中優(yōu)先從緩存中搜索可用的節(jié)點(diǎn)。除非集群狀態(tài)發(fā)生變化（增加或刪除節(jié)點(diǎn)）或者碰到不同資源訴求的 Pod，不需要每一輪都重新掃描集群中的節(jié)點(diǎn)。在調(diào)度的過程中沒有資源可分配的節(jié)點(diǎn)會(huì)被移除緩存，并根據(jù)集群狀態(tài)調(diào)整排序。這一優(yōu)化可以明顯優(yōu)化節(jié)點(diǎn)篩選的過程，當(dāng)調(diào)度同一個(gè)業(yè)務(wù)用戶的一組 Pod 時(shí)，理想情況下可以把時(shí)間復(fù)雜度從 O(n) 降低到 O(1)。

• 降低掃描節(jié)點(diǎn)的比例

雖然上述優(yōu)化可以降低候選節(jié)點(diǎn)的構(gòu)建過程，但是如果集群狀態(tài)或者資源申請(qǐng)發(fā)生變化，還是要重新掃描集群所有節(jié)點(diǎn)。

為了進(jìn)一步降低時(shí)間開銷，G?del 調(diào)整了候選列表的掃描比例，用局部最優(yōu)解作為全局最優(yōu)解的近似替代。因?yàn)檎{(diào)度過程中需要為所有 Running Units/Pods 找到足夠的候選節(jié)點(diǎn)，G?del 至少會(huì)掃描 # of Running Units 個(gè)數(shù)的節(jié)點(diǎn)，根據(jù)歷史數(shù)據(jù)的分析，G?del 默認(rèn)掃描 # of Running Units + 50 個(gè)節(jié)點(diǎn)來尋找候選節(jié)點(diǎn)。如果沒有找到合適的，會(huì)再掃描相同的個(gè)數(shù)。該方法結(jié)合候選節(jié)點(diǎn)緩存，會(huì)大大降低調(diào)度器為Pod尋找合適節(jié)點(diǎn)的時(shí)間開銷。

• 優(yōu)化數(shù)據(jù)結(jié)構(gòu)和算法

除了上述兩個(gè)優(yōu)化外，G?del 調(diào)度器還不斷對(duì)數(shù)據(jù)結(jié)構(gòu)和算法進(jìn)行優(yōu)化：

為了可以低成本地維護(hù)候選節(jié)點(diǎn)列表，避免頻繁重建節(jié)點(diǎn)列表產(chǎn)生的開銷。G?del 重構(gòu)了原生 Kubernetes 調(diào)度器的 NodeList 維護(hù)機(jī)制，通過離散化節(jié)點(diǎn)列表的方式解決了超大規(guī)模生產(chǎn)集群出現(xiàn)的性能問題，并以更低的開銷獲得了更好的節(jié)點(diǎn)離散效果；

為了提高整體資源利用率，字節(jié)跳動(dòng)將高優(yōu)的在線任務(wù)和低優(yōu)的離線任務(wù)混合部署。由于業(yè)務(wù)的潮汐特點(diǎn)，晚高峰時(shí)伴隨著大量在線業(yè)務(wù)的返場，往往需要高頻地?fù)屨嫉蛢?yōu)的離線業(yè)務(wù)。搶占過程涉及到大量的搜索計(jì)算，頻繁搶占嚴(yán)重地影響了調(diào)度器的整體工作效率。為了解決這一問題，G?del 調(diào)度器引入了基于 Pod 和 Nodes 的多維剪枝策略，使得搶占吞吐能夠快速回升、搶占時(shí)延大幅降低。

實(shí)驗(yàn)結(jié)果

論文評(píng)估了 G?del 調(diào)度器在調(diào)度吞吐、集群規(guī)模等方面的性能。

首先，對(duì)于微服務(wù)業(yè)務(wù)，字節(jié)跳動(dòng)將 G?del（單實(shí)例）與 Kubernetes 原生調(diào)度器進(jìn)行了對(duì)比。在集群規(guī)模上，原生 Kubernetes 默認(rèn)最大只能支持 5,000 節(jié)點(diǎn)的集群，最大調(diào)度吞吐小于200 Pods/s。在使用字節(jié)開源的高性能 key-value store - KubeBrain 后，原生 Kubernetes 可以支持更大規(guī)模的集群，調(diào)度吞吐也明顯提高。但 Kubernetes + KubeBrain 組合后的性能仍然遠(yuǎn)小于 G?del。G?del 在 5,000 節(jié)點(diǎn)規(guī)模的集群上可以達(dá)到 2,600 Pods/s 的性能，即使在 20,000 節(jié)點(diǎn)時(shí)仍然有約 2,000 Pods/s，是原生 Kubernetes 調(diào)度器性能的 10 倍以上。

為了取得更高的調(diào)度吞吐，G?del 可以開啟多實(shí)例。下面右圖中描述的是 10,000 節(jié)點(diǎn)的集群中依次開啟 1-6個(gè) 調(diào)度器實(shí)例，開始階段吞吐逐漸增加，峰值可以達(dá)到約 4,600 Pods/s。但當(dāng)實(shí)例數(shù)超過 5 個(gè)后，性能有所下降，原因是實(shí)例越多，實(shí)例間的沖突越多，影響了調(diào)度效率。所以，并不是調(diào)度實(shí)例越多越好。

對(duì)于有 Gang 語義需求的離線任務(wù)，論文將 G?del 和開源社區(qū)常用的 YARN 和 K8s-volcano 進(jìn)行對(duì)比。可以明顯看出，G?del 的性能不但遠(yuǎn)遠(yuǎn)高于 K8s-volcano，也接近兩倍于 YARN。G?del 支持同時(shí)調(diào)度在線和離線任務(wù)，論文通過改變系統(tǒng)中提交的在離線任務(wù)的比例來模擬不同業(yè)務(wù)混部時(shí)的場景?？梢钥闯觯徽撛陔x線業(yè)務(wù)的比例如何，G?del的性能都比較穩(wěn)定，吞吐維持在 2,000 Pods/s 左右。

為了論證為什么 G?del 會(huì)有如此大的性能提高，論文著重分析了兩個(gè)主要的優(yōu)化“緩存候選節(jié)點(diǎn)”和“降低掃描比例”產(chǎn)生的貢獻(xiàn)。如下圖所示，依次使用完整版 G?del、只開啟節(jié)點(diǎn)緩存優(yōu)化的 G?del 和只開啟降低掃描比例的 G?del 來重復(fù)前面的實(shí)驗(yàn)，實(shí)驗(yàn)結(jié)果證明，這兩個(gè)主要的優(yōu)化項(xiàng)分別貢獻(xiàn)了約 60% 和 30% 的性能提升。

除了用 benchmark 來評(píng)估 G?del 的極限性能，論文還展示了字節(jié)跳動(dòng)在生產(chǎn)環(huán)境中使用 G?del 調(diào)度器帶來的實(shí)際體驗(yàn)，表現(xiàn)出 G?del 在資源并池、彈性和流轉(zhuǎn)方面具備良好的能力。

下面左圖描述的是某集群在某段時(shí)間內(nèi)在線任務(wù)和離線任務(wù)的資源分配情況。開始階段，在線任務(wù)消耗的資源不多，大量計(jì)算資源被分配給優(yōu)先級(jí)較低的離線任務(wù)。當(dāng)在線任務(wù)由于某個(gè)特殊事件（突發(fā)事件、熱搜等）導(dǎo)致資源需求激增后，G?del 立刻把資源分配給在線任務(wù)，離線任務(wù)的資源分配量迅速減少。當(dāng)高峰過后，在線任務(wù)開始降低資源請(qǐng)求，調(diào)度器再次把資源轉(zhuǎn)向離線任務(wù)。通過在離線并池和動(dòng)態(tài)資源流轉(zhuǎn)，字節(jié)跳動(dòng)可以一直維持較高的資源利用率。晚高峰時(shí)間，集群的平均資源率達(dá)到 60%以上，白天波谷階段也可以維持在 40% 左右。

總結(jié)及未來展望

論文介紹了字節(jié)跳動(dòng)編排調(diào)度團(tuán)隊(duì)設(shè)計(jì)和開發(fā)的統(tǒng)一在離線資源池的調(diào)度系統(tǒng) G?del。該調(diào)度系統(tǒng)支持在超大規(guī)模集群中同時(shí)調(diào)度在線和離線任務(wù)，支持資源并池、彈性和流轉(zhuǎn)，并擁有很高的調(diào)度吞吐。G?del 自 2022 年在字節(jié)跳動(dòng)自有數(shù)據(jù)中心批量上線以來，滿足了內(nèi)場絕大部分業(yè)務(wù)的混部需求，實(shí)現(xiàn)了晚高峰 60% 以上的平均資源利用率和約 5,000 Pods/s 的調(diào)度吞吐。

未來，編排調(diào)度團(tuán)隊(duì)會(huì)繼續(xù)推進(jìn) G?del 調(diào)度器的擴(kuò)展和優(yōu)化工作，進(jìn)一步豐富調(diào)度語義，提高系統(tǒng)響應(yīng)能力，降低多實(shí)例情況下的沖突概率，并且會(huì)在優(yōu)化初次調(diào)度的同時(shí)，構(gòu)建和加強(qiáng)系統(tǒng)重調(diào)度的能力，設(shè)計(jì)和開發(fā) G?del Rescheduler。通過 G?del Scheduler 和 Rescheduler 的協(xié)同工作，實(shí)現(xiàn)全周期內(nèi)集群資源的合理分配。