04-美團大數據及機器學習基礎設施云原生改造實踐-吳通.pdf

《04-美團大數據及機器學習基礎設施云原生改造實踐-吳通.pdf》由會員分享，可在線閱讀，更多相關《04-美團大數據及機器學習基礎設施云原生改造實踐-吳通.pdf（54頁珍藏版）》請在三個皮匠報告上搜索。

1、美團數據及機器學習集群云原改造實踐 美團數據平臺資源與系統負責/吳通錄早期架構及升級背景 云原改造過程 關鍵問題和思考 未來規劃改造前架構場景特點數據和機器學習兩個場景，先有數據，后有機器學習 數據場景供需共構，對擴展性、可觀測性等訴求不，機器故障率低 機器學習場景供需異構，對調度語義、擴展性、可觀測性、運維友好均有訴求，機器故障率改造前痛點擴展App類型復雜度 依賴AM，戶感知，影響資源統計 持GPU、RDMA、NPU等設備復雜度 調度策略定制成本 故障感知、監控、可觀測平低更深層次的原因離線場景的路徑依賴 架構變更帶來的不確定性 K8S VS YARNYARN：分布式集群資源調度系統 K8

2、S：分布式集群操作系統，管理集群資源的，不僅僅是調度改造后架構錄早期架構及升級背景 云原改造過程 關鍵問題和思考 未來規劃控制改造內容概覽組件改造內容簡介etcd服務器和客戶端均升級3.5.5，提升性能并修復單節點revision落后較多的問題kube-apiserver1.解決負載不均衡問題2.httplog獲取userAgent可能觸發map并發讀寫問題3.修復get&watch在apiserver_request_duration_seconds_bucket錯誤展示的問題controller-manager1.改造Endpoint Controller，以解決underlay CNI不

3、持ClusterIP service問題2.增強NodeLifecycle Controller處理Not Ready Node的能，降低節點不可對已有負載的影響Operator1.SparkOperator：解決spark on k8s，持spark 2.2和RSS2.TrainingOperator：解決TF、MPI、PyTorch on K8S，持容錯3.AFOServingOperator：以PaaS式解決TF、PyTorch、Triton 推理 on K8S4.OrdinaryServingOperator：以類IaaS式管理在線服務5.Codelab Operator：以容器式給程

4、師提供開發實驗環境 6.PrestoOperator：Presto cluster on K8S，持彈性容錯調度器研調度器，持各種級特性，吞吐平較節點端改造內容概覽組件改造內容簡介物理機調整掛盤式，借助硬/軟Raid解決kubelet不能管理多磁盤的問題kubelet1.卡、GPU親和性持到PCIE級別2.持多卡Pod分配多IP3.不同作業采不同的oom處理策略4.改造static cpu manager，適配預留cpu核的綁核法5.修復系列導致kubelet不穩定的問題，如device權限、terminating pod、IP回收等問題device plugin1.gpu-device-pl

5、ugin持按卡類型匯報資源名2.gpu-device-plugin、rdma-device-plugin持更豐富的設備健康檢查和異常處理機制3.gpu-device-plugin、rdma-device-plugin持PCIE級親和策略4.npu-device-plugin持ring內npd1.增強節點異常檢查功能，保證節點在運期環境是符合預期的2.包括CPU、GPU、卡等硬件環境，也包括存儲系統、IP管理等軟件環境絡1.采underlay CNI，實現pod和集群外部絡資源互聯2.改造clusterIP service實現式，實現在underlay CNI的負載均衡案存儲1.持訪問HDFS，

6、主要解決從NameNode獲取token和renew token，并存儲到Pod內的問題2.持訪問Dolphin FS，實現了套CSI Driver，采靜態提供PV的式，并持件系統故障后可動恢復，不影響已有負載 3.持訪問EBS，實現了套CSI Driver，采動態提供PV的式。來剝離解決實驗開發場景的狀態保存，以實現掛起恢復功能改造內容概覽組件改造內容簡介監控告警1.3分2副本Prometheus，3thanos，3thanos-ruler2.建設k8s_alert對接公司內部的告警系統3.建設raptor-adaptor，對接在線服務指標到公司內部中間件可觀測1.主流志案般采消息隊列實時收

7、集志，但解決不了時延、時序和丟失問題，對戶troubleshooting影響很 2.研了套志案，基本思路是在每個節點部署簡單的件服務器來讀取running狀態pod志，pod結束后持久化到s33.構建了套數據收集案，實時收集etcd和Prometheus等數據源的數據，并通過消息隊列存儲到持久化存儲4.構建了數百張dashboard，描述系統的運狀況和不同組件的內部細節，并借此指導各類優化作研調度器簡介持多租戶配額管理，持排隊 集群唯調度器，持Gang Scheduling，租戶間、租戶內公平調度 持搶占式調度，配額之上增加彈性量，提升資源利率 持劃分邏輯資源池，Pod適應優選策略，減少GPU

