根據(jù) Gartner 預(yù)測(cè)數(shù)據(jù)顯示：2024 年全球 IT 支出預(yù)計(jì)將達(dá)到 5.1 萬(wàn)億美元，比 2023 年增長(zhǎng) 8 %。然而，該機(jī)構(gòu)的另一項(xiàng)調(diào)查數(shù)據(jù)顯示：全球數(shù)據(jù)中心服務(wù)器平均 CPU 利用率普遍低于 20%，存在巨大的資源浪費(fèi)。據(jù)測(cè)算，以數(shù)百萬(wàn)核 CPU 規(guī)模的數(shù)據(jù)中心為例，每提升 1 個(gè)百分點(diǎn)的整體資源利用率，每年將節(jié)省數(shù)千萬(wàn)元的成本。由此可見(jiàn)，提高資源利用率對(duì)于降低企業(yè)運(yùn)營(yíng)成本具有顯著的效果。

早在 2015 年，谷歌就在其經(jīng)典論文《Large-scale cluster management at Google with Borg》中披露了它在資源管理和調(diào)度方面的實(shí)踐經(jīng)驗(yàn)，是最早通過(guò)混部技術(shù)來(lái)提升資源利用率的公司之一。國(guó)內(nèi)多家頭部互聯(lián)網(wǎng)企業(yè)也相繼實(shí)施類(lèi)似的技術(shù)方案，并取得可觀的資源利用率提升效果。

隨著小紅書(shū)業(yè)務(wù)的高速發(fā)展，各類(lèi)在線、離線業(yè)務(wù)對(duì)計(jì)算資源的需求日益增長(zhǎng)。與此同時(shí)，我們觀察到：部分在線集群天均利用率的水位卻維持在較低的水平。造成這一現(xiàn)象的主要原因有以下幾點(diǎn)：

• 在線服務(wù)資源使用量隨著終端用戶的使用習(xí)慣呈現(xiàn)穩(wěn)定的潮汐現(xiàn)象，夜間 CPU 利用率極低，從而導(dǎo)致整個(gè)集群的均值 CPU 利用率降低。
• 業(yè)務(wù)保有大量的獨(dú)占資源池，資源池割裂產(chǎn)生大量的資源碎片，進(jìn)而降低 CPU 的利用率。
• 出于穩(wěn)定性考慮，業(yè)務(wù)傾向于過(guò)量?jī)?chǔ)備資源，進(jìn)一步降低 CPU 的利用率。

基于以上背景，為了幫助業(yè)務(wù)降低資源使用成本，小紅書(shū)容器團(tuán)隊(duì)從 2022 年開(kāi)始規(guī)模化落地混部技術(shù)，提升集群 CPU 利用率。截止目前，混部集群 CPU 利用率均值可達(dá) 45% 以上，為業(yè)務(wù)提供數(shù)百萬(wàn)核時(shí)的算力成本優(yōu)化。

1、技術(shù)演進(jìn)

小紅書(shū)混部技術(shù)演進(jìn)分為以下四個(gè)階段(如圖所示)：

階段一：閑置資源再利用

在早期，小紅書(shū)的集群資源管理相對(duì)粗放，集群中存在大量業(yè)務(wù)獨(dú)占的資源池。由于資源碎片化等因素，各個(gè)集群中存在許多低分配率的低效節(jié)點(diǎn)，導(dǎo)致大量資源浪費(fèi)。同時(shí)，基于 Kubernetes(K8s)發(fā)布的轉(zhuǎn)碼類(lèi)近線/離線場(chǎng)景，在全天時(shí)段均存在大量計(jì)算資源需求。基于以上背景，小紅書(shū)容器平臺(tái)通過(guò)技術(shù)手段將集群中的閑置資源進(jìn)行收集，并將其分配給轉(zhuǎn)碼類(lèi)業(yè)務(wù)場(chǎng)景使用。

