根據 Gartner 預測數據顯示：2024 年全球 IT 支出預計將達到 5.1 萬億美元，比 2023 年增長 8 %。然而，該機構的另一項調查數據顯示：全球數據中心服務器平均 CPU 利用率普遍低于 20%，存在巨大的資源浪費。據測算，以數百萬核 CPU 規模的數據中心為例，每提升 1 個百分點的整體資源利用率，每年將節省數千萬元的成本。由此可見，提高資源利用率對于降低企業運營成本具有顯著的效果。

早在 2015 年，谷歌就在其經典論文《Large-scale cluster management at Google with Borg》中披露了它在資源管理和調度方面的實踐經驗，是最早通過混部技術來提升資源利用率的公司之一。國內多家頭部互聯網企業也相繼實施類似的技術方案，并取得可觀的資源利用率提升效果。

隨著小紅書業務的高速發展，各類在線、離線業務對計算資源的需求日益增長。與此同時，我們觀察到：部分在線集群天均利用率的水位卻維持在較低的水平。造成這一現象的主要原因有以下幾點：

• 在線服務資源使用量隨著終端用戶的使用習慣呈現穩定的潮汐現象，夜間 CPU 利用率極低，從而導致整個集群的均值 CPU 利用率降低。
• 業務保有大量的獨占資源池，資源池割裂產生大量的資源碎片，進而降低 CPU 的利用率。
• 出于穩定性考慮，業務傾向于過量儲備資源，進一步降低 CPU 的利用率。

基于以上背景，為了幫助業務降低資源使用成本，小紅書容器團隊從 2022 年開始規模化落地混部技術，提升集群 CPU 利用率。截止目前，混部集群 CPU 利用率均值可達 45% 以上，為業務提供數百萬核時的算力成本優化。

1、技術演進

小紅書混部技術演進分為以下四個階段(如圖所示)：

階段一：閑置資源再利用

在早期，小紅書的集群資源管理相對粗放，集群中存在大量業務獨占的資源池。由于資源碎片化等因素，各個集群中存在許多低分配率的低效節點，導致大量資源浪費。同時，基于 Kubernetes(K8s)發布的轉碼類近線/離線場景，在全天時段均存在大量計算資源需求。基于以上背景，小紅書容器平臺通過技術手段將集群中的閑置資源進行收集，并將其分配給轉碼類業務場景使用。

整體架構上，離線業務發布入口統一收斂在在一個集群，我們稱之為元數據集群，目的是為業務屏蔽底層多物理 K8s 集群。通過 Virtual-Kubelet 連接元數據集群與物理集群，將閑置資源匯聚到元數據集群，在元數據集群中調度分發轉碼類任務到底層物理集群。

策略方面，二次調度器負責巡檢集群中的所有節點，識別出低效節點并進行標記;隨后 Virtual-Kubelet 獲取物理集群中的低效節點可用資源作為集群閑置資源，再次分配給離線轉碼場景。同時，二次調度器確保一旦在線服務有資源需求，將會立刻驅逐離線 Pod 并歸還資源。通過此舉，我們能夠提高集群資源的利用效率，減少資源浪費，并滿足轉碼類場景對計算資源的需求。

階段二：整機騰挪分時復用

搜推廣等業務的獨占資源池，存在明顯的 CPU 利用率潮汐現象，尤其夜間利用率極低。通常情況下，資源池中的單個節點往往也只部署一個大規格業務 Pod。基于這種情況，平臺通過彈性能力(HPA)，在凌晨業務低峰期按比例對在線業務進行縮容，釋放出整機資源，并將轉碼、訓練等離線 Pod 在該時段運行起來，實現資源優化，起到利用率“填谷”的效果。

在具體實施過程中，我們需要確保在線服務能夠在規定的時間內全部被拉起。為此，我們采取以下策略：實現離線服務的提前退場，并通過調度器的搶占機制進行兜底，確保在線服務在業務高峰期來臨之前能被全量且及時地重新啟動。

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