8、碎 持RDMA親和性調度，更好地撐性能計算需求 完善的退避機制，持租戶-Job-Pod多層級退避 調度吞吐300+pods/s租戶-配額管理兩級隊列：隊列：租戶，隊列：租戶內細分，min：配額，max-min：彈性量 Pod劃分：System Pod，User Pod（指定PodGroup），單調度器統調度 Gang Job：PodGroup唯映射個Gang Job，指定作業提交隊列主流程OpenSession：從cache中復制Node、Queue、Job和Pod等對象，使調度流程鎖化 AllcoateSystem：調度System Pod，優選過程，快速調度 PreAllocate：為上輪

9、搶占成功的User Pod分配節點，Gang Job遵循事務提交 Allocate：調度User Pod，搜索最優Node，Gang Job遵循事務提交，核流程 Preempt：為調度失敗的User Pod搶占資源，Gang Job遵循事務提交，核流程 CloseSession：更新Job和Pod狀態，記錄event事件和監控指標數據 調度概述隊列公平調度：配額滿率低的隊列優先 Gang Scheduling優先調度：未滿Gang的Job優先 Job公平調度：Pod調度率低的Job優先，防個Job餓死其他Job 優先級調度：持隊列內指定Job優先級、Job內指定Pod優先級 異構調度：持10+

10、種GPU卡型，持5+種命周期、特點不的任務 調度語義豐富：持k8s原調度語義，擴展了如適應聚集/均衡調度、RDMA絡親和調度等搶占概述隊列max min即表示開啟彈性調度，max-min部分的資源占在集群資源緊張時會被搶占 隊列只在配額未滿的情況下才能搶占，彈性量部分不通過搶占來滿 公平性：和調度過程類似，優先為配額滿率低的隊列和Pod調度率低的Job發起搶占 優先級搶占：持隊列內指定Job優先級、Job內指定Pod優先級，搶低優保優 Gang Scheduling保護：優先搶占每個Job超出minMember的Pod，如果Gang Scheduling被破壞，則搶占整個Job搶占關鍵實現-G

11、ang Scheduling Gang Scheduling：為Job分配于等于minMember數量的Pod 調度事務化，連續為Job調度夠數量的Pod后提交調度結果，否則回滾 搶占分成兩步，先嘗試僅搶占超出minMember部分的Pod，再執Gang搶占搶占關鍵實現-兩級事務控制為Gang Job發起搶占會有多個Preemptor，多個Preemptor搶占結果提交需要保證原性；每個Preemptor可能搶占Node上的多個Preemptee，多個Preemptee的搶占結果也需要保證原性。邏輯資源池劃分核思想：刻畫任務類型特征，在資源碎、可性、性能和可維護性之間找到平衡點 有狀態的作業。

12、執遷移和運維動作困難，盡量聚集在批機器上 規模訓練作業。單worker占據整機資源，集群需要預留些空載機器 多實例在線服務。將不同實例打散到不同機器，當節點故障時降低對服務的影響 在邏輯上分成 均衡池 和 聚集池。均衡池負責多實例應的容錯和提升集群整體IO及絡帶寬，聚集池降低尺Pod的等待時間，并將有狀態作業束縛在少量機器上。邏輯資源池只是種優選機制，當聚集池滿了之后，聚集型的Pod也可以被調度到均衡池中，反之亦然。退避機制前提假設：輪調度失敗的任務，在之后輪中概率還是失敗 四級退避設計：指數退避算法，防”壞分”，減少調度器做謂調度，充分保證正常隊列、任務的調度需求，在調度負載場景下可以顯著提

13、升調度吞吐Codelab OperatorCodelab是基于容器實現的實驗開發環境，定位于戶進規模開發實驗，提供隔離獨的開發環境，持久化存儲實驗環境和數據，能快速啟動和恢復 Codelab核功能：1）狀態持久化，持掛起和恢復；2）資源監控；3）集成實驗環境及WebIDE，如JupyterNotebook、PyCharm等 什么是CodelabCodelab系統架構1.Application應層：通過APIService暴露API給戶，渲染Codelab yaml 2.Controller控制層：調諧PC的切為 3.Storage存儲層：Codelab通過PVC掛載或客戶端訪問所需共享存儲Co

