阿里巴巴雲原生混部系統Koordinator正式開源

脫胎於阿里巴巴內部，經過多年雙 11 打磨，為每年為公司節省數十億的混部系統 Koordinator 今天宣佈正式開源。透過開源，我們希望將更好的混部能力、排程能力開放到整個行業，幫助企業客戶改進雲原生工作負載執行的效率、穩定性和計算成本。

混部是什麼？

業界很多網際網路公司或多或少都有佈局將不同特徵型別工作負載協同排程的技術方向，充分利用負載之間的消峰填谷效應，讓工作負載以更穩定、更高效、更低成本的方式去使用資源。這樣的一套系統或機制，也就是業界時常提及的 “混部”概念。

阿里巴巴的混部：

阿里巴巴在 2011 年開始探索容器技術，並在 2016 年啟動混部技術研發，至今經過了多倫技術架構升級，最終演進到今天的雲原生混部系統架構，實現了全業務規模超千萬核的雲原生混部，混部天平均 CPU 利用率超 50%，幫助阿里巴巴節省了大量的資源成本。

混部是在網際網路企業內部重金打造的成本控制核心，凝聚了眾多的業務抽象和資源管理的思考最佳化經驗，因此混部通常都需要數年的打磨實踐才能逐漸穩定併產生生產價值。是不是每家企業都需要很高的門檻才能使用混部，都需要大量的投入才能產生價值？那讓我們的Koordinator來嘗試給出回答。

Koordinator 正是基於內部超大規模混部生產實踐經驗而來，旨在為使用者打造雲原生場景下接入成本最低、混部效率最佳的解決方案，幫助使用者企業實現雲原生後持續的紅利釋放。

一 Koordinator 是什麼？

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

谷歌內部有一個排程系統名叫 Borg，是最早做容器混部的系統，在其論文公開發表之前在行業上一直是非常神秘的存在。雲原生容器排程編排系統 Kubernetes 正是受 Borg 設計思想啟發，由 Borg 系統的設計者結合雲時代應用編排的需求重新設計而來。Kubernetes 良好的擴充套件性使其能適應多樣的工作負載，幫助使用者很好的解決工作負載日常運維效率。

Koordinator 是完全基於 Kubernetes 標準能力擴充套件而來，致力於解決多樣工作負載混部在一個叢集、節點場景下的排程、執行時效能以及穩定性挑戰。專案包含了混合工作負載編排的一套完整解決方案，包括精細化資源排程、任務排程、差異化 SLO 三大塊。透過這樣一套解決方案實現：

幫助企業使用者更多工作負載接入 kubernetes，特別是大資料、任務處理相關的工作負載，提高其執行效率和穩定性
透過開源技術標準，幫助企業使用者在雲上、雲下實現一致的技術架構，提升運維效率
幫助企業使用者合理利用雲資源，在雲上實現可持續發展

二 Koordinator 有什麼優勢？

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

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

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

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

1 超大規模生產實踐經驗錘鍊

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

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

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

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

回頭去看，阿里巴巴堅定的推進混部技術，主要是考慮到以下方面帶來的問題：

利用率不均衡：在非混部時代，幾大資源池之間的資源利用率不均衡，大資料資源池利用率極高長期缺乏算力，而電商資源池日常利用率比較低，空閒了大量的計算資源，但出於災備設計又不能直接下掉機器提高線上密度。混部的初衷是讓全域性資源排程更合理，在日常態透過混部將大資料的任務排程到電商資源池中，充分利用這部分空閒的資源。

大促備戰效率低：在大促時為了減少大促資源採購，希望在大促時能夠借用大資料資源池，部署電商任務支撐流量洪峰同時。在非混部時代，這樣的彈性資源借用只能透過騰挪機器的方式推進，大促支援的效率較低很難大規模實施。

正是在雙 11 這樣的峰值場景驅動之下，阿里的混部排程技術持續演進，積累了大量的生產實踐經驗，到今天已經是第三代即雲原生全業務混部系統。這樣一套基於雲原生理唸的混部技術解決方案，脫胎於阿里巴巴，希望透過開源社群輻射到整個行業，幫助企業在雲原生容器排程方向上加速快跑。

2 聚焦混部技術，支援豐富的場景

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

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

上圖是 Koordinator 混部資源超賣模型，也是混部最關鍵最核心的地方。其中超賣的基本思想是去利用那些已分配但未使用的資源來執行低優先順序的任務，如圖所示的四條線分別是：

limit: 灰色，高優先順序 Pod 申請的資源量，對應 kubernetes 的 Pod request
usage: 紅色，Pod 實際使用的資源量，橫軸是時間線，紅線也就是 Pod 負載隨時間的波動曲線
short-term reservation: 深藍色，是基於 usage 過去一段時間（較短）的資源使用情況，對其未來一段時間的資源使用情況的預估，reservation 與 limit 之間也就是已分配未使用（預估未來一段時間也不會使用）的資源，可以用於執行短生命週期批處理任務
long-term reservation: 淺藍色，類似於 short-term reservation 但預估使用的歷史週期較長，從 reservation 到 limit 之間的資源可用於較長生命週期的任務，其可用資源相比 short-term 更少但穩定性更高

