*作者：Koordinator 團隊*

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

11 月 3 日，在 2022 杭州 · 雲棲大會上，阿里雲智慧雲原生應用平臺負責人丁宇宣佈，Koordinator 1.0 正式釋出。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/62a9100246f849048bf414d28896692a~tplv-k3u1fbpfcp-zoom-1.image "1.png")

如果你對混部、排程領域不太關注，可能對 Koordinator 還沒有做過太深入的瞭解。本文就藉著 v1.0 釋出時機，為你詳細的梳理一次 Koordinator 專案的發展脈絡，解讀它的核心思想和願景，掌握這個正在快速發展的雲原生混部系統的技術理念。

## 專案的前生今世

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

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

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2a39badbaefb418ea6c6dbbbba72b154~tplv-k3u1fbpfcp-zoom-1.image "2.png")

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

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

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

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

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

1.  **應用如何接入到混部平臺**
1.  **應用如何在平臺上能夠執行穩定、高效**

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

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

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a7d0d040347449059a3dace674608351~tplv-k3u1fbpfcp-zoom-1.image "3.png")

### 大規模生產實踐錘鍊

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

> 作為阿里巴巴的核心專案，阿里雲（容器團隊和大資料團隊）聯合阿里巴巴資源效能團隊、螞蟻容器編排團隊，歷時一年多研發和技術攻堅，實現了從“混部技術”到今天“統一排程技術”的全面升級。
>   
> 今天，統一排程已實現阿里巴巴電商、搜推廣、MaxCompute 大資料的排程全面統一，實現了 Pod 排程和 task 高效能排程的統一，實現了完整的資源檢視統一和排程協同，實現了多種複雜業務形態的混部和利用率提升，全面支撐了全球數十個資料中心、數百萬容器、數千萬核的大規模資源排程。

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

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

### 支援豐富的負載型別

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

1.  精細的資源編排，以滿足效能及長尾時延的要求，關鍵點是精細化的資源排程編排策略及 QoS 感知策略；
1.  智慧的資源超賣，以更低成本滿足計算任務對計算資源的需求，並保證計算效率的同時不影響延遲敏感服務的響應時間。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5a5116cd209f487cbca7c8a42a8abdfd~tplv-k3u1fbpfcp-zoom-1.image "4.png")

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

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

### 零侵入，低接入成本

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

1.  對 Kubernetes 平臺的零侵入：無需修改任何 Kubernetes 原生元件，而是以外掛的方式增強混部需要的各種能力
1.  對工作負載編排系統的零侵入：無需修改計算任務的管理引擎（operator），而是以配置化的方式管理混部策略引數，簡化應用接入的難度
1.  支援系統的平滑升級：已有的 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：

1.  支援 Strict/NonStrict 模式，解決大作業場景長時間得不到資源問題
1.  支援 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，可以方便的與大多數公司的組織結構對映，解決同部門內或者不同部門間的額度管理需求。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3a22d8d3e20745688f14e0ff1417284a~tplv-k3u1fbpfcp-zoom-1.image "5.png")

-   **Fine-grained Device Scheduling**

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

1.  支援 GPU 共享，GPU 獨佔，GPU 超賣
1.  支援百分比的 GPU 排程
1.  支援 GPU 多卡排程
1.  NVLink 拓撲感知排程（doing）

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b2b777e485c946f89361949c1cfdd243~tplv-k3u1fbpfcp-zoom-1.image "6.png")

### 差異化 SLO

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

-   **CPU Supress**

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

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bc458b21de1a473cb5540f5b29152177~tplv-k3u1fbpfcp-zoom-1.image "7.png")

-   **CPU Burst**

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

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f28528461d6d436493c1fbea6ad67904~tplv-k3u1fbpfcp-zoom-1.image "8.png")

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

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f514c102a5f34353999535416aaac26c~tplv-k3u1fbpfcp-zoom-1.image "9.png")

-   **基於記憶體安全閾值的主動驅逐機制**

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

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

-   **基於資源滿足的驅逐機制**

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

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/331fdeac59f14c61bde2a3161e86289a~tplv-k3u1fbpfcp-zoom-1.image "10.png")

