編者按：
Koordinator 是一個開源項目，是基於阿里巴巴內部多年容器調度、混部實踐經驗孵化誕生，是行業首個生產可用、面向大規模場景的開源混部系統，致力於提升應用服務質量，優化資源使用效率。自 2022 年 4 月正式開源以來，吸引了業界衆多優秀工程師的貢獻參與和討論。
小紅書是 Koordinator 社區的活躍成員，自項目誕生初期就深度參與了一系列重要功能的演進。本文是基於 2023 雲棲大會上關於 Koordinator 分享的實錄，Koordinator 社區成員宋澤輝（小紅書）、張佐瑋（阿里雲）爲大家介紹了小紅書混部技術實踐以及 Koordinator 的近期規劃。
背景介紹
隨着小紅書業務的高速發展，各類在線，離線業務對於計算資源的需求也在快速增長。與此同時，部分在線集羣天均利用率水位卻維持在較低水平，造成這一現象的主要原因有以下幾點：
- 在線服務資源使用量隨着終端用戶的使用習慣呈現穩定的潮汐現象，夜間 CPU 利用率極低，導致集羣均值 CPU 利用率較低；
- 業務保有大量的獨佔資源池，資源池割裂產生大量的資源碎片，拉低 CPU 利用率；
- 業務爲了穩定性考慮，會過量囤積資源，進一步拉低 CPU 利用率。
基於以上背景，爲了幫助業務降低資源使用成本，提升集羣 CPU 利用率，小紅書容器團隊從 2022 年開始，通過規模化落地混部技術來大幅提升集羣資源效能，降低業務資源成本。
技術演進
小紅書混部技術演進分爲以下四個階段：
階段一：閒置資源再利用
早期集羣資源管理粗放，集羣中存在大量業務獨佔資源池，因爲資源碎片等因素存在大量低分配率的低效節點，散落在各個集羣中的低效節點形成大量資源浪費。另一方面，部分基於 K8s 發佈的轉碼類近線/離線場景，全天時段均存在大量計算資源需求。基於以上背景，容器平臺通過技術手段將集羣中的閒置資源收集起來，分配給轉碼類業務場景使用。
我們通過 virtual-kubelet 打通元數據集羣與物理集羣，將閒置資源匯聚起來，在元數據集羣分配給轉碼類場景近線/離線計算服務。策略方面，二次調度器負責巡檢集羣所有節點，識別爲低效節點後標記出來，virtual-kubelet 獲取物理集羣中的低效節點可用資源作爲集羣閒置資源二次分配給離線轉碼，同時二次調度器需要保證一旦在線服務有資源需求，將會立刻驅逐離線 pod 並歸還資源。
階段二：整機騰挪分時複用
搜推廣等業務的獨佔資源池，CPU 利用率潮汐現象明顯，夜間利用率極低，資源池中的單個節點往往也只部署一個大規格業務 Pod，基於以上背景，平臺通過彈性能力（HPA），在凌晨業務低峯期按比例對在線業務縮容，騰挪空出整機，並將轉碼，訓練等離線 pod 在該時段運行起來，起到利用率“填谷”的效果。
具體實施時，需要確保在線服務能在規定的時間內全部被拉起，爲此，策略方面我們實現了離線提前退場，並通過調度器搶佔機制兜底，確保在線服務在業務高峯期來臨之前能被全量及時拉起。
階段三：常態混部
爲了降低資源碎片率，降低業務資源持有成本，平臺持續推進業務大規模合池，將業務由獨佔池遷至平臺託管的公共混部池，通過合池，資源超賣等技術手段，CPU 分配率得到有效提升，但依舊無法解決合併後的資源池夜間利用率較低等問題。另一方面，合池後的複雜混部場景下，整機騰挪分時混部離線的調度策略很難再繼續實施，平臺需要通過建設更爲細粒度的資源管理與調度能力來實現均值利用率提升的目標，具體包含以下幾點：
- 調度側：
- 通過動態超賣技術獲取可二次分配給離線的可用資源量，並抽象出離線資源視圖讓 K8s 調度器感知到，調度器調度離線負載到對應節點上，實現離線對節點利用率的“填谷”效果；
- 通過負載調度，儘可能避免在線服務被調度到高負載機器，讓集羣中節點負載更加均衡；
- 通過二次調度，驅逐負載熱點機器上的高利用率服務，使得集羣負載處於動態均衡狀態。
- 單機側：
- 支持 Qos(Quality of service) 保障策略，根據服務的 Qos 等級提供差異化的運行時資源保障能力；
- 支持干擾檢測、離線驅逐等能力，當離線對在線敏感服務產生干擾時，第一時間驅逐離線。
通過以上技術手段，可以有效保障服務混部時的穩定性，從而常態化的讓在線離線工作負載混跑在節點上，實現利用率填谷效果的最大化。
架構設計與實現
小紅書容器資源調度架構設計如圖所示：
小紅書各類業務場景通過各類發佈平臺、任務平臺提交後，通過上層負載編排能力，以 pod 形式下發到統一調度系統。統一調度系統基於不同的調度需求，對在線服務提供強保障的資源交付能力，差異化的 Qos 保障能力，對離線服務提供最小資源需求的保障能力和極致的彈性能力。
調度側：
- 離線調度：coscheduling；
- 二次調度：熱點驅逐，碎片整理；
- 負載調度：基於 CPU 水位；
- 資源視圖：模擬調度。
單機側：
- 壓制策略：bvt 壓制，內存驅逐；
- Qos 保障：綁核，超線程干擾抑制等；
- Batch 資源上報：batch 可用資源計算，上報；
- 指標採集(from kernel)：psi，sched info 等；
- 干擾檢測：基於 cpi，psi，業務指標的干擾檢測。
離線調度資源視圖
離線服務資源調度的基本原理是基於在線服務負載感知能力的動態超賣，具體實現是將節點空閒資源二次分配給離線業務：
其中離線可用資源爲節點上的空閒資源（包含未分配資源和已分配未使用資源之和），扣除安全預留資源之後剩餘資源，離線可用資源計算公式如下：
離線可用資源=整機資源–預留資源-在線服務實際使用量
將計算出的離線可用資源量按照時間分佈後如圖所示（圖中綠色部分）：
實際落地過程中，爲了避免離線可用資源隨在線服務資源使用波動而大幅波動，從而影響離線資源質量和離線服務運行穩定性，通過資源畫像對上述公式中的在線服務實際使用量數據進一步處理，去除數據噪點，最終計算出一個相對穩定的離線可用資源量（圖中綠色部分），如圖所示：
混部 QoS 保障策略
QoS 分級
按照業務對於服務質量（QoS: Quality of service）的需求，我們將小紅書的業務類型簡單的劃分爲三個 QoS 級別，如下表所示：
| Qos等級 | 說明 | 業務場景 |
| latency-sensitive | 最高Qos保障等級，延遲極爲敏感服務 | 搜推廣延遲極爲敏感場景 |
| mid | 默認Qos保障等級，容忍部分干擾延遲 | 網關，java微服務 |
| batch | 最低Qos保障等級，延遲不敏感，資源隨時可能被搶 | 轉碼，spark，flink，訓練等計算場景 |
QoS 保障
根據服務的 QoS 需求，節點側會做 Pod 粒度的分級資源保障，實現各個資源維度差異化 QoS 保障策略，具體的保障參數如下：
| 資源 | 特性 | latency-sensitive | mid | batch |
| CPU | cpu burst | enable | enable | disable |
| 調度優先級 | 最高 | 默認 | 低 | |
| 綁核 | share(默認) | share(默認) | reclaimed | |
| numa | 強保證 | prefer（默認） | none | |
| L3 cache | 100% | 100%（默認） | 30%（默認） | |
| 內存帶寬 | 100% | 100%（默認） | 30%（默認） | |
| 內存 | OOM優先級 | 最低 | 默認 | 最高 |
| 內存回收水線 | 調高 | 默認 | 調低 |
在 CPU 核調度層面，分別設置了三種綁核類型，並設計了一套精細化 CPU 覈編排策略，分配示意圖如下：
三種綁核類型分別爲：
- exclusive（不推薦）
- 特點：綁定 cpuset 調度域，CCD 感知，numa 綁定，獨佔排他
- 場景：極爲敏感的搜推廣大規格延遲敏感服務
- share
- 特點：綁定 cpuset 調度域，CCD 感知，numa（可選）綁定，share/exlusive 排他，可與 none 類型業務共享
- 場景：容忍部分干擾的 Java 微服務，應用網關，web 服務
- reclaimed
- 特點：無 cpuset 綁定，可能與非 exlusive 綁核模式業務共享核，核的分配完全交由內核，CPU 資源並非 100% 能得到滿足
- 場景：batch 類離線服務，部分對延遲無要求的計算服務
離線驅逐
極端場景下，如整機內存使用率較高，有觸發 OOM 風險，或者離線業務 CPU 長期得不到滿足，單機側支持按照離線服務內部定義的優先級配置，資源用量，運行時長等多維度綜合算分排序後按序驅逐。
離線業務場景
小紅書作爲一個數億用戶的內容社區，其離線業務場景豐富多樣，其中包含大量視頻類，圖片類轉碼場景，搜推，cv/nlp 算法推理訓練，算法特徵生產，數倉查詢等離線場景，具體來講，包含以下業務類型：
- 近離線轉碼場景（已容器化）
- Flink 流式/批式計算（已容器化）
- Spark 批式計算 （未容器化，on yarn）
- cv/nlp 算法回掃場景（已容器化）
- 訓練場景 （已容器化）
通過提供以 K8s 爲底座的在離線統一調度能力，將這些離線業務與在線服務混合部署在統一計算資源池內，爲在線服務提供差異化的資源質量保障，爲離線服務提供海量的低層本算力，實現資源效能的提升。
K8s 與 YARN 混部方案
小紅書內部商業化，社區搜索等業務存在大量的算法類 spark 任務因爲離線集羣資源緊張導致任務堆積，不能得到及時處理，同時在線集羣在業務低峯時段資源使用率較低；另一方面，相當佔比的 spark 任務資源調度仍舊運行在 Yarn 調度器上，在這樣的背景下，爲了降低業務遷移成本，方案選型方面，我們選擇與 Kooridinator 社區合作，採用 Yarn on K8s 混部方案來快速落地 Spark 離線場景混部，具體方案如圖所示：
其中容器化的在線、離線工作負載通過 K8s 鏈路發佈到在線集羣內，Spark 作業通過 Yarn ResourceManager 調度到具體節點，並由節點上的 Nodemanager 組件拉起。其中 Nodemanager 通過容器的方式部署在在線 K8s 集羣內，除此之外，還涉及到以下組件：
- 調度側
- koord-yarn-operator ：支持 K8s 與 yarn 調度器資源視圖雙向同步；
- 節點側
- copilot：NodeManager 操作代理，提供 Yarn Task 管控接口；
- Neptune-agent/koordlet：離線資源上報，節點離線 Pod/task 管理，衝突解決，驅逐，壓制策略；
支持 K8s 與 YARN 混部的核心能力目前已經在社區研發完成，將於 11 月下旬，在 Koordinator 1.4 版本進行發佈。
多調度器資源同步
K8s 調度器與 YARN 調度器之間原本獨立且相互不感知，爲了共享分配在線集羣節點上的總可用離線資源，需要通過 koord-yarn-operator 組件來做兩個調度器之間的資源雙向同步和協調，並實現兩個同步鏈路：
1. K8s->YARN 調度器資源同步鏈路，負責同步 Yarn 視角離線資源總量，其中 YARN 離線資源總量計算如下：
YARN 離線資源總量=離線總可用量-K8s 側節點已分配
2. YARN->K8s 調度器資源同步鏈路，負責同步 YARN 已分配資源量，其中 K8s 離線資源總量計算如下：
K8s 離線資源總量=離線總可用量-YARN 側節點已分配
基於各自節點離線資源視圖，兩個調度器分別做出調度決策，調度 K8s 離線 Pod 與 YARN Task 到節點上，由於同步過程不適合加鎖，可能會出現資源被過量分配的問題：
具體解決措施是在單機側增加了仲裁邏輯，當節點已分配離線服務資源量長期超過節點可用離線資源，且離線使用率持續較高，存在離線服務得不到資源被餓死的可能，單機側則會根據離線服務的優先級，資源佔用量，運行時長等因素綜合算分並按序驅逐。
阿里雲 EMR 產品化支持
與此同時，阿里雲 EMR 團隊在產品層面提供了混部功能的開發支持，在兼容EMR 原有日誌，監控，運維邏輯的基礎上，支持了 K8s 集羣彈性擴縮容 NodeManager Pod 的能力。
落地收益
截止目前，小紅書混部能力覆蓋數十萬臺機器規模，覆蓋算力規模數百萬核，支持數萬規模在線、離線場景服務的資源調度。通過大規模容器混部的持續推進，小紅書在資源成本效能等方面都取得了顯著收益，具體包含以下兩方面：
- CPU 利用率
- 在保證在線服務服務質量的前提下，在線混部集羣天均 CPU 利用率提升至 45% 以上，部分集羣天均 CPU 利用率可穩定提升至 55%。
- 通過在離線混部等技術手段，在線集羣 CPU 利用率提升 8%-15% 不等，部分存儲集羣 CPU 利用率提升可達 20% 以上。
- 資源成本
- 在保證離線業務穩定性的前提下，爲小紅書各類離線場景提供數百萬核時的低成本算力。
- 混部集羣 CPU 分配率提升至 125% 以上，相較於獨佔資源池，資源碎片率明顯下降。
社區共建歷程
小紅書是早期參與 Koordinator 社區的公司之一，2022 年 4 月，Koordinator 正式開源，同年 6 月，小紅書內部啓動了在離線混部項目，開始參與 Koordinator 方案設計與代碼提交。2022 年 8 月，小紅書與社區共建了 runtime-proxy 組件，並在內部場景落地。2023 年 4 月，小紅書在社區主導啓動了 YARN 與 K8s 混部項目，2023 年 8 月，該方案在小紅書內規模化落地。
截止目前，依託 Koorindiator 的助力，小紅書的混部已經覆蓋公司數萬臺節點，提供數十萬核離線資源，整體混部集羣的利用率提升至 45% 以上。取得了不錯的落地效果。
總結與展望
在小紅書近一年多混部技術探索過程中，我們在資源效能提升方面積累了較爲豐富的落地經驗，並取得了不錯的提升效果，隨着公司業務規模逐步增長，場景愈發複雜，我們將會面臨諸多新的技術挑戰。下個階段我們的目標是建設面向混合雲架構的統一資源調度能力，具體工作將圍繞以下三方面展開：
- 混合工作負載調度能力支持：包括大數據，AI 在內的任務型工作負載調度能力建設，滿足小紅書所有業務場景的資源調度功能，性能需求；
- 資源效能進一步提升：面向混合雲架構，推進更大規模的資源合池，推進 quota 化資源交付，通過更加激進的彈性，混部，超賣等技術手段，實現集羣資源利用率的進一步提升，資源成本的大幅下降；
- 更高服務質量保障能力：在更爲激進的 CPU 利用率目標背景下，通過建設 Qos 感知調度能力，干擾檢測能力，依託安全容器等技術手段，解決深水區混部中可能遇到的各類混部干擾問題。
作者：宋澤輝（小紅書）、張佐瑋（阿里雲）
本文爲阿里雲原創內容，未經允許不得轉載。