作者：Koordinator 團隊

Koordinator 從 2022 年 4 月發布以來，迄今一共迭代發布了 8 個版本。項目經歷的大半年發展過程中，Koordinator 社區吸納了包括阿里巴巴、小米、小紅書、愛奇藝、360 在內的大量優秀工程師，貢獻了眾多的想法、代碼和場景，一起推動 Koordinator 項目的成熟。

11 月 3 日，在 2022 杭州 · 云棲大會上，阿里云智能云原生應用平臺負責人丁宇宣布，Koordinator 1.0 正式發布。

如果你對混部、調度領域不太關注，可能對 Koordinator 還沒有做過太深入的了解。本文就借著 v1.0 發布時機，為你詳細的梳理一次 Koordinator 項目的發展脈絡，解讀它的核心思想和愿景，掌握這個正在快速發展的云原生混部系統的技術理念。

項目的前生今世

Koordinator，名字取自 coordinator，K for Kubernetes，發音相同。語意上契合項目要解決的問題，即協調編排 kubernetes 集群中不同類型的工作負載，使得他們以最優的布局、最佳的姿態在一個集群、一個節點上運行。

容器混部技術最早起源于 Google 內部的一個 Borg 系統，在其論文公開發表（2015）之前在行業上一直是非常神秘的存在。在業界，基于 Hadoop 的大數據任務調度技術先行，在比較早期很好的解決了企業對于大數據計算的訴求。熟悉歷史的同學應該知道，云原生容器調度編排系統 Kubernetes 開源于 2014 年， 而 Kubernetes 正是受 Borg 設計思想啟發，由 Borg 系統的設計者結合云時代應用編排的需求重新設計而來。Kubernetes 良好的擴展性使其能適應多樣的工作負載，幫助用戶很好的解決工作負載日常運維效率。隨著 Kubernetes 的蓬勃發展，逐步成為行業的事實標準，越來越多的工作負載開始運行在 Kubernetes 之上，特別是在這兩年，大數據相關的負載逐步遷移到 Kubernetes 之上。

阿里巴巴早在 2016 年就啟動了混部技術研發，到今年，內混部系統經歷了三輪大的架構升級，并經歷多年“雙11”峰值流量的錘煉。目前，阿里巴巴實現全業務規模超千萬核的云原生混部，混部 CPU 利用率超 50%，混部技術幫助 2022 年“雙11”計算成本大幅下降。在這個過程中，阿里巴巴混部也走過了一些彎路，積累了大量的生產實踐經驗。

為了幫助企業少走彎路，更快速的拿到云原生混部帶來的資源效率紅利，阿里巴巴在 2022 年 4 月份正式對外發布的 Koordinator 開源項目。通過建立一個中立的開源社區，幫助企業實現在標準 Kubernetes 之上的多種類型負載混部的調度解決方案，以達到云上、云下一致的云原生混部架構，降低系統運維成本，保持長期可持續發展的健康形態。

Koordinator 自發布以來，在開源制度與規范上不斷向 Kubernetes 等前輩學習，逐漸形成了較為完善的社區運作機制。在這里，我們會淡化每一位社區成員的雇主、職務，以用戶、開發者的身份參與到社區建設中。同樣，Koordinator 未來的 roadmap 與發展規劃，也將源于所有成員與用戶的反饋、需求與共識，而非阿里巴巴自身制定。因此，對于每一位云原生愛好者，不管你是初識調度領域或是混部場景的親身經歷者，都歡迎你關注和參與到 Koordinator 項目中，共同打造一套面向未來的開源混部體系。

標準、通用的混部解決方案

混部需要一套完整、自閉環的調度回路，但在企業應用混部的過程中，將要面臨的兩大挑戰是：

應用如何接入到混部平臺

應用如何在平臺上能夠運行穩定、高效

Koordinator 吸取了阿里巴巴內部多年的生產實踐經驗教訓，針對這兩大挑戰針對性的設計了解決方案，旨在幫助企業真正意義上的用上混部，用好 Kubernetes，而不是秀技術秀肌肉。