整體架構(gòu)上，離線業(yè)務(wù)發(fā)布入口統(tǒng)一收斂在在一個(gè)集群，我們稱(chēng)之為元數(shù)據(jù)集群，目的是為業(yè)務(wù)屏蔽底層多物理 K8s 集群。通過(guò) Virtual-Kubelet 連接元數(shù)據(jù)集群與物理集群，將閑置資源匯聚到元數(shù)據(jù)集群，在元數(shù)據(jù)集群中調(diào)度分發(fā)轉(zhuǎn)碼類(lèi)任務(wù)到底層物理集群。

策略方面，二次調(diào)度器負(fù)責(zé)巡檢集群中的所有節(jié)點(diǎn)，識(shí)別出低效節(jié)點(diǎn)并進(jìn)行標(biāo)記;隨后 Virtual-Kubelet 獲取物理集群中的低效節(jié)點(diǎn)可用資源作為集群閑置資源，再次分配給離線轉(zhuǎn)碼場(chǎng)景。同時(shí)，二次調(diào)度器確保一旦在線服務(wù)有資源需求，將會(huì)立刻驅(qū)逐離線 Pod 并歸還資源。通過(guò)此舉，我們能夠提高集群資源的利用效率，減少資源浪費(fèi)，并滿足轉(zhuǎn)碼類(lèi)場(chǎng)景對(duì)計(jì)算資源的需求。

階段二：整機(jī)騰挪分時(shí)復(fù)用

搜推廣等業(yè)務(wù)的獨(dú)占資源池，存在明顯的 CPU 利用率潮汐現(xiàn)象，尤其夜間利用率極低。通常情況下，資源池中的單個(gè)節(jié)點(diǎn)往往也只部署一個(gè)大規(guī)格業(yè)務(wù) Pod。基于這種情況，平臺(tái)通過(guò)彈性能力(HPA)，在凌晨業(yè)務(wù)低峰期按比例對(duì)在線業(yè)務(wù)進(jìn)行縮容，釋放出整機(jī)資源，并將轉(zhuǎn)碼、訓(xùn)練等離線 Pod 在該時(shí)段運(yùn)行起來(lái)，實(shí)現(xiàn)資源優(yōu)化，起到利用率“填谷”的效果。

在具體實(shí)施過(guò)程中，我們需要確保在線服務(wù)能夠在規(guī)定的時(shí)間內(nèi)全部被拉起。為此，我們采取以下策略：實(shí)現(xiàn)離線服務(wù)的提前退場(chǎng)，并通過(guò)調(diào)度器的搶占機(jī)制進(jìn)行兜底，確保在線服務(wù)在業(yè)務(wù)高峰期來(lái)臨之前能被全量且及時(shí)地重新啟動(dòng)。

這一階段能最大限度地利用資源，使得離線服務(wù)在低峰期得到有效運(yùn)行，同時(shí)保證在線服務(wù)在業(yè)務(wù)高峰期能夠快速恢復(fù)運(yùn)行。

階段三：常態(tài)混部

為了降低資源碎片率和業(yè)務(wù)資源持有成本，平臺(tái)持續(xù)推進(jìn)業(yè)務(wù)的大規(guī)模合池，將業(yè)務(wù)從獨(dú)占資源池遷移到平臺(tái)托管的公共混部池。通過(guò)合池、資源超賣(mài)等技術(shù)手段，我們有效提升了 CPU 分配率，但依舊無(wú)法解決合并后的資源池夜間利用率較低等問(wèn)題。另外，在合池后的復(fù)雜混部場(chǎng)景下，整機(jī)騰挪、分時(shí)混部離線的調(diào)度策略很難再繼續(xù)實(shí)施。平臺(tái)需要建設(shè)更為細(xì)粒度的資源管理與調(diào)度能力，來(lái)實(shí)現(xiàn)均值利用率提升的目標(biāo)，具體包含以下幾點(diǎn)：

1. 調(diào)度側(cè)

