簡介：脱胎於阿里巴巴內部，經過多年雙 11 打磨，每年為公司節省數十億的混部系統 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、音視頻任務等，盡情期待。
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。