Koordinator 1.0 的整體架構如下圖所示，為了用戶提供了完整的混部工作負載編排、混部資源調度、混部資源隔離及性能調優解決方案，幫助用戶提高延遲敏感服務的運行性能，挖掘空閑節點資源并分配給真正有需要的計算任務，從而提高全局的資源利用效率。

大規模生產實踐錘煉

2021 雙 11 之后阿里對外宣布了“首次！統一調度系統規模化落地，全面支撐阿里巴巴雙 11 全業務”：

作為阿里巴巴的核心項目，阿里云（容器團隊和大數據團隊）聯合阿里巴巴資源效能團隊、螞蟻容器編排團隊，歷時一年多研發和技術攻堅，實現了從“混部技術”到今天“統一調度技術”的全面升級。

今天，統一調度已實現阿里巴巴電商、搜推廣、MaxCompute 大數據的調度全面統一，實現了 Pod 調度和 task 高性能調度的統一，實現了完整的資源視圖統一和調度協同，實現了多種復雜業務形態的混部和利用率提升，全面支撐了全球數十個數據中心、數百萬容器、數千萬核的大規模資源調度。

作為云原生混部的踐行者，阿里巴巴是真刀真槍的在生產環境中推進混部技術理念，并在去年雙 11 完成了超過千萬核的混部規模，通過混部技術幫助阿里巴巴雙 11 節約超過 50% 的大促資源成本，在大促快上快下鏈路上提速 100%，助力大促實現絲滑的用戶體驗。

正是在雙 11 這樣的峰值場景驅動之下，阿里的混部調度技術持續演進，積累了大量的生產實踐經驗，到今天已經是第三代即云原生全業務混部系統。Koordinator 的架構基于阿里巴巴內部的超大規模生產實踐，結合阿里云看到的企業容器客戶的真實訴求，在標準化、通用化上做出了更多的突破，實現首個基于標準 Kubernetes 的生產可用的開源混部系統。

支持豐富的負載類型

混部是一套針對延遲敏感服務的精細化編排+大數據計算工作負載混合部署的資源調度解決方案，核心技術在于：

精細的資源編排，以滿足性能及長尾時延的要求，關鍵點是精細化的資源調度編排策略及 QoS 感知策略；

智能的資源超賣，以更低成本滿足計算任務對計算資源的需求，并保證計算效率的同時不影響延遲敏感服務的響應時間。

上圖是 Koordinator 混部資源超賣模型，也是混部最關鍵最核心的地方。其中超賣的基本思想是去利用那些已分配但未使用的資源來運行低優先級的任務，如圖所示的四條線分別是資源使用量（紅線），短生命周期可超賣量（藍線），長生命周期可超賣量（淺藍），以及資源總量（黑線）。

該資源模型足夠精煉的同時也具備很強的靈活性，支持豐富的在線資源編排類別，支持短生命周期的批處理任務（MapReduce 類別），以及實時計算類的生命周期任務。Koordinator 整個混部資源調度的大廈構建在這樣一個資源模型的基礎之上，配合上優先級搶占、負載感知、干擾識別和 QoS 保障技術，構建出混部資源調度底層核心系統。Koordinator 社區將圍繞這個思路投入建設，持續將混部場景的調度能力展開，解決企業面臨的真實業務場景問題。

零侵入，低接入成本

企業接入混部最大的挑戰是如何讓應用跑在混部平臺之上，這第一步的門檻往往是最大的攔路虎。Koordinator 針對這一問題，結合內部生產實踐經驗，設計了“零侵入”的混部調度系統：

對 Kubernetes 平臺的零侵入：無需修改任何 Kubernetes 原生組件，而是以插件的方式增強混部需要的各種能力

對工作負載編排系統的零侵入：無需修改計算任務的管理引擎（operator），而是以配置化的方式管理混部策略參數，簡化應用接入的難度

支持系統的平滑升級：已有的 Kubernetes 集群的調度器可以平滑升級到 Koordinator，存量的 Pod 的標準調度能力可以無損接管到 Koordinator 中

