脫胎于阿里巴巴內部，經(jīng)過多年雙 11 打磨，每年為公司節(jié)省數(shù)十億成本的混部系統(tǒng) Koordinator 今天宣布正式開源。通過開源，我們希望將更好的混部能力、調度能力開放到整個行業(yè)，幫助企業(yè)客戶改進云原生工作負載運行的效率、穩(wěn)定性和計算成本。

混部是什么

業(yè)界很多互聯(lián)網(wǎng)公司或多或少都有在不同特征類型工作負載協(xié)同調度的技術方向進行布局，充分利用負載之間的消峰填谷效應，讓工作負載以更穩(wěn)定、更高效、更低成本的方式去使用資源。這樣的一套系統(tǒng)或機制，也就是業(yè)界時常提及的 “混部”概念。

阿里巴巴的混部

阿里巴巴在 2011 年開始探索容器技術，并在 2016 年啟動混部技術研發(fā)，至今經(jīng)過了多輪技術架構升級，最終演進到今天的云原生混部系統(tǒng)架構，實現(xiàn)了全業(yè)務規(guī)模超千萬核的云原生混部，混部的日平均 CPU 利用率超 50%，幫助阿里巴巴節(jié)省了大量的資源成本。

混部是在互聯(lián)網(wǎng)企業(yè)內部重金打造的成本控制內核，凝聚了眾多業(yè)務抽象和資源管理的思考優(yōu)化經(jīng)驗，因此混部通常都需要數(shù)年的打磨實踐才能逐漸穩(wěn)定并產(chǎn)生生產(chǎn)價值。那么，是不是每家企業(yè)都需要很高的門檻才能使用混部，都需要大量的投入才能產(chǎn)生價值？Koordinator 來嘗試給出回答。Koordinator 基于內部超大規(guī)模混部生產(chǎn)實踐經(jīng)驗，旨在為用戶打造云原生場景下接入成本最低、混部效率最佳的解決方案，幫助用戶企業(yè)實現(xiàn)云原生后持續(xù)的紅利釋放。

Koordinator 是什么？

Koordinator: 取自 coordinator，K for Kubernetes，發(fā)音相同。語意上契合項目要解決的問題，即協(xié)調編排 kubernetes 集群中不同類型的工作負載，使得他們以最優(yōu)的布局、最佳的姿態(tài)在一個集群、一個節(jié)點上運行。

谷歌內部有一個調度系統(tǒng)名叫 Borg，是最早做容器混部的系統(tǒng)，其論文公開發(fā)表之前在行業(yè)上一直是非常神秘的存在。云原生容器調度編排系統(tǒng) Kubernetes 正是受 Borg 設計思想啟發(fā)，由 Borg 系統(tǒng)的設計者結合云時代應用編排的需求重新設計而來。Kubernetes 良好的擴展性使其能適應多樣的工作負載，幫助用戶很好地提升工作負載的日常運維效率。

Koordinator 是完全基于 Kubernetes 標準能力擴展而來，致力于解決多樣工作負載混部在一個集群、節(jié)點場景下的調度，運行時性能以及穩(wěn)定性挑戰(zhàn)。項目包含了混合工作負載編排的一套完整解決方案，包括精細化資源調度、任務調度、差異化 SLO 三大塊。通過這樣一套解決方案實現(xiàn)：

1. 幫助企業(yè)用戶更多工作負載接入 kubernetes，特別是大數(shù)據(jù)、任務處理相關的工作負載，提高其運行效率和穩(wěn)定性；
2. 通過開源技術標準幫助企業(yè)用戶在云上、云下實現(xiàn)一致的技術架構，提升運維效率；
3. 幫助企業(yè)用戶合理利用云資源，在云上實現(xiàn)可持續(xù)發(fā)展。

Koordinator 有什么優(yōu)勢？

混部需要一套完整、自閉環(huán)的調度回路，但在企業(yè)應用混部的過程中，將要面臨的兩大挑戰(zhàn)是：應用如何接入到混部平臺，應用如何在平臺上穩(wěn)定高效運行。

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

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

超大規(guī)模生產(chǎn)實踐經(jīng)驗錘煉

