Koordinator 支持 K8s 與 YARN 混部,小紅書在離線混部實踐分享

背景介紹

Koordinator 是一個開源項目,基於阿里巴巴在容器調度領域多年累積的經驗孵化誕生,目前已經支持了 K8s 生態內的在離線混部,然而在 K8s 生態外,仍有相當數量的用戶會將大數據任務運行在 Apache Hadoop YARN[1]這類資源管理系統中。雖然目前一些計算引擎提供了 K8s operator,將任務接入到了 K8s 生態,但不可否認的是,目前 YARN 生態依然保持一定的活躍度,典型的例子是包括阿里雲在內的一系列主流雲廠商仍然提供類似 E-MapReduce[2]的產品,支持用戶將大數據作業提交到 YARN 上運行,這點從產品的受歡迎程度上可見一斑。

小紅書是 Koordinator 社區的活躍成員,爲了進一步豐富 Koordinator 支持的在離線混部場景,社區會同來自阿里雲、小紅書、螞蟻金服的開發者們共同啓動了 Hadoop YARN 與 K8s 混部項目,支持將超賣的 Batch 資源提供給 Hadoop YARN 使用,進一步提升集羣資源的使用效率,該項目目前已經在小紅書生產環境正式投入使用。

技術原理

總體原則

在此之前,業界已經有關於 K8s 與 YARN 混部的一些內部實踐,不過受限於落地場景,大部分的實現方式都對 YARN 系統本身做了相當多的侵入式改造,在運維和迭代上對普通用戶來說不夠友好。爲了讓更多用戶享受到社區的開源技術紅利,Koordinator 的設計將遵循以下幾個原則。

  • 離線作業的提交入口依然爲 YARN 保持不變。
  • 基於 Hadoop YARN 開源版本,原則上不對 YARN 做侵入式改造。
  • Koordinator 提供的混部資源,既可被 K8s Pod 使用,也可被 YARN task 使用,不同類型的離線應用可在同一節點內共存。
  • 單機 QoS 策略由 Koordlet 統一管理,併兼容 YARN task 的運行時。

方案設計

ResourceManager 和 NodeManger 是 YARN 的核心組件,ResourceManager 在管控側負責接收任務以及資源調度,NodeManager 負責任務的生命週期管理。在 YARN & K8s 混部場景下,RM 將仍然作爲 YARN 集羣的核心組件獨立部署,NM 將以容器的形式部署。

Koordinator 新增了 koord-yarn-operator 模塊,負責將 Batch 資源量同步給 YARN RM。爲了對資源進行更精細的管理,YARN task 將與 NM 的資源管理相互獨立,NM 在部署時只需按自身開銷申請 Batch 混部資源。YARN 任務的資源使用通過 cgroup 來管理(LinuxContainerExecutor 模式),將 cgroup 路徑在 besteffort Pod QoS 下,確保可以和其他 K8s Pod 一樣,統一在 besteffort 分組下管理。

koodlet 目前在單機支持了一系列的 QoS 策略,這些同樣需要針對 YARN 場景進行適配。對於資源隔離參數,例如 Group Identity,Memory QoS,L3 Cache 隔離等,koordlet 將根據設計的 cgroup 層級進行適配。而對於驅逐和壓制這類動態策略,koordlet 將新增一個 sidecar 模塊 koord-yarn-copilot,用於對接 YARN 場景的各類數據和操作,包括 YARN task 元信息採集、資源指標採集、task 驅逐操作等,所有 QoS 策略仍然保留在 koordlet 內,koordlet 內部相關模塊將以 plugin 形式對接 koord-yarn-copilot 接口。同時,koord-yarn-copilot 的接口設計將保留一定的擴展性,後續可用於對接其他資源框架。

更多有關 YARN & K8s 混部的詳細設計,可參考社區設計文檔[3]

小紅書在離線混部實踐

業務背景

在降本增效的大背景下,小紅書內部商業化,社區搜索等業務存在大量的算法類 Spark 任務因爲離線集羣資源緊張導致任務堆積,不能得到及時處理,同時在線集羣在業務低峯時段資源使用率較低;另一方面,相當佔比的 Spark 任務資源調度仍舊運行在 YARN 調度器上;基於此現狀,結合小紅書在在離線混部方面的既有能力,通過打通 K8s 調度器與 YARN 調度器之間的資源視圖,並在單機側支持了 YARN task 粒度的驅逐與 QoS 保障策略,最終實現了在維持離線業務提交入口和使用習慣不發生任何改變的前提下,讓大量的 Spark 任務穩定運行在在線閒時資源上,有效提升在線集羣資源利用率的同時,大大緩解業務資源壓力,並且有效降低業務離線資源使用成本。

在小紅書的實踐經驗中,有以下幾個關鍵技術點值得分享:

  • 針對 local shuffle 帶來的磁盤性能瓶頸問題, 我們通過 RemoteShuffleService 技術手段降低本地磁盤 IO 開銷,提升 IO 性能,有效提升離線業務運行效率與穩定性,另一方面,也能有效規避離線對在線在 IO 層面的干擾問題。
  • 小紅書參與在離線混部的業務場景複雜,除了大數據 Spark 場景以外,還有轉碼,離線推理,訓練等其他業務場景,爲了確保高優 Spark 任務運行時穩定性,我們在 YARN 資源同步,單機的驅逐策略,QoS 保障策略等方面,都做了細粒度的優先級區分和策略優化,例如:離線資源超量上報(爲了壓榨資源,提高利用率),單機衝突處理,資源衝突或者離線資源滿足度過低優先驅逐轉碼等時效性要求不高的離線,離線差異化 QoS 保障策略等。綜合以上優化手段,最終實現了 Spark 任務的穩定高效運行和資源的充分利用。

落地收益

截止目前,小紅書在離線混部方案已大規模落地,取得了以下業務結果:

  • 覆蓋數萬臺在線集羣節點,爲離線業務穩定提供數十萬核的計算資源
  • 離線任務驅逐率低於 1%,作業混部後基本不受影響
  • 混部集羣 CPU 利用率平均增長 8% ~ 10%,部分均值 CPU 利用率能達到 45% 以上,大幅提升了集羣資源使用效率

隨着增量業務場景的不斷接入,上述收益規模還在持續增長。

如何使用

支持 K8s 與 YARN 混部的相關功能目前已經基本研發完成,Koordinator 團隊目前正努力完成發佈前的一系列準備工作,敬請期待!

如果您也有意參與項目的合作共建,或是對 K8s & YARN 混部感興趣,歡迎您到社區專項討論區[4]下方留言,我們將第一時間聯繫您。參考留言格式:

聯繫人(gihub-id/e-mail):, e.g. @koordinator-dev

您任職/就讀/參與的公司/學校/組織名稱:e.g. koordinator community

社區參與意向:e.g. 希望能夠參與研發/學習大數據&雲原生混部/將 K8s&YARN 混部功能在生產環境落地/其它。

您對 "K8s&YARN混部" 的期待:

作者:索增增(小紅書)、宋澤輝(小紅書)、張佐瑋(阿里雲)

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章