通過在這三方面的努力，降低用戶在生產環境中引入 Koordinator 的難度，只在幫助用戶解決生產環境應用混部的第一道攔路虎。

版本特性深入解讀

自 2022 年 4 月份 Koordinator 發布以來，社區圍繞在混部資源的一層調度而構建，解決任務混部最核心的資源編排、資源隔離的問題。在版本迭代過程中，Koordinator 社區始終圍繞三大能力而構建，即任務調度、差異化 SLO 以及 QoS 感知調度能力。

任務調度

• Enhanced Coscheduling

Koordinator 在啟動之初，期望支持 Kubernetes 多種工作負載的混部調度，提高工作負載的運行時效率和可靠性，其中就包括了機器學習和大數據領域中廣泛存在的具備 All-or-Nothing 需求的作業負載。例如當提交一個Job 時會產生多個任務，這些任務期望要么全部調度成功，要么全部失敗。這種需求稱為 All-or-Nothing，對應的實現被稱作 Gang Scheduling(or Coscheduling) 。為了解決 All-or-Nothing 調度需求，Koordinator 基于社區已有的 Coscheduling 實現了 Enhanced Coscheduling：

支持 Strict/NonStrict 模式，解決大作業場景長時間得不到資源問題

支持 AI 場景多角色聯合的 coscheduling 策略，例如一個 TF 訓練 Job 中包含 PS 和 Worker 兩種角色，并且兩種角色都需要單獨定義 MinMember，但又期望兩種角色的 All-or-Nothing 都滿足后才能繼續調度

• Enhanced ElasticQuota Scheduling

企業的 Kubernetes 一般由多個產品和研發團隊共用一個規模比較大的 Kubernetes 集群，由資源運維團隊統一管理集群內大量 CPU/Memory/Disk 等資源。

Koordinator 為幫助用戶管理好資源額度，提升資源額度的使用效率，實現降本增效，Koordinator 基于基于社區 ElasticQuota CRD 實現了 Enhanced ElasticQuota Scheduling ，具備如下增強特性：

• 兼容社區的 ElasticQuota CRD，用戶可以無縫升級到 Koordinator
• 支持樹形結構管理 Quota，契合企業的組織架構
• 支持按照共享權重(shared weight)保障公平性
• 允許用戶設置是否允許借用 Quota 給其他消費對象

Koordinator ElasticQuota Scheduling 通過額度借用機制和公平性保障機制，Koordinator 把空閑的額度復用給更需要的業務使用。當額度的所有者需要額度時，Koordinator 又可以保障有額度可用。通過樹形管理機制管理 Quota，可以方便的與大多數公司的組織結構映射，解決同部門內或者不同部門間的額度管理需求。

• Fine-grained Device Scheduling

在 AI 領域，GPU、RDMA、FPGA 等異構資源被廣泛的應用，Koordinator 針對異構資源調度場景，提供了精細化的設備調度管理機制，包括：

支持 GPU 共享，GPU 獨占，GPU 超賣

支持百分比的 GPU 調度

支持 GPU 多卡調度

NVLink 拓撲感知調度（doing）

差異化 SLO

差異化 SLO 是 Koordinator 提供的核心混部能力，保障資源超賣之后的 Pod 的運行穩定性。Koordinator 定了一一組 Priority & QoS，用戶按照這一最佳實踐的方式接入應用，配合完善的資源隔離策略，最終保障不同應用類型的服務質量。

• CPU Supress

Koordinator 的單機組件 koordlet 會根據節點的負載水位情況，調整 BestEffort 類型 Pod 的 CPU 資源額度。這種機制稱為 CPU Suppress。當節點的在線服務類應用的負載較低時，koordlet 會把更多空閑的資源分配給 BestEffort 類型的 Pod 使用；當在線服務類應用的負載上升時，koordlet 又會把分配給 BestEffort 類型的 Pod 使用的 CPU 還給在線服務類應用。

• CPU Burst