2021 雙 11 之后阿里對外宣布了“首次！統(tǒng)一調度系統(tǒng)規(guī)?；涞?，全面支撐阿里巴巴雙 11 全業(yè)務”。作為阿里巴巴的核心項目，阿里云（容器團隊和大數(shù)據(jù)團隊）聯(lián)合阿里巴巴資源效能團隊、螞蟻容器編排團隊，歷時一年多研發(fā)和技術攻堅，實現(xiàn)了從“混部技術”到“統(tǒng)一調度技術”的全面升級。

目前，統(tǒng)一調度已實現(xiàn)阿里巴巴電商、搜推廣、MaxCompute 大數(shù)據(jù)的調度全面統(tǒng)一，實現(xiàn)了 pod 調度和 task 高性能調度的統(tǒng)一，實現(xiàn)了完整的資源視圖統(tǒng)一和調度協(xié)同，實現(xiàn)了多種復雜業(yè)務形態(tài)的混部和利用率提升，全面支撐了全球數(shù)十個數(shù)據(jù)中心、數(shù)百萬容器、數(shù)千萬核的大規(guī)模資源調度。

作為云原生混部的踐行者，阿里巴巴是真刀真槍地在生產(chǎn)環(huán)境中推進混部技術理念，并在去年雙 11 完成了超過千萬核的混部規(guī)模，通過混部技術幫助阿里巴巴雙 11 節(jié)約超過 50% 的大促資源成本，在大促快上快下鏈路上提速 100%。

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

• 利用率不均衡：在非混部時代，幾大資源池之間的資源利用率不均衡，大數(shù)據(jù)資源池利用率極高，但長期缺乏算力；電商資源池日常利用率比較低，空閑了大量的計算資源，但出于災備設計又不能直接下掉機器提高在線密度?；觳康某踔允亲屓仲Y源調度更合理，在日常態(tài)通過混部將大數(shù)據(jù)的任務調度到電商資源池中，充分利用這部分空閑的資源。
• 大促備戰(zhàn)效率低：在大促時為了減少資源采購，希望在大促時能夠借用大數(shù)據(jù)資源池，部署電商任務支撐流量洪峰。在非混部時代，這樣的彈性資源借用只能通過騰挪機器的方式推進，大促支持的效率較低很難大規(guī)模實施。

正是在雙 11 這樣的峰值場景驅動之下，阿里的混部調度技術持續(xù)演進，積累了大量的生產(chǎn)實踐經(jīng)驗，到今天已經(jīng)是第三代即云原生全業(yè)務混部系統(tǒng)。這樣一套基于云原生理念的混部技術解決方案，脫胎于阿里巴巴，希望通過開源社區(qū)輻射到整個行業(yè)，幫助企業(yè)在云原生容器調度方向上加速快跑。

聚焦混部技術，支持豐富場景

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

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

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

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

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

雙零侵入，超低接入成本

企業(yè)接入混部最大的挑戰(zhàn)是如何讓應用跑在混部平臺之上，第一步的門檻往往是最大的攔路虎。Koordinator 針對這一問題，結合內部生產(chǎn)實踐經(jīng)驗，設計了“雙零侵入”的混部調度系統(tǒng)。

第一個零侵入，是指對 Kubernetes 平臺的零侵入。行業(yè)內的人大多知道，將 Kubernetes 應用于企業(yè)內部的復雜場景混部時，因為這樣或者那樣的原因總是需要對 Kubernetes 做一定量的修改，特別是節(jié)點管理（Kubelet）部分，這部分修改本身具備較大的技術門檻，同時也為給后續(xù)的 Kubernetes 版本升級帶來巨大的挑戰(zhàn)。企業(yè)為了解決這一問題，往往需要專門的團隊來維護這一些定制化的修改，并且具有很大的沉沒成本，等到線上出現(xiàn)問題或者需要升級新版本時，熟悉這份修改的同學可能已不知去向。這給企業(yè)帶來了很大的技術風險，往往讓混部技術的推廣受阻。而 Koordinator 混部系統(tǒng)，設計之初即保證了不需要對社區(qū)原生 Kubernetes 做任何修改，只需要一鍵安裝 Koordinator 組件到集群中，不需要做任何配置，既可以為 Kubernetes 集群帶來混部的能力。同時，在用戶不啟用混部能力時，不會對原有的 Kubernetes 集群有任何形式的打擾。