• 通過(guò)動(dòng)態(tài)超賣(mài)技術(shù)獲取可用于二次分配給離線服務(wù)的可用資源量，并抽象出離線資源視圖，使得 K8s 調(diào)度器感知到這些離線資源。調(diào)度器調(diào)度離線負(fù)載到對(duì)應(yīng)節(jié)點(diǎn)上，實(shí)現(xiàn)離線服務(wù)對(duì)節(jié)點(diǎn)利用率的“填谷”效果。
• 通過(guò)負(fù)載調(diào)度，盡可能避免在線服務(wù)被調(diào)度到高負(fù)載機(jī)器上，讓集群中節(jié)點(diǎn)負(fù)載更加均衡。
• 通過(guò)二次調(diào)度，驅(qū)逐負(fù)載熱點(diǎn)機(jī)器上的高利用率服務(wù)，使得集群負(fù)載保持動(dòng)態(tài)均衡狀態(tài)。

2. 單機(jī)側(cè)

• 支持 QoS(Quality of Service)保障策略，根據(jù)服務(wù)的 QoS 等級(jí)提供差異化的運(yùn)行時(shí)資源保障能力。
• 支持干擾檢測(cè)、離線驅(qū)逐等能力，當(dāng)離線服務(wù)對(duì)在線敏感服務(wù)產(chǎn)生干擾時(shí)，第一時(shí)間驅(qū)逐離線服務(wù)。
• 通過(guò)以上技術(shù)手段，我們能夠有效地保障服務(wù)混合部署時(shí)的穩(wěn)定性，從而實(shí)現(xiàn)在線和離線工作負(fù)載在節(jié)點(diǎn)上的常態(tài)混合運(yùn)行，實(shí)現(xiàn)利用率“填谷”效果的最大化。

階段四：統(tǒng)一調(diào)度

隨著常態(tài)混部和大規(guī)模資源合池的持續(xù)推進(jìn)，小紅書(shū)云原生資源調(diào)度將會(huì)面臨以下挑戰(zhàn)：

1. 各類(lèi)業(yè)務(wù)場(chǎng)景對(duì)資源調(diào)度存在復(fù)雜且各異的功能和性能需求

• 大數(shù)據(jù)、AI 場(chǎng)景下：排隊(duì)調(diào)度、批量調(diào)度(All-or-Nothing)、高吞吐量調(diào)度等需求。
• 在線敏感服務(wù)場(chǎng)景下：資源調(diào)度成功率保障性需求、服務(wù)運(yùn)行時(shí)質(zhì)量保障性需求。

2. GPU 等異構(gòu)資源調(diào)度需求

• 支持 GPU 共享調(diào)度、bin packing等調(diào)度能力，以提升 GPU 利用率及 GPU 機(jī)器上的 CPU 利用率。
• 支持 GPU 拓?fù)涓兄⒂H和性調(diào)度等調(diào)度能力，通過(guò)優(yōu)化 GPU 間的通信效率，大幅提升大規(guī)模訓(xùn)練效率。

基于以上背景，我們提出面向混合云架構(gòu)的統(tǒng)一調(diào)度方案。該方案基于統(tǒng)一資源池，通過(guò)統(tǒng)一調(diào)度能力來(lái)管理異構(gòu)計(jì)算資源，并支持各類(lèi)業(yè)務(wù)形態(tài)的工作負(fù)載調(diào)度能力。通過(guò)站在全局視角，將工作負(fù)載調(diào)度到最合適的節(jié)點(diǎn)，讓業(yè)務(wù)跑得更快更穩(wěn)定，并降低全局資源使用成本。涉及到的關(guān)鍵技術(shù)點(diǎn)如下：

1. 在離線統(tǒng)一調(diào)度

提供以 K8s 為底座的統(tǒng)一調(diào)度能力，支持包含在線敏感型服務(wù)、大數(shù)據(jù)/ AI 任務(wù)型工作負(fù)載在內(nèi)的統(tǒng)一資源調(diào)度。

2. QoS 感知調(diào)度

基于服務(wù)畫(huà)像，結(jié)合系統(tǒng)指標(biāo)識(shí)別干擾源，并刻畫(huà)節(jié)點(diǎn)資源質(zhì)量。通過(guò)綜合調(diào)度、重調(diào)度和單機(jī)調(diào)度等不同維度的調(diào)度能力，降低業(yè)務(wù)間混部造成的干擾，從而提升在線服務(wù)的運(yùn)行質(zhì)量。

3. GPU 調(diào)度