CPU Burst 是一種服務級別目標 (SLO) 感知的資源調度功能。用戶可以使用 CPU Burst 來提高對延遲敏感的應用程序的性能。內核的調度器會因為容器設置的 CPU Limit 壓制容器的 CPU，這個過程稱為 CPU Throttle。該過程會降低應用程序的性能。

Koordinator 自動檢測 CPU Throttle 事件，并自動將 CPU Limit 調整為適當的值。通過 CPU Burst 機制能夠極大地提高延遲敏感的應用程序的性能。

• 基于內存安全閾值的主動驅逐機制

當延遲敏感的應用程序對外提供服務時，內存使用量可能會由于突發流量而增加。類似地，BestEffort 類型的工作負載可能存在類似的場景，例如，當前計算負載超過預期的資源請求/限制。這些場景會增加節點整體內存使用量，對節點側的運行時穩定性產生不可預知的影響。例如，它會降低延遲敏感的應用程序的服務質量，甚至變得不可用。尤其是在混部場景下，這個問題更具挑戰性。

我們在 Koordinator 中實現了基于內存安全閾值的主動驅逐機制。koordlet 會定期檢查 Node 和 Pods 最近的內存使用情況，檢查是否超過了安全閾值。如果超過，它將驅逐一些 BestEffort 類型的 Pod 釋放內存。在驅逐前根據 Pod 指定的優先級排序，優先級越低，越優先被驅逐。相同的優先級會根據內存使用率（RSS）進行排序，內存使用率越高越優先被驅逐。

• 基于資源滿足的驅逐機制

CPU Suppress 在線應用的負載升高時可能會頻繁的壓制離線任務，這雖然可以很好的保障在線應用的運行時質量，但是對離線任務還是有一些影響的。雖然離線任務是低優先級的，但頻繁壓制會導致離線任務的性能得不到滿足，嚴重的也會影響到離線的服務質量。而且頻繁的壓制還存在一些極端的情況，如果離線任務在被壓制時持有內核全局鎖等特殊資源，那么頻繁的壓制可能會導致優先級反轉之類的問題，反而會影響在線應用。雖然這種情況并不經常發生。

為了解決這個問題，Koordinator 提出了一種基于資源滿足度的驅逐機制。我們把實際分配的 CPU 總量與期望分配的 CPU 總量的比值成為 CPU 滿足度。當離線任務組的 CPU 滿足度低于閾值，而且離線任務組的 CPU 利用率超過 90% 時，koordlet 會驅逐一些低優先級的離線任務，釋放出一些資源給更高優先級的離線任務使用。通過這種機制能夠改善離線任務的資源需求。

• L3 Cache 和內存帶寬分配(MBA) 隔離

混部場景下，同一臺機器上部署不同類型的工作負載，這些工作負載會在硬件更底層的維度發生頻繁的資源競爭。因此如果競爭沖突嚴重時，是無法保障工作負載的服務質量的。

Koordinator 基于 Resource Director Technology (RDT, 資源導向技術) ，控制由不同優先級的工作負載可以使用的末級緩存（服務器上通常為 L3 緩存）。RDT 還使用內存帶寬分配 (MBA) 功能來控制工作負載可以使用的內存帶寬。這樣可以隔離工作負載使用的 L3 緩存和內存帶寬，確保高優先級工作負載的服務質量，并提高整體資源利用率。

QoS 感知調度、重調度

Koordinator 差異化 SLO 能力在節點側提供了諸多 QoS 保障能力能夠很好的解決運行時的質量問題。同時 Koordinator Scheduler 也在集群維度提供了增強的調度能力，保障在調度階段為不同優先級和類型的 Pod 分配合適的節點。

• 負載感知調度

超發資源可以極大的提升集群的資源利用率，但也會凸顯集群內節點之間資源利用率不均勻的現象。這個現象在非混部環境下也是存在的，只是因為 Kubernetes 原生是不支持資源超發機制，節點上的利用率往往不是很高，一定程度上掩蓋了這個問題。但當混部時，資源利用率會上升到比較高的水位時就暴露了這個問題。