第二個零侵入，是指對工作負載編排系統(tǒng)的零侵入。想象一下，在企業(yè)內部的 Kubernetes 集群之上提供混部能力之后，面臨的問題是如何將企業(yè)的工作負載接入進來以混部的方式運行。一般情況下將會面臨的兩種情況是：

1. 工作負載具備企業(yè)私有運維特性，由平臺或運維團隊的系統(tǒng)管理這些工作負載的日常升級發(fā)布、擴容縮容，而企業(yè)推進混部的容器或 SRE 團隊與平臺運維團隊之間，存在著組織的鴻溝（或大或?。绾瓮苿悠脚_團隊改造工作負載管理機制，對接混部的協(xié)議，也是一個不小的挑戰(zhàn)。
2. 工作負載以原生的 Deployment/StatefulSet/Job 的方式管理，對其 Kubernetes 內部的設計實現(xiàn)或改造成本超出了團隊的預期，也將成為推行混部的挑戰(zhàn)。

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

云上、云下一致的用戶體驗

Koordinator 開源項目是阿里巴巴云原生 2.0 的重點戰(zhàn)役，用戶除了在自己的環(huán)境中可以體驗到 Koordinator 混部帶來的技術紅利，也可以將其部署到任意一個云廠商中，保持混合云、多云的架構一致。當然，也可以在阿里巴巴提供的多款云產(chǎn)品中獲得一致的用戶體驗，一次設計對接多處發(fā)揮價值。

可以看到，除了支持內部超大規(guī)模的業(yè)務混部外，Koordinator 也是阿里云容器服務集成的解決方案，社區(qū)將持續(xù)的保持活力，致力于將混部變成平民化、通用化、標準化的技術能力。

為什么要開源？

最早做容器混部的是 Borg， 在 Google 內部運行超過 15 年，最新公開的資料是 Borg: the next Generation[1]。國內互聯(lián)網(wǎng)公司內部推進混部接近 10 年，其中阿里巴巴的混部技術也經(jīng)歷過了 3 代技術架構升級變遷，最終走到全局混部的終極形態(tài)?；觳繋椭⒗锇桶偷碾娚獭⑺阉?、大數(shù)據(jù)業(yè)務極大提高了大促的備戰(zhàn)效率，也為歷年的雙 11 大促節(jié)省了大量的計算資源。

我們堅信，云原生混部是企業(yè)容器調度技術發(fā)展的必然方向，只有通過工作負載的混合編排，才能在業(yè)務多可用區(qū)災備架構下實現(xiàn)更好的資源利用效率，才能充分發(fā)揮不同類型負載的削峰填谷效應，從而完全發(fā)揮出計算資源潛力，最大化釋放云計算的價值。

Koordinator 的開源，希望讓更多的企業(yè)能夠看見并使用云原生混部的能力，幫助企業(yè)加速云原生化的過程。在技術上，Koordinator 能夠幫助企業(yè)實現(xiàn)更多的負載接入到 Kubernetes 平臺，豐富容器調度的工作負載類型，繼而發(fā)揮出工作負載錯峰分時的特征，從而實現(xiàn)效率、成本上的收益，保持長期可持續(xù)發(fā)展的健康形態(tài)。

當前，Koordinator 已經(jīng)支持了 Spark 任務場景的混部，同時也提供了低成本接入混部的解決方案。后續(xù)，也非常期待看到大家的混部應用案例，聽到大家的反饋！未來，Koordinator 社區(qū)將持續(xù)豐富混部的場景及業(yè)務形態(tài)，支持 Flink、Hadoop、AI Jobs、音視頻任務等，敬請期待。

加入 Koordinator 社區(qū)

• 你是否正在規(guī)劃或者正在實施提升 Kubernetes 集群資源利用率的項目？
• 你是否正在頭痛 Kubernetes 集群上 Pod 運行時資源穩(wěn)定性、性能調優(yōu)的問題？
• 你是否正在經(jīng)歷云上、云下調度體系不一致帶來的多倍復雜性？

非常歡迎你參與 Koordinator 開源社區(qū)，我們期待聽到你的聲音：

• Github 地址：

https://github.com/koordinator-sh/koordinator

• 加入社區(qū) Slack channel（English）：

https://koordinatorgroup.slack.com/archives/C0392BCPFNK

• 參考鏈接

[1]:https://research.google/pubs/pub49065

阿里巴巴云原生混部系統(tǒng) Koordinator 正式開源