支持 GPU Share、bin packing、多 GPU 卡之間的親和性調(diào)度等調(diào)度能力，以提高 GPU 資源的利用效率。

4. 資源售賣(mài)模型

根據(jù)資源質(zhì)量、資源供應(yīng)形態(tài)(如常態(tài)化供應(yīng)資源、分時(shí)潮汐資源、Spot 資源)和資源套餐規(guī)格等多個(gè)維度，定義差異化資源售賣(mài)模型，降低資源綜合使用成本。

5. 資源配額

支持資源配額管理能力，包括分時(shí)配額、彈性配額和層級(jí)結(jié)構(gòu)管理等功能，避免多租戶之間的資源爭(zhēng)搶?zhuān)嵘Y源使用效率。

2、架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)

小紅書(shū)容器統(tǒng)一資源調(diào)度系統(tǒng) Tusker (The Unified Scheduling system base on Kubernetes for Efficiency and Reliability) 架構(gòu)設(shè)計(jì)如圖所示：

小紅書(shū)的各類(lèi)業(yè)務(wù)場(chǎng)景通過(guò)多個(gè)發(fā)布平臺(tái)和任務(wù)平臺(tái)提交，并通過(guò)上層負(fù)載編排能力，以 Pod 形式下發(fā)到統(tǒng)一調(diào)度系統(tǒng)。統(tǒng)一調(diào)度系統(tǒng)基于不同的調(diào)度需求，為在線服務(wù)提供強(qiáng)保障的資源交付能力、差異化的 QoS 保障能力，同時(shí)為離線服務(wù)提供最小資源需求的保障能力和極致的彈性能力。

在調(diào)度側(cè)，離線調(diào)度采用 Coscheduling 技術(shù);二次調(diào)度處理資源熱點(diǎn)問(wèn)題，包括熱點(diǎn)驅(qū)逐和碎片整理;負(fù)載調(diào)度基于 CPU 水位進(jìn)行調(diào)度，以實(shí)現(xiàn)更好地資源利用;資源視圖用于資源走查和模擬調(diào)度。

在單機(jī)側(cè)，通過(guò)壓制策略如 BVT(Borrowed Virtual Time)進(jìn)行性能控制和資源限制，并進(jìn)行內(nèi)存驅(qū)逐操作;QoS 保障方面，采用綁核和超線程干擾抑制等技術(shù)來(lái)實(shí)現(xiàn)資源的差異化保障;計(jì)算和上報(bào)可用的 Batch 資源信息;來(lái)自 Kernel 的指標(biāo)采集包括 PSI(Pressure Stall Information)、調(diào)度信息等;干擾檢測(cè)基于 CPI(Cycles Per lnstruction)、PSI(Pressure Stall Information)和業(yè)務(wù)指標(biāo)等，用于檢測(cè)和處理干擾情況。

2.1 離線調(diào)度資源視圖

離線服務(wù)資源調(diào)度的基本原理是基于在線服務(wù)負(fù)載感知能力的動(dòng)態(tài)超賣(mài)，具體實(shí)現(xiàn)是將節(jié)點(diǎn)空閑資源二次分配給離線業(yè)務(wù)：

其中離線可用資源為節(jié)點(diǎn)上的空閑資源(包含未分配資源和已分配未使用資源之和)，扣除安全預(yù)留資源之后的剩余資源，離線可用資源計(jì)算公式如下：

離線可用資源 = 整機(jī)資源 – 預(yù)留資源 – 在線服務(wù)實(shí)際使用量

將計(jì)算出的離線可用資源量按照時(shí)間分布后如圖所示(圖中綠色部分)：

實(shí)際落地過(guò)程中，為了避免離線可用資源隨在線服務(wù)資源使用波動(dòng)而大幅波動(dòng)，從而影響離線資源質(zhì)量和離線服務(wù)運(yùn)行穩(wěn)定性，可以通過(guò)資源畫(huà)像對(duì)上述公式中的在線服務(wù)實(shí)際使用量數(shù)據(jù)進(jìn)一步處理，去除數(shù)據(jù)噪點(diǎn)，最終計(jì)算出一個(gè)相對(duì)穩(wěn)定的離線可用資源量(圖中綠色部分)，如圖所示：