階段三：常態混部

為了降低資源碎片率和業務資源持有成本，平臺持續推進業務的大規模合池，將業務從獨占資源池遷移到平臺托管的公共混部池。通過合池、資源超賣等技術手段，我們有效提升了 CPU 分配率，但依舊無法解決合并后的資源池夜間利用率較低等問題。另外，在合池后的復雜混部場景下，整機騰挪、分時混部離線的調度策略很難再繼續實施。平臺需要建設更為細粒度的資源管理與調度能力，來實現均值利用率提升的目標，具體包含以下幾點：

1. 調度側

• 通過動態超賣技術獲取可用于二次分配給離線服務的可用資源量，并抽象出離線資源視圖，使得 K8s 調度器感知到這些離線資源。調度器調度離線負載到對應節點上，實現離線服務對節點利用率的“填谷”效果。
• 通過負載調度，盡可能避免在線服務被調度到高負載機器上，讓集群中節點負載更加均衡。
• 通過二次調度，驅逐負載熱點機器上的高利用率服務，使得集群負載保持動態均衡狀態。

2. 單機側

• 支持 QoS(Quality of Service)保障策略，根據服務的 QoS 等級提供差異化的運行時資源保障能力。
• 支持干擾檢測、離線驅逐等能力，當離線服務對在線敏感服務產生干擾時，第一時間驅逐離線服務。
• 通過以上技術手段，我們能夠有效地保障服務混合部署時的穩定性，從而實現在線和離線工作負載在節點上的常態混合運行，實現利用率“填谷”效果的最大化。

階段四：統一調度

隨著常態混部和大規模資源合池的持續推進，小紅書云原生資源調度將會面臨以下挑戰：

1. 各類業務場景對資源調度存在復雜且各異的功能和性能需求

• 大數據、AI 場景下：排隊調度、批量調度(All-or-Nothing)、高吞吐量調度等需求。
• 在線敏感服務場景下：資源調度成功率保障性需求、服務運行時質量保障性需求。

2. GPU 等異構資源調度需求

• 支持 GPU 共享調度、bin packing等調度能力，以提升 GPU 利用率及 GPU 機器上的 CPU 利用率。
• 支持 GPU 拓撲感知、親和性調度等調度能力，通過優化 GPU 間的通信效率，大幅提升大規模訓練效率。

基于以上背景，我們提出面向混合云架構的統一調度方案。該方案基于統一資源池，通過統一調度能力來管理異構計算資源，并支持各類業務形態的工作負載調度能力。通過站在全局視角，將工作負載調度到最合適的節點，讓業務跑得更快更穩定，并降低全局資源使用成本。涉及到的關鍵技術點如下：

1. 在離線統一調度

提供以 K8s 為底座的統一調度能力，支持包含在線敏感型服務、大數據/ AI 任務型工作負載在內的統一資源調度。

2. QoS 感知調度

基于服務畫像，結合系統指標識別干擾源，并刻畫節點資源質量。通過綜合調度、重調度和單機調度等不同維度的調度能力，降低業務間混部造成的干擾，從而提升在線服務的運行質量。

3. GPU 調度

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

4. 資源售賣模型

根據資源質量、資源供應形態(如常態化供應資源、分時潮汐資源、Spot 資源)和資源套餐規格等多個維度，定義差異化資源售賣模型，降低資源綜合使用成本。

5. 資源配額

支持資源配額管理能力，包括分時配額、彈性配額和層級結構管理等功能，避免多租戶之間的資源爭搶，提升資源使用效率。

2、架構設計與實現

小紅書容器統一資源調度系統 Tusker (The Unified Scheduling system base on Kubernetes for Efficiency and Reliability) 架構設計如圖所示：

小紅書的各類業務場景通過多個發布平臺和任務平臺提交，并通過上層負載編排能力，以 Pod 形式下發到統一調度系統。統一調度系統基于不同的調度需求，為在線服務提供強保障的資源交付能力、差異化的 QoS 保障能力，同時為離線服務提供最小資源需求的保障能力和極致的彈性能力。