利用率不均勻一般是節點之間不均勻以及出現局部的負載熱點，局部的負載熱點會可能影響工作負載的整體運行效果。另一個是在負載高的節點上，在線應用和離線任務之間可能會存在的嚴重的資源沖突，影響到在線應用的運行時質量。

為了解決這個問題， Koordinator 的調度器提供了一個可配置的調度插件控制集群的利用率。該調度能力主要依賴于 koordlet 上報的節點指標數據，在調度時會過濾掉負載高于某個閾值的節點，防止 Pod 在這種負載較高的節點上無法獲得很好的資源保障，另一方面是避免負載已經較高的節點繼續惡化。在打分階段選擇利用率更低的節點。該插件會基于時間窗口和預估機制規避因瞬間調度太多的 Pod 到冷節點機器出現一段時間后冷節點過熱的情況。

• 精細化 CPU 調度

隨著資源利用率的提升進入到混部的深水區，需要對資源運行時的性能做更深入的調優，更精細的資源編排可以更好的保障運行時質量，從而通過混部將利用率推向更高的水平。

我們把 Koordinator QoS 在線應用 LS 類型做了更細致的劃分，分為 LSE、LSR 和 LS 三種類型。拆分后的 QoS 類型具備更高的隔離性和運行時質量。通過這樣的拆分，整個 Koordinator QoS 語義更加精確和完整，并且兼容 Kubernetes 已有的 QoS 語義。

而且我們針對 Koordinator QoS，設計了一套豐富靈活的 CPU 編排策略，如下表所示。

不同的 QoS 類型的工作負載具備不同的隔離性：

Koordinator Scheduler 會針對 LSE/LSR 類型的 Pod 分配具體的 CPU 邏輯核，并更新到 Pod Annotation 中，由單機側 koordlet 配合，把調度器分配的 CPU 更新到 cgroup 中。

調度器在分配 CPU 時，會根據 CPU 拓撲結構分配，默認盡可能的保障分配的 CPU 屬于同一個 NUMA Node 以獲得更好的性能。并且 CPU 調度時，支持 Pod 根據需要設置不同的互斥策略，例如一個系統中多個核心的服務部署在相同的物理核上，性能表現比較差，但分開就完全沒問題，此時就可以配置互斥策略，調度器會盡可能的把這種互斥屬性的 Pod 分配使用不同的物理核。并且在打分階段，調度器會參考集群的整體情況，選擇符合 CPU 編排要求的節點。

• 資源預留（Reservation）