2.2 混部 QoS 保障策略

2.2.1 QoS 分級(jí)

按照業(yè)務(wù)對(duì)于服務(wù)質(zhì)量(QoS: Quality of Service)的需求，小紅書(shū)的業(yè)務(wù)類(lèi)型可以簡(jiǎn)單劃分為三個(gè) QoS 級(jí)別，如下表所示：

2.2.2 QoS 保障

根據(jù)服務(wù)的 QoS 需求，節(jié)點(diǎn)側(cè)可以采取 Pod 粒度的分級(jí)資源保障，以實(shí)現(xiàn)不同資源維度的差異化 QoS 保障策略，具體的保障參數(shù)如下：

在 CPU 核編排層面，我們針對(duì)不同的需求場(chǎng)景，設(shè)置了三種不同的綁核類(lèi)型，并設(shè)計(jì)了一套精細(xì)化 CPU 核編排策略，分配示意圖如下：

三種綁核類(lèi)型分別為：

Exclusive

特點(diǎn)：綁定 cpuset 調(diào)度域、CCD 感知、NUMA 綁定、獨(dú)占排他

場(chǎng)景：適用于對(duì)延遲極為敏感的搜推廣大規(guī)格服務(wù)

Share(推薦)

特點(diǎn)：綁定 cpuset 調(diào)度域、CCD 感知、NUMA(可選)綁定、Share/Exlusive 排他、可與 None 類(lèi)型業(yè)務(wù)共享

場(chǎng)景：適用于容忍部分干擾的 Java 微服務(wù)、應(yīng)用網(wǎng)關(guān)、Web服務(wù)等

Reclaimed

特點(diǎn)：無(wú) cpuset 綁定、可能與非 exlusive 綁核模式的業(yè)務(wù)共享核，核的分配完全由內(nèi)核控制，CPU 資源并非百分之百能夠滿足需求

場(chǎng)景：適用于 Batch 類(lèi)離線服務(wù)，部分對(duì)延遲無(wú)要求的計(jì)算服務(wù)

2.2.3 離線驅(qū)逐

在極端場(chǎng)景下，如整機(jī)內(nèi)存使用率較高、有觸發(fā) OOM 風(fēng)險(xiǎn)，或者離線業(yè)務(wù) CPU 長(zhǎng)期得不到滿足時(shí)，可以采取離線驅(qū)逐策略。單機(jī)側(cè)支持按照離線服務(wù)內(nèi)部定義的優(yōu)先級(jí)配置、資源用量和運(yùn)行時(shí)長(zhǎng)等多維度綜合算分排序后，按序驅(qū)逐離線服務(wù)，以達(dá)到最優(yōu)的資源利用效果。

2.3 離線業(yè)務(wù)場(chǎng)景舉例

小紅書(shū)作為一個(gè)擁有數(shù)億用戶的內(nèi)容社區(qū)，其離線業(yè)務(wù)場(chǎng)景豐富多樣，其中包含大量視頻類(lèi)和圖片類(lèi)轉(zhuǎn)碼場(chǎng)景、搜推、CV/NLP 算法推理訓(xùn)練、算法特征生產(chǎn)以及數(shù)倉(cāng)查詢等離線場(chǎng)景。具體而言，包含以下業(yè)務(wù)類(lèi)型：

• 近離線轉(zhuǎn)碼場(chǎng)景(已容器化)
• Flink 流式/批式計(jì)算(已容器化)
• Spark 批式計(jì)算 (未容器化、On YARN)
• CV/NLP 算法回掃場(chǎng)景(已容器化)
• 訓(xùn)練場(chǎng)景 (已容器化)

通過(guò)基于 K8s 的在離線統(tǒng)一調(diào)度能力，將這些離線業(yè)務(wù)與在線服務(wù)混合部署在統(tǒng)一資源池中。不僅能為在線服務(wù)提供差異化的資源質(zhì)量保障，亦能為離線服務(wù)提供海量的低成本算力，以實(shí)現(xiàn)資源效能的提升。

2.3.1 K8s 與 YARN 混部方案