14、delab Operator架構準備：前置準備作，如添加Finalizer，申請HDFS訪問token等；創建Pod：根據podTemplate創建Pod及其相關資源 掛起和恢復：通過spec.pause標記掛起和恢復期望，掛起時刪除Pod，恢復時重新創建Pod；同步集群外資源：對接公司內服務樹系統，將Codelab注冊到某個AppKey；刪除和清理：清理效Codelab，從Appkey注銷，并釋放HDFS Token；更新狀態：計算Codelab狀態，并更新.status 通過容器共享掛載實現初始化容器件共享 使EBS存儲持久化戶開發環境，主要包括yum和pip包 使Dolphin FS儲存

15、組內共享的數據和代碼 pc-start.sh作為systemd服務初始化CodelabCodelab啟動過程1.閑時動掛起Codelab，刪除Pod，釋放所占計算資源，保留PV 2.恢復時將重建Pod，重新掛載PV，恢復數據和環境掛起與恢復Dolphin FS接簡介Host Path-CSI 租戶錄唯映射PV，靜態綁定加速調度 多Dolphin FS集群動識別，業務感知 Pod粒度fuse，提升讀寫并發 Fuse進程位于物理機，升級CSI plugin不中斷掛載 持掛載點異常檢測和熱恢復改造前痛點：機器上所有Pod共享同個掛載點，掛載進程異常影響所有Pod 客戶端發重啟，容器內的掛載點丟失，法

16、熱恢復，只能重啟容器 客戶端升級等運維操作會導致掛載中斷，常運維“戰戰兢兢”針對多集群掛載需求，每種上層作業引擎需要重復適配 租戶掛載固定錄，設計個租戶唯映射個PV 預分發租戶PVC和PV，并完成靜態綁定，加速調度過程租戶-PV映射機制多集群動識別 多集群的配置信息存到ConfigMap，并掛載到CSI Pod，持熱更新 CSI通過PV中攜帶的租戶信息定位數據所在Dolphin FS集群，并將對應集群掛載到PodPod Level Fuse 每個Pod都有獨的Fuse進程，即使Fuse進程掛掉，也不影響其他Pod的正常讀寫 Fuse作過程涉及戶態和內核態切換，般對IO的并發有所限制，獨享Fus

17、e在并發IO時具有性能優勢CSI Connector 如在CSI Pod中啟動Fuse進程，container重建導致Fuse進程重啟，穩定性差 借助csi-connector，將Fuse進程代理到物理機，交由systemd來管理，和CSI解耦掛載點檢測和熱恢復 掛載點可以恢復的核關鍵在于：Linux Mount Propagation。CSI雙向傳播掛載kubelet數據錄，錄的掛載/卸載操作會傳播到宿主機 Pod使HostToContainer，可以將宿主機的掛載事件傳播到容器志服務志架構簡介 志收集 志訪問實時收集不可改造成本：對多志缺乏持，改造成本很 收集鏈路的要求：收集鏈路，flue

18、ntbit-log-agent-kafka-es，該架構法解決收集時延、志丟失和失序的問題 離線式能較好解決問題志收集優化志掛載不同pod如何掛載不同錄 通過改造kubelet持如下模式掛載如何感知何時上傳S3 調整kubelet的ttl參數，Pod刪除后保留分鐘容器元數據，輪詢docker接獲取容器信息 兜底：從志路徑還原Pod信息 志訪問優化集群外部署 當節點故障，志服務通過Fail over機制訪問集群外同等接提升訪問成功率 前節點外部署可以避免約0.43%的訪問失敗SEEK接獲取志 S3及本地件均提供seek接，可根據偏移量獲取件內容，提升接效率訓練整體流程作業概覽作業資源監控作業志錄

19、早期架構及升級背景 云原改造過程 關鍵問題和思考 未來規劃規模集群關鍵問題與思考調度能 穩定性 資源效率調度能吞吐量、調度語義的權衡 命周期和是否有狀態對運維的影響穩定性基礎環境的可預期：標準定義、異常發現、異常處理和標準變更 組件穩定性：控制組件和節點組件 資源隔離和QoS：關鍵是場景需要資源效率提升效率的段運維提效，建設動投產、維修系統 異常檢查、動恢復 降低節點級別異常頻率：修復節點端各類問題、隔離系統和業務進程 節點/單卡故障動維修 故障效診斷、維修保有率通過搶占釋放些租戶暫時不使的資源 作業分級，空閑卡跑低優作業 跨集群跨卡型調度機制 混部調度率優化容器啟動速度 全位的作業命周期異常為探測，治理不合理法 MPS、MIG、vGPU等單卡復技術 預測服務彈性伸縮 調度負載率未來規劃完成數據離線和實時場景的云原改造 場景間混部提升資源效率 構建場景適配的調度能 持續提升穩定性和資源效率