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

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

混部技術(shù)概念

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

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

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

1、節(jié)點(diǎn)粒度

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

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

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

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

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

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

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

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

• 差異化 SLO：在 Kubernetes 之上抽象一套面向QoS的資源調(diào)度機(jī)制，同時(shí)在優(yōu)先級(jí)內(nèi)部劃分不同的 QoS，并保障每一個(gè)優(yōu)先級(jí)與 QoS 的資源特性；
• 資源精細(xì)化調(diào)度：阿里巴巴的最佳實(shí)踐，其中包括 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)先級(jí)搶占以及彈性 Quota（隊(duì)列間借用）等，從而更好地去應(yīng)用整個(gè)集群資源。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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