2022年4月6日，阿里云原生混部系統 Koordinator 宣布正式開源。據介紹，Koordinator沉淀于阿里巴巴內部多年大規模應用實踐，在2021年“雙11”計算成本下降50% 中起到了關鍵作用。這個來自于阿里巴巴的大規模實踐項目到底是什么？它的發展背景、技術原理及開源規劃是怎樣的？阿里內部又是如何利用混部技術解決“雙11”等極端場景下的資源挑戰的？

不久前，在【T·TALK】系列活動的第五期中，懿川、曾凡松、楊國東三位阿里技術專家，從 Koodinator 項目出發，為我們分享了混部的技術背景、落地經驗以及對混部技術未來演進的思考與前瞻。【T·TALK】也將本次直播的核心內容進行了整理，希望能給大家帶來一些不同的思考與啟發：

混部技術概念

混部概念可以從兩方面進行理解：從節點粒度的角度來看，混部就是將多個容器或多種應用部署在同一節之上。其中，多個容器包括，多個在線容器、多個離線容器與多個離在線容器三種形態，并不僅限于常規理解中的離線容器。單個節點，則是能夠運行容器的最小單位，包含物理機、單個 ECS 等。

另一方面，從集群粒度的定義出發，多種應用在一個集群內自動部署，通過預測分析應用特性，實現業務間的錯峰填谷，這便是混部。總的來說，混部所希望實現的是，利用更少的資源運行所有任務，以達到降本增效的終極目標。

通過上述混部的定義，我們可以梳理出混部的兩項核心技術。

1、節點粒度

• 容器隔離技術：包括依賴內核的袋鼠、RunC 等；
• 單機調度技術：包括單機的負載感知，容器策略和閾值設置，容器優先   級和伸縮控制、cpushare 等；
• 中心調度技術：支持單機粒度的負載反饋、調度策略、調度性能等；
• 資源的差異化 SLO 技術：包括差異化 SLO 設定，優先級設定，基于   差異化SLO 的單機和中心調度配合。

2、集群粒度：基于節點粒度之上實現

• 中心調度技術：高性能調度、資源視圖、多負載的調度協同、GPU 拓撲   感知等；
• 單機調度技術：任務的高頻起停控制，單機多環境、硬件適配、cpu 歸   一化等；
• k8s 生態框架優化和配套能力建設：包括集群規模突破、穩定性改進、   運維配套能力、界面和接口能力、業務對接等。

阿里作為業界混部技術的先行者之一，在 2011 年便開始探索容器技術，并在2016 年啟動了混部技術研發，至今經歷了多輪技術架構升級，最終演進到今天的云原生混部系統架構，直接采用基于 K8S 的云原生統一調度來實現多任務、多負載的協同感知，實現整個混部的效果。這也是目前經過驗證的、最理想的架構和最好的工程實現。

如今，業界許多企業都在關注混部，希望能夠快捷地獲取到混部所帶來的收益。對此，第一種解決方案便是直接采用公有云或商業化的產品，這部分會默認攜帶一些混部和彈性能力的支持。第二種解決方案則是開源共建，這種方式既能夠保證團隊自建的效果，又可以借助開源社區所積累的各層技術棧的經驗，這也是目前比較推薦的一種方案。

阿里云原生混部系統Koordinator

Koordinator 是脫胎于阿里巴巴內部的混部系統，已于2022年4月6日正式開源（??https://koordinator.sh??）。Koordinator 的技術基礎和整套系統設計思路均來源于阿里內部的多年實踐經驗。阿里希望通過開源去推進整個混部技術的標準化，讓更多用戶能夠應用混部并從中受益。

目前 Koordinator 項目中包含的內容分為三部分：

• 差異化 SLO：在 Kubernetes 之上抽象一套面向QoS的資源調度機制，同時在優先級內部劃分不同的 QoS，并保障每一個優先級與 QoS 的資源特性；
• 資源精細化調度：阿里巴巴的最佳實踐，其中包括 CPU 拓撲感知、性能優化調度、資源預留、交互式搶占、碎片整理、資源預覽、GPU 共享調度以及算力歸一化等；
• 任務調度：大數據與 AI 相關的任務調度，比如 Gang、批量、優先級搶占以及彈性 Quota（隊列間借用）等，從而更好地去應用整個集群資源。

從整體架構的角度分析，Koordinator 項目的技術同樣分為三大模塊：最底層為Koordlet 模塊，負責對應單機的一些技術能力，例如特征感知、單機級別干擾監測以及一些 QoS 管理與單機資源隔離。

當然，Koordinator 組件在單機上還會擴展出一些運行時的管理者角色，以幫助適配各種不同的運行時，同時避免對底層基礎組件的侵入式修改。

中心端有兩個主要角色，第一部分是 Koordinator Scheduler，其中包含調度特性與從調度特性。雖然在一般情況下，做調度的概率會遠高于做從調度的概率，但從調度在混部項目中也是非常關鍵的一環，能夠保證整個集群資源的運行質量持續保持較高的水準。

第二部分是 Koordinator Manager，這一組件主要用于混部策略的管理，包括如何對工作負載進行接入。此外，Koordinator Manager 中還集成了一個資源畫像模塊，目的是為了更好地支持調度器，做更好的資源打散，避免局部的機器出現熱點，從而導致服務受損。

以上便是 Koordinator 的整體架構。上述這些模塊的核心目標是希望幫助大家解決混部的兩大核心問題：第一個問題是如何將混部工作負載進行接入，讓各類任務能夠以最低成本的方式接入到 Koordinator 混部的框架之中；第二個問題則是如何讓各類任務在混部時各自良好運行，讓計算任務能夠獲得所需的算力，讓在線任務的運行延遲不受影響。