為了解決這個問題，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 到冷節點機器出現一段時間後冷節點過熱的情況。

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/de2d16508c204a9fb0c0b4de80650048~tplv-k3u1fbpfcp-zoom-1.image "11.png")

-   **精細化 CPU 排程**

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

我們把 Koordinator QoS 線上應用 LS 型別做了更細緻的劃分，分為 LSE、LSR 和 LS 三種型別。拆分後的 QoS 型別具備更高的隔離性和執行時質量。透過這樣的拆分，整個 Koordinator QoS 語義更加精確和完整，並且相容 Kubernetes 已有的 QoS 語義。

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

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1a25159756734cffb6e2c28c35e14a11~tplv-k3u1fbpfcp-zoom-1.image "12.png")

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

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bf60fda3abe34e4391e3b47ed8f849dd~tplv-k3u1fbpfcp-zoom-1.image "13.png")

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）即可以預留資源。資源預留在容量管理、碎片最佳化、排程成功率和重排程等場景有重要作用：

1.  當有重要的工作負載在未來某段時間需要資源時，可以提前預留資源滿足需求。
1.  使用者在 PaaS 上發起擴容時，可以透過資源預留能力嘗試預留，預留成功後發起擴容，保障 PaaS 的 SLA。
1.  使用者在 PaaS 上釋出時，如果應用採用了滾動釋出的能力，可以透過資源預留保留即將銷燬的 Pod 持有的資源，在滾動釋出時，新建的 Pod 可以複用預留下來的原有資源，能夠有效提高滾動釋出的成功率。
1.  碎片最佳化場景中，可以透過資源預留佔住空閒的碎片資源，並把可被整理的 Pod 遷移到這些節點。
1.  重排程時在發起驅逐前，先嚐試預留資源，預留成功後發起驅逐，避免驅逐後無資源可用影響應用的可用性。

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b2dd49123b404701b04eae23d60839d5~tplv-k3u1fbpfcp-zoom-1.image "14.png")

-   **靈活可擴充套件且安全的重排程器**

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

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

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

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

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

2.  另外，社群重排程器呼叫的 Kubernetes Evcition API 雖然會檢查 PDB 確保在安全範圍內驅逐，但是眾所周知，眾多的 workload Controller 在釋出和縮容場景都是透過直接呼叫 Delete API 的形式銷燬 Pod，此時並不會被 PDB 限制。這就導致重排程時如果遇到上述場景，是很可能引發嚴重的穩定性問題。

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

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

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

1.  需要一個外掛化機制實現自定義的重排程策略，但又不希望這個抽象過於複雜；
1.  需要具備基本的外掛管理能力，透過配置啟用和禁用外掛；
1.  具備統一的外掛配置下發機制，方便外掛自定義引數；
1.  並能夠方便的擴充套件和使用統一的 Evictor 機制；
1.  另外期望使用者能夠基於 controller-runtime 實現 controller 並納入統一的外掛管理機制。

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

基於 Koordinator descheduler framework，使用者可以非常容易的擴充套件實現自定義重排程策略，就像基於 Kubernetes scheduling framework 的實現自定義的排程外掛一樣簡單。並且使用者也可以以外掛的形式實現 controller，支援基於 Event 觸發重排程的場景。

## Koordinator 的未來規劃

Koordinator 社群將不斷豐富大資料計算任務混部的形態，擴充包括 Hadoop YARN 等計算框架混部支援，豐富任務混部解決方案，專案上持續的完善干擾檢測、問題診斷體系，推進更多的負載型別融入 Koordinator 生態，並取得更好的資源執行效率。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/a0d98cc180474f0bbe963b315c01dd32~tplv-k3u1fbpfcp-zoom-1.image "15.png")

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

![16.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4ff158f7cab34195b4d17e410a55e7ac~tplv-k3u1fbpfcp-zoom-1.image "16.jpeg")

Koordinator 1.0 正式釋出：業界首個生產可用、面向規模場景的開源混部系統

相關文章