在調度側，離線調度采用 Coscheduling 技術;二次調度處理資源熱點問題，包括熱點驅逐和碎片整理;負載調度基于 CPU 水位進行調度，以實現更好地資源利用;資源視圖用于資源走查和模擬調度。

在單機側，通過壓制策略如 BVT(Borrowed Virtual Time)進行性能控制和資源限制，并進行內存驅逐操作;QoS 保障方面，采用綁核和超線程干擾抑制等技術來實現資源的差異化保障;計算和上報可用的 Batch 資源信息;來自 Kernel 的指標采集包括 PSI(Pressure Stall Information)、調度信息等;干擾檢測基于 CPI(Cycles Per lnstruction)、PSI(Pressure Stall Information)和業務指標等，用于檢測和處理干擾情況。

2.1 離線調度資源視圖

離線服務資源調度的基本原理是基于在線服務負載感知能力的動態超賣，具體實現是將節點空閑資源二次分配給離線業務：

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

離線可用資源 = 整機資源 – 預留資源 – 在線服務實際使用量

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

實際落地過程中，為了避免離線可用資源隨在線服務資源使用波動而大幅波動，從而影響離線資源質量和離線服務運行穩定性，可以通過資源畫像對上述公式中的在線服務實際使用量數據進一步處理，去除數據噪點，最終計算出一個相對穩定的離線可用資源量(圖中綠色部分)，如圖所示：

2.2 混部 QoS 保障策略

2.2.1 QoS 分級

按照業務對于服務質量(QoS: Quality of Service)的需求，小紅書的業務類型可以簡單劃分為三個 QoS 級別，如下表所示：

2.2.2 QoS 保障

根據服務的 QoS 需求，節點側可以采取 Pod 粒度的分級資源保障，以實現不同資源維度的差異化 QoS 保障策略，具體的保障參數如下：

在 CPU 核編排層面，我們針對不同的需求場景，設置了三種不同的綁核類型，并設計了一套精細化 CPU 核編排策略，分配示意圖如下：

三種綁核類型分別為：

Exclusive

特點：綁定 cpuset 調度域、CCD 感知、NUMA 綁定、獨占排他

場景：適用于對延遲極為敏感的搜推廣大規格服務

Share(推薦)

特點：綁定 cpuset 調度域、CCD 感知、NUMA(可選)綁定、Share/Exlusive 排他、可與 None 類型業務共享

場景：適用于容忍部分干擾的 Java 微服務、應用網關、Web服務等

Reclaimed

特點：無 cpuset 綁定、可能與非 exlusive 綁核模式的業務共享核，核的分配完全由內核控制，CPU 資源并非百分之百能夠滿足需求

場景：適用于 Batch 類離線服務，部分對延遲無要求的計算服務

2.2.3 離線驅逐

在極端場景下，如整機內存使用率較高、有觸發 OOM 風險，或者離線業務 CPU 長期得不到滿足時，可以采取離線驅逐策略。單機側支持按照離線服務內部定義的優先級配置、資源用量和運行時長等多維度綜合算分排序后，按序驅逐離線服務，以達到最優的資源利用效果。

2.3 離線業務場景舉例

小紅書作為一個擁有數億用戶的內容社區，其離線業務場景豐富多樣，其中包含大量視頻類和圖片類轉碼場景、搜推、CV/NLP 算法推理訓練、算法特征生產以及數倉查詢等離線場景。具體而言，包含以下業務類型：

• 近離線轉碼場景(已容器化)
• Flink 流式/批式計算(已容器化)
• Spark 批式計算 (未容器化、On YARN)
• CV/NLP 算法回掃場景(已容器化)
• 訓練場景 (已容器化)

通過基于 K8s 的在離線統一調度能力，將這些離線業務與在線服務混合部署在統一資源池中。不僅能為在線服務提供差異化的資源質量保障，亦能為離線服務提供海量的低成本算力，以實現資源效能的提升。

