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

不久前，在【T·TALK】系列活動的第五期中，懿川、曾凡松、楊國東三位阿里技術(shù)專家，從 Koodinator 項目出發(fā)，為我們分享了混部的技術(shù)背景、落地經(jīng)驗以及對混部技術(shù)未來演進(jìn)的思考與前瞻?！綯·TALK】也將本次直播的核心內(nèi)容進(jìn)行了整理，希望能給大家?guī)硪恍┎煌乃伎寂c啟發(fā)：

混部技術(shù)概念

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

另一方面，從集群粒度的定義出發(fā)，多種應(yīng)用在一個集群內(nèi)自動部署，通過預(yù)測分析應(yīng)用特性，實現(xiàn)業(yè)務(wù)間的錯峰填谷，這便是混部?？偟膩碚f，混部所希望實現(xiàn)的是，利用更少的資源運行所有任務(wù)，以達(dá)到降本增效的終極目標(biāo)。

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

1、節(jié)點粒度

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

2、集群粒度：基于節(jié)點粒度之上實現(xiàn)

• 中心調(diào)度技術(shù)：高性能調(diào)度、資源視圖、多負(fù)載的調(diào)度協(xié)同、GPU 拓?fù)?  感知等；
• 單機調(diào)度技術(shù)：任務(wù)的高頻起?？刂疲瑔螜C多環(huán)境、硬件適配、cpu 歸   一化等；
• k8s 生態(tài)框架優(yōu)化和配套能力建設(shè)：包括集群規(guī)模突破、穩(wěn)定性改進(jìn)、   運維配套能力、界面和接口能力、業(yè)務(wù)對接等。

阿里作為業(yè)界混部技術(shù)的先行者之一，在 2011 年便開始探索容器技術(shù)，并在2016 年啟動了混部技術(shù)研發(fā)，至今經(jīng)歷了多輪技術(shù)架構(gòu)升級，最終演進(jìn)到今天的云原生混部系統(tǒng)架構(gòu)，直接采用基于 K8S 的云原生統(tǒng)一調(diào)度來實現(xiàn)多任務(wù)、多負(fù)載的協(xié)同感知，實現(xiàn)整個混部的效果。這也是目前經(jīng)過驗證的、最理想的架構(gòu)和最好的工程實現(xiàn)。

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

阿里云原生混部系統(tǒng)Koordinator

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

目前 Koordinator 項目中包含的內(nèi)容分為三部分：

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

從整體架構(gòu)的角度分析，Koordinator 項目的技術(shù)同樣分為三大模塊：最底層為Koordlet 模塊，負(fù)責(zé)對應(yīng)單機的一些技術(shù)能力，例如特征感知、單機級別干擾監(jiān)測以及一些 QoS 管理與單機資源隔離。

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

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

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

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

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

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

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

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

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

Koordinator 社區(qū)所提供的能力與企業(yè)內(nèi)部真實環(huán)境的需求能力之間可能會有一些差異。用戶可以基于社區(qū)使用自己內(nèi)部的版本，結(jié)合企業(yè)特性去兼容一些舊的場景，通過這種方式，能夠跟整個 Koordinator 社區(qū)更好的協(xié)作。Koordinator 社區(qū)會非?？斓牡?，在這種模式下，用戶可以不斷從社區(qū)拿到新的特性，并且只需要在內(nèi)部版本中維護(hù)自身企業(yè)非特殊化的部分即可。

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

混部實踐與發(fā)展前瞻

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

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

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

混部技術(shù)是一個系統(tǒng)工程，是從硬件到操作系統(tǒng)的調(diào)度，需要協(xié)同優(yōu)化。從阿里集團(tuán)的資源利用率提升階段看，當(dāng)資源利用率從 10% 提升為 30% 時，這一階段的技術(shù)門檻是相對較低的，通過類似于K8S調(diào)度以及基礎(chǔ)混部能力，便能夠?qū)崿F(xiàn)整體負(fù)載的提升，這一階段對大部分企業(yè)都是適用的。

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

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

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