在小紅書(shū)商業(yè)化、社區(qū)搜索等業(yè)務(wù)中存在大量的算法類(lèi) Spark 任務(wù)，由于離線集群資源緊張，任務(wù)無(wú)法及時(shí)處理，導(dǎo)致任務(wù)堆積。同時(shí)，在線集群在業(yè)務(wù)低峰時(shí)段資源使用率較低。另外，相當(dāng)大比例的 Spark 任務(wù)資源調(diào)度仍運(yùn)行在 YARN 調(diào)度器上。基于此背景，為了快速降低業(yè)務(wù)遷移成本，在方案選型方面，我們選擇與 Kooridinator 社區(qū)合作，采用 YARN on K8s 混部方案來(lái)快速落地 Spark 離線場(chǎng)景混部，具體方案如圖所示：

在線和離線工作負(fù)載在容器化環(huán)境下通過(guò) K8s 鏈路發(fā)布到在線集群內(nèi)。Spark 作業(yè)通過(guò) YARN ResourceManager 調(diào)度到具體節(jié)點(diǎn)，并由節(jié)點(diǎn)上的 NodeManager 組件拉起。NodeManager 以容器的形式部署在在線 K8s 集群中，實(shí)現(xiàn)資源的有效管理。除此之外，還涉及到以下組件：

1. 調(diào)度側(cè)

Koord-Yarn-Operator：支持 K8s 與 YARN 調(diào)度器資源視圖的雙向同步，確保資源信息的共享和一致性。

2. 節(jié)點(diǎn)側(cè)

Copilot：作為 NodeManager 的操作代理，提供 YARN Task 的管控接口。

Tusker-agent/koordlet：負(fù)責(zé)離線資源的上報(bào)、節(jié)點(diǎn)上離線 Pod/Task 管理，并處理沖突解決、驅(qū)逐、壓制策略等功能。

多調(diào)度器資源同步

K8s 調(diào)度器與 YARN 調(diào)度器之間原本獨(dú)立且相互不感知，為了共享分配節(jié)點(diǎn)上的總可用離線資源，需要通過(guò) Koord-Yarn-Operator 組件來(lái)做兩個(gè)調(diào)度器之間的資源雙向同步和協(xié)調(diào)，并實(shí)現(xiàn)兩個(gè)同步鏈路：

1. K8s ->YARN 調(diào)度器資源同步鏈路，負(fù)責(zé)同步 YARN 視角離線資源總量，其中 YARN 離線資源總量計(jì)算如下：

YARN離線資源總量 = 離線總可用量 – K8s 側(cè)節(jié)點(diǎn)已分配

2. YARN->K8s 調(diào)度器資源同步鏈路，負(fù)責(zé)同步已分配的 YARN 資源量，其中 K8s 離線資源總量計(jì)算如下：

K8s 離線資源總量 = 離線總可用量 – YARN 側(cè)節(jié)點(diǎn)已分配

基于各自節(jié)點(diǎn)離線資源視圖，兩個(gè)調(diào)度器分別作出調(diào)度決策，將離線 Pod 與 YARN Task 調(diào)度到適當(dāng)?shù)墓?jié)點(diǎn)上。由于同步過(guò)程不適合加鎖，可能會(huì)出現(xiàn)資源被過(guò)量分配的問(wèn)題：

具體解決措施是在單機(jī)側(cè)增加了仲裁邏輯。當(dāng)節(jié)點(diǎn)已分配的離線服務(wù)資源量長(zhǎng)期超過(guò)節(jié)點(diǎn)可用離線資源，且離線使用率持續(xù)較高時(shí)，存在離線服務(wù)無(wú)法獲得資源而被餓死的風(fēng)險(xiǎn)。單機(jī)側(cè)會(huì)根據(jù)離線服務(wù)的優(yōu)先級(jí)、資源占用量和運(yùn)行時(shí)長(zhǎng)等因素綜合算分，并按序驅(qū)逐。

3、落地收益