2.3.1 K8s 與 YARN 混部方案

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

在線和離線工作負載在容器化環境下通過 K8s 鏈路發布到在線集群內。Spark 作業通過 YARN ResourceManager 調度到具體節點，并由節點上的 NodeManager 組件拉起。NodeManager 以容器的形式部署在在線 K8s 集群中，實現資源的有效管理。除此之外，還涉及到以下組件：

1. 調度側

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

2. 節點側

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

Tusker-agent/koordlet：負責離線資源的上報、節點上離線 Pod/Task 管理，并處理沖突解決、驅逐、壓制策略等功能。

多調度器資源同步

K8s 調度器與 YARN 調度器之間原本獨立且相互不感知，為了共享分配節點上的總可用離線資源，需要通過 Koord-Yarn-Operator 組件來做兩個調度器之間的資源雙向同步和協調，并實現兩個同步鏈路：

1. K8s ->YARN 調度器資源同步鏈路，負責同步 YARN 視角離線資源總量，其中 YARN 離線資源總量計算如下：

YARN離線資源總量 = 離線總可用量 – K8s 側節點已分配

2. YARN->K8s 調度器資源同步鏈路，負責同步已分配的 YARN 資源量，其中 K8s 離線資源總量計算如下：

K8s 離線資源總量 = 離線總可用量 – YARN 側節點已分配

基于各自節點離線資源視圖，兩個調度器分別作出調度決策，將離線 Pod 與 YARN Task 調度到適當的節點上。由于同步過程不適合加鎖，可能會出現資源被過量分配的問題：

具體解決措施是在單機側增加了仲裁邏輯。當節點已分配的離線服務資源量長期超過節點可用離線資源，且離線使用率持續較高時，存在離線服務無法獲得資源而被餓死的風險。單機側會根據離線服務的優先級、資源占用量和運行時長等因素綜合算分，并按序驅逐。

3、落地收益

截止目前，小紅書混部能力覆蓋數十萬臺機器規模，覆蓋算力規模數百萬核，支持數萬規模在線、離線場景服務的資源調度。通過大規模容器混部的持續推進，小紅書在資源成本效能等方面都取得了顯著收益，具體包含以下兩方面：

CPU 利用率

• 在保證在線服務服務質量的前提下，在線混部集群天均 CPU 利用率提升至 45% 以上，部分集群天均 CPU 利用率可穩定提升至 55%。
• 通過在離線混部等技術手段，在線集群 CPU 利用率提升 8%-15% 不等，部分存儲集群利用率提升可達 20% 以上。

資源成本

• 在保證離線業務穩定性的前提下，為小紅書各類離線場景提供數百萬核時的低成本算力。
• 混部集群 CPU 分配率提升至 125% 以上，相較于獨占資源池，資源碎片率明顯下降。

4、總結與展望

在小紅書近一年多的混部技術探索中，我們在資源效能提升方面積累了較為豐富的落地經驗，并取得了不錯的收益。隨著公司業務規模逐步增長，場景愈發復雜，我們將會面臨諸多新的技術挑戰。展望未來，我們的目標是建設面向混合云架構的統一資源調度能力，具體工作將圍繞以下三方面展開：

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

5、作者簡介

桑鐸(宋澤輝)：基礎技術部/云原生平臺

小紅書資源調度負責人，在容器資源調度、混部部署、資源隔離等方面有豐富的實踐經驗，目前主要負責小紅書大規模容器資源調度、在離線混部等方向的技術研發工作。

黃瀨(索增增)：基礎技術部/云原生平臺

小紅書資源調度資深研發工程師，主要負責資源調度、工作負載編排相關的研發工作。

灰仔(葉楊婕)：基礎技術部/云原生平臺

小紅書資源調度研發工程師，主要負責在離線混部方向研發工作。

特別感謝：小紅書音視頻架構組、數據引擎組、交易算法組所有業務方同學。