作為目前較為成熟的混部系統，Koordinator 有“雙零入侵”的特性。第一，Koordinator 對應用的工作負載管理是零侵入的。Koordinator 會投大量精力，幫助用戶將典型計算類負載的混部鏈路打通，用戶只需要進行簡單的配置、Koordinator 會 apply 一些配置的 yaml，就可以自動將計算的任務轉化成混部的任務，從而避免對這些計算框架進行修改，這可以幫助到用戶更快將混部落地到企業內部場景之中。

第二個零入侵指，Koordinator 對 Kubernets 是沒有入侵的。在 Koordinator支持的 Kubernetes 版本上，用戶可以將開源組件安裝到自己的 Kubernetes 集群，去獲得對應能力。Kubernetes 的擴展性在中心端是很好的，但是在節點端擴展性較差，因此在 Koordinator 項目的 Kubelet 和底層的容器運行池之間存在 Hook Manager，用來支持策略的擴展，從而避免對 Kubelet 以及底層的Containerd 或者 Docker 的侵入式修改。

整個混部之中，最重要的就是資源模型。做混部最本質的就是做出差異化能力，這樣才能夠進行資源超發，才能夠提高資源的利用率，這一系列過程是倒推得來的。Koordinator 定義的資源模型是非常完備的，能夠支持在線服務、實時計算、AI 訓練任務、批處理計算任務，甚至一些測試任務都可以通過這套資源模型去滿足。

此外，Koordinator也提供了各種資源維度的資源隔離技術，例如 CPU cquset、LLC 的一些隔離能力以及操作系統提供的優先級搶占能力等等。這些隔離能力未來都會在 Koordinator 社區中呈現，大家會逐漸看到這些隔離能力，以及針對不同資源特性實現的干擾檢測能力。

Koordinator 是基于 Kubernetes 社區的，但 Koordinator 不會對 Kubernetes社區做任何修改，用戶在運用混部技術時，首先會應用到 Kubernets，而后在Kubernets 之上去安裝 Koordinator 對應的組件，這是 Koordinator 上下游的關系狀況。

Koordinator 社區所提供的能力與企業內部真實環境的需求能力之間可能會有一些差異。用戶可以基于社區使用自己內部的版本，結合企業特性去兼容一些舊的場景，通過這種方式，能夠跟整個 Koordinator 社區更好的協作。Koordinator 社區會非常快的迭代，在這種模式下，用戶可以不斷從社區拿到新的特性，并且只需要在內部版本中維護自身企業非特殊化的部分即可。

如今，阿里巴巴已經基本實現了全量混部的覆蓋，也通過自身實踐證明了，混部技術能夠給企業帶來很大價值。阿里希望通過開源推進混部技術的標準化，讓更多用戶能夠更簡便地應用混部技術，并從中獲得收益。未來，Koordinator 社區也將定義一些不同的角色，也非常歡迎大家參與其中，持續通過開源去做更多的貢獻。

混部實踐與發展前瞻

阿里巴巴集團有兩個比較典型的混部場景，一部分是常態化的，日常主要的混部利用是在容災的余量，阿里希望能夠把容災的余量用來進行大數據計算，這樣能夠提高整體資源的利用率。

另一部分就是“雙11”這類應用場景，阿里的在線流量大概是日常的十倍量級。按照傳統的資源準備方式，需要準備十倍的機器來支持大促的資源需求。但阿里將 MaxCompute 、批處理以及非實時任務作為離線任務，通過大量的降級，將資源釋放給在線業務，以實現大促資源采購的降低。

結合阿里巴巴的技術發展來看，混部的適用環境可以抽象為幾點：其一，企業的工作負載應該是多樣化的；其二，當企業的流量與業務達到一定規模時，才有對資源彈性的需求，才更需要考慮降本增效。對于初期或規模不大的場景，使用 ECS 的彈性基本就能夠享受到混部以及彈性的優勢。

混部技術是一個系統工程，是從硬件到操作系統的調度，需要協同優化。從阿里集團的資源利用率提升階段看，當資源利用率從 10% 提升為 30% 時，這一階段的技術門檻是相對較低的，通過類似于K8S調度以及基礎混部能力，便能夠實現整體負載的提升，這一階段對大部分企業都是適用的。

但如果將混部的水位從 30% 提升到 50%，其中的挑戰還是很大的。阿里混部技術一路演進過來，在計算、存儲、網絡等方面都做了很多升級。但到目前為止，這些依然不能夠滿足我們對混部以及彈性的資源模型。這時，需要依靠應用架構的改進，例如，阿里將業務架構去掉了本地盤，將 IO 隔離的問題轉化成了網絡隔離問題等，這些是全鏈路需要在應用側去配合的，這樣才能切實提高利用率。

此外，在集群的混部本身其實也有著很高的門檻。基于簡單的 workload，可以按照4核或8核16G標準規格去調度。但隨著混部的 workload 復雜度提升，資源規格的多樣性，將分配問題變成了一個 NP 問題，此時要解決好專項問題，則需要使用一些較為復雜的、類似于決策智能的問題求解算法，以及在做混部的過程中如何做好應用畫像，這些都是需要打磨的。

可以看到，混部是一個很大的系統工程。今天，阿里通過開源，將過往在混部落地中所踩過的坑以及所積累的經驗，都呈現給了大家，也希望今后有更多的伙伴能夠加入進來，在收獲混部效益的同時，發掘更有深度的技術，共建混部技術生態。