這一套資源模型支撐了阿里巴巴內部全業務的混部，足夠精煉的同時也具備很強的靈活性。Koordinator 整個混部資源排程的大廈構建在這樣一個資源模型的基礎之上，配合上優先順序搶佔、負載感知、干擾識別和 QoS 保障技術，構建出混部資源排程底層核心系統。Koordinator 社群將圍繞這個思路投入建設，持續將混部場景的排程能力展開，將阿里巴巴內部豐富場景支援的經驗輸出到社群，解決企業面臨的真實業務場景問題。

3 雙零傾入，超低接入成本

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

第一個零傾入，是指對 Kubernetes 平臺的零傾入。行業內的人大多知道，將 Kubernetes 應用於企業內部的複雜場景混部時，因為這樣或者那樣的原因總是需要對 Kubernetes 做一定量的修改，特別是節點管理（Kubelet）部分，這部分修改本身具備較大的技術門檻，同時也為給後續的 Kubernetes 版本升級帶來巨大的挑戰。企業為了解決這一問題，往往需要專門的團隊來維護這一些定製化的修改，並且具備很大的沉默成本，等到線上出現問題或者需要升級新版本時，熟悉這份修改的同學可能已不知去向。這給企業帶來了很大的技術風險，往往讓混部技術的推廣受阻。而 Koordinator 混部系統，設計之處即保證了不需要對社群原生 Kubernetes 做任何修改，只需要一鍵安裝 Koordinator 元件到叢集中，不需要做任何配置，既可以為 Kubernetes 叢集帶來混部的能力。同時，在使用者不啟用混部能力時，不會對原有的 Kubernetes 叢集有任何形式的打擾。

第二個零傾入，是指對工作負載編排系統的零傾入。想像一下，在企業內部的 Kubernetes 叢集之上提供混部能力之後，將面臨的問題是如何將企業的工作負載接入進來，以混部的方式執行。一般情況下將會面臨的兩種情況是：

工作負載具備企業私有運維特性，由平臺或運維團隊的系統管理這些工作負載的日常升級釋出、擴容縮容，而企業推進混部的容器或 SRE 團隊與平臺運維團隊之間，存在著組織的鴻溝（或大或小），如何推動平臺團隊改造工作負載管理機制，對接混部的協議，也是一個不小的挑戰。
工作負載以原生的 Deployment/StatefulSet/Job 的方式管理，對其 Kubernetes 內部的設計實現或改造成本超出了團隊的預期，也將成為推行混部的挑戰。

Koordinator 針對應用接入層的改造成本，設計了單獨的工作負載接入層（Colocation Profile），幫助使用者解決工作負載接入混部的難題，使用者只需要管理混部的配置（YAML）即可靈活的排程編排哪些任務以混部的方式執行在叢集中，非常的簡單且靈活。當前 Koordinator 為使用者提供了混跑 Spark 任務的樣例，未來，社群將持續豐富工作負載接入層的特性，支援更多場景的零傾入接入。

4 雲上、雲下一致的使用者體驗

Koordinator 開源專案是阿里巴巴雲原生 2.0 的重點戰役，使用者除在自己的環境中可以體驗到 Koordinator 混部帶來的技術紅利，也可以將其部署到任意一個雲廠商中，保持混合雲、多雲的架構一致。當然，也可以在阿里巴巴提供的多款雲產品中獲得一致的使用者體驗，一次設計對接多處發揮價值。

可以看到，除了支援內部超大規模的業務混部外，Koordinator 也是阿里雲容器服務整合的解決方案，社群將持續的保持活力，致力於將混部變成平民化、通用化、標準化的技術能力。

三為什麼要開源？

最早做容器混部的是 Borg，在 Google 內部執行超過 15 年，最新公開的資料是 Borg: the next Generation[1]。國內網際網路公司內部推進混部接近 10 年，其中阿里巴巴的混部技術也經歷過了 3 代技術架構升級變遷，最終走到全域性混部的終極形態。混部幫助阿里巴巴的電商、搜尋、大資料業務極大的提高了大促的備戰效率，也為歷年的雙 11 大促節省了大量的計算資源。

我們堅信，雲原生混部是企業容器排程技術發展的必然方向，只有透過工作負載的混合編排，才能在業務多可用區災備架構下實現更好的資源利用效率，才能充分的發揮不同型別負載的消峰填谷效應，從而完全的發揮出計算資源潛力，最大化釋放雲計算的價值。

Koordinator 的開源，希望讓更多的企業能夠看見並用上雲原生混部的能力，幫助企業加速雲原生化的過程。在技術上，Koordinator 能夠幫助企業實現更多的負載能夠接入到 Kubernetes 平臺，豐富容器排程的工作負載型別，繼而發揮出工作負載錯峰分時的特徵，從而實現效率、成本上的收益，保持長期可持續發展的健康形態。

當前，Koordinator 已經支援了 Spark 任務場景的混部，同時也提供了低成本接入混部的解決方案，期待看到你的混部應用案例，聽到你的反饋！未來，Koordinator 社群將持續的豐富混部的場景及業務形態，支援 Flink、Hadoop、AI Jobs、音視屏任務等，盡情期待。