Koordinator 支持在不侵入 Kubernetes 已有的機制和代碼前提下，實現了資源預留的原子能力(Reservation)。Koordinator Reservation API 允許用戶不修改 Pod Spec 或者存量的 Workload(例如 Deployment, StatefulSet）即可以預留資源。資源預留在容量管理、碎片優化、調度成功率和重調度等場景有重要作用：

當有重要的工作負載在未來某段時間需要資源時，可以提前預留資源滿足需求。

用戶在 PaaS 上發起擴容時，可以通過資源預留能力嘗試預留，預留成功后發起擴容，保障 PaaS 的 SLA。

用戶在 PaaS 上發布時，如果應用采用了滾動發布的能力，可以通過資源預留保留即將銷毀的 Pod 持有的資源，在滾動發布時，新建的 Pod 可以復用預留下來的原有資源，能夠有效提高滾動發布的成功率。

碎片優化場景中，可以通過資源預留占住空閑的碎片資源，并把可被整理的 Pod 遷移到這些節點。

重調度時在發起驅逐前，先嘗試預留資源，預留成功后發起驅逐，避免驅逐后無資源可用影響應用的可用性。

• 靈活可擴展且安全的重調度器

調度器調度時是根據當時集群內的情況和配置，做出綜合的判斷，選擇出一個最合適的節點分配給 Pod 使用。但隨著時間和工作負載的變化，原本最合適的節點也會變差，差異化 SLO 和調度器都提供了豐富的能力幫助改善這些問題，但差異化 SLO 更多還是關注在自身單機的情況，無法感知全局的變化。

從控制的角度看，我們也需要根據集群內的情況做出決策，把異常的 Pod 驅逐遷移到更合適的節點，讓這些 Pod 有機會可以更好的對外服務。因此 Koordinator Descheduler 應運而生。

我們認為 Pod 遷移是一個復雜的過程，涉及到審計、資源分配、應用啟動等步驟，還夾雜著應用的發布升級、擴容/縮容場景和集群管理員的資源運維操作。因此，如何管理 Pod 遷移過程的穩定性風險，保證應用不會因為 Pod 的遷移影響可用性，是一個非常關鍵的必須解決的問題。

為了讓大家更好的理解，舉幾個場景：

社區的重調度器內置的多個重調度策略根據自身邏輯判斷某個 Pod 是否要被遷移，需要遷移時調用 Kubernetes Eviction API 發起驅逐。但是這個過程并不關注被驅逐的 Pod 在將來是否可以分配到資源。因此存在大量 Pod 被驅逐后因為沒有資源而處于 Pending 狀態的情況。如果應用此時有大量請求進來，又因為沒有足夠的可用的 Pod 導致可用性異常。

另外，社區重調度器調用的 Kubernetes Evcition API 雖然會檢查 PDB 確保在安全范圍內驅逐，但是眾所周知，眾多的 workload Controller 在發布和縮容場景都是通過直接調用 Delete API 的形式銷毀 Pod，此時并不會被 PDB 限制。這就導致重調度時如果遇到上述場景，是很可能引發嚴重的穩定性問題。

我們認為 Pod 騰挪不是一個簡單的后臺自動化邏輯，有相當多的場景和用戶期望由人工介入手工遷移 Pod，甚至期望重調度時發起的自動遷移請求應該被攔截掉，經過審批決定是否執行。

Koordinator 基于 CRD 定義了一個名為 PodMigrationJob API。重調度器或者其他自動化自愈組件通過 PodMigrationJob 可以安全的遷移 Pod。PodMigrationJob Controller 在處理 PodMigrationJob 時會先嘗試通過 Koordinator Reservation 機制預留資源，預留失敗則遷移失敗；資源預留成功后發起驅逐操作并等待預留的資源被消費。中間的過程都會記錄到 PodMigrationJobStatus 中，并產生相關的 Event。

我們在 Koordinator 中實現了一個全新的 Descheduler Framework。我們認為重調度場景：

需要一個插件化機制實現自定義的重調度策略，但又不希望這個抽象過于復雜；

需要具備基本的插件管理能力，通過配置啟用和禁用插件；

具備統一的插件配置下發機制，方便插件自定義參數；

并能夠方便的擴展和使用統一的 Evictor 機制；

另外期望用戶能夠基于 controller-runtime 實現 controller 并納入統一的插件管理機制。

Koordinator descheduler framework 提供了插件配置管理（例如啟用、禁用，統一配置等）、插件初始化、插件執行周期管理等機制。并且該框架內置了基于 PodMigrationJob 實現的 Controller，并作為 Evictor Plugin 方便被各種重調度插件使用，幫助重調度插件安全的遷移 Pod。

基于 Koordinator descheduler framework，用戶可以非常容易的擴展實現自定義重調度策略，就像基于 Kubernetes scheduling framework 的實現自定義的調度插件一樣簡單。并且用戶也可以以插件的形式實現 controller，支持基于 Event 觸發重調度的場景。

Koordinator 的未來規劃

Koordinator 社區將不斷豐富大數據計算任務混部的形態，拓展包括 Hadoop YARN 等計算框架混部支持，豐富任務混部解決方案，項目上持續的完善干擾檢測、問題診斷體系，推進更多的負載類型融入 Koordinator 生態，并取得更好的資源運行效率。

Koordinator 社區將持續的保持中立的發展趨勢，聯合各廠商持續的推進混部能力的標準化，也歡迎大家加入社區共同推進混部的標準化進程。

總結

以上是生活随笔為你收集整理的Koordinator 1.0 正式发布：业界首个生产可用、面向规模场景的开源混部系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。