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

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

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

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

引言

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

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

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

開發(fā)動機

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

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

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

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

• Unified Resource Pool

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

• Improved Resource Utilization

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

• High Resource Elasticiy

在集群和節(jié)點維度，計算資源可以在不同優(yōu)先級的業(yè)務(wù)之間靈活且迅速地流轉(zhuǎn)。在提高資源利用率的同時，任何時候都保證高優(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)度決策時而不是 kubelet admit 時就識別到候選節(jié)點的資源微拓撲，并根據(jù)業(yè)務(wù)需求選擇合適的節(jié)點進行調(diào)度。

G?del 介紹

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

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

核心組件

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

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

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

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

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

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

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

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

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

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

兩層調(diào)度

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

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

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

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

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

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

性能優(yōu)化

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

• 緩存候選節(jié)點

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

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

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

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

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

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

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

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

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

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

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

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

實驗結(jié)果

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

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

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

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

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

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

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

總結(jié)及未來展望

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

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