截止目前，小紅書(shū)混部能力覆蓋數(shù)十萬(wàn)臺(tái)機(jī)器規(guī)模，覆蓋算力規(guī)模數(shù)百萬(wàn)核，支持?jǐn)?shù)萬(wàn)規(guī)模在線、離線場(chǎng)景服務(wù)的資源調(diào)度。通過(guò)大規(guī)模容器混部的持續(xù)推進(jìn)，小紅書(shū)在資源成本效能等方面都取得了顯著收益，具體包含以下兩方面：

CPU 利用率

• 在保證在線服務(wù)服務(wù)質(zhì)量的前提下，在線混部集群天均 CPU 利用率提升至 45% 以上，部分集群天均 CPU 利用率可穩(wěn)定提升至 55%。
• 通過(guò)在離線混部等技術(shù)手段，在線集群 CPU 利用率提升 8%-15% 不等，部分存儲(chǔ)集群利用率提升可達(dá) 20% 以上。

資源成本

• 在保證離線業(yè)務(wù)穩(wěn)定性的前提下，為小紅書(shū)各類(lèi)離線場(chǎng)景提供數(shù)百萬(wàn)核時(shí)的低成本算力。
• 混部集群 CPU 分配率提升至 125% 以上，相較于獨(dú)占資源池，資源碎片率明顯下降。

4、總結(jié)與展望

在小紅書(shū)近一年多的混部技術(shù)探索中，我們?cè)谫Y源效能提升方面積累了較為豐富的落地經(jīng)驗(yàn)，并取得了不錯(cuò)的收益。隨著公司業(yè)務(wù)規(guī)模逐步增長(zhǎng)，場(chǎng)景愈發(fā)復(fù)雜，我們將會(huì)面臨諸多新的技術(shù)挑戰(zhàn)。展望未來(lái)，我們的目標(biāo)是建設(shè)面向混合云架構(gòu)的統(tǒng)一資源調(diào)度能力，具體工作將圍繞以下三方面展開(kāi)：

1. 混合工作負(fù)載調(diào)度能力支持：為了滿足小紅書(shū)所有業(yè)務(wù)場(chǎng)景的資源調(diào)度功能、性能需求，重點(diǎn)發(fā)展任務(wù)型工作(包括大數(shù)據(jù)、AI等 )的負(fù)載調(diào)度能力建設(shè)。
2. 資源效能進(jìn)一步提升：面向混合云架構(gòu)，我們將推進(jìn)更大規(guī)模的資源合池，推動(dòng) Quota 化資源交付。通過(guò)采用更先進(jìn)的彈性、混部、超賣(mài)等技術(shù)手段，進(jìn)一步提升集群資源利用率，實(shí)現(xiàn)資源成本的大幅度下降。
3. 更高服務(wù)質(zhì)量保障能力：在更具挑戰(zhàn)性的 CPU 利用率目標(biāo)下，我們將建設(shè) QoS 感知調(diào)度能力、干擾檢測(cè)能力，并依托安全容器等技術(shù)手段，解決深水區(qū)混部中可能遇到的各類(lèi)干擾問(wèn)題。

5、作者簡(jiǎn)介

桑鐸(宋澤輝)：基礎(chǔ)技術(shù)部/云原生平臺(tái)

小紅書(shū)資源調(diào)度負(fù)責(zé)人，在容器資源調(diào)度、混部部署、資源隔離等方面有豐富的實(shí)踐經(jīng)驗(yàn)，目前主要負(fù)責(zé)小紅書(shū)大規(guī)模容器資源調(diào)度、在離線混部等方向的技術(shù)研發(fā)工作。

黃瀨(索增增)：基礎(chǔ)技術(shù)部/云原生平臺(tái)

小紅書(shū)資源調(diào)度資深研發(fā)工程師，主要負(fù)責(zé)資源調(diào)度、工作負(fù)載編排相關(guān)的研發(fā)工作。

灰仔(葉楊婕)：基礎(chǔ)技術(shù)部/云原生平臺(tái)

小紅書(shū)資源調(diào)度研發(fā)工程師，主要負(fù)責(zé)在離線混部方向研發(fā)工作。

特別感謝：小紅書(shū)音視頻架構(gòu)組、數(shù)據(jù)引擎組、交易算法組所有業(yè)務(wù)方同學(xué)。