【云駐共創(chuàng)】基于Volcano的大規(guī)模分布式離線計(jì)算平臺(tái)的應(yīng)用實(shí)踐

一、背景

在一些企業(yè)業(yè)務(wù)場(chǎng)景中，需要使用離線集群提供的虛擬機(jī)保證策略人員的研究和開(kāi)發(fā)，以及AI訓(xùn)練和非AI訓(xùn)練都會(huì)在集群上進(jìn)行處理。而數(shù)據(jù)源一方面是線上每天產(chǎn)生大量的數(shù)據(jù)，另一方面是從第三方數(shù)據(jù)商獲取的大量數(shù)據(jù)，這些所有的數(shù)據(jù)都通過(guò)一個(gè)穩(wěn)定的ETL流程匯總到分布式存儲(chǔ)上。然而，通常情況下數(shù)據(jù)形式和內(nèi)容參差不齊，此時(shí)就需要進(jìn)行大規(guī)模計(jì)算實(shí)行數(shù)據(jù)清洗和數(shù)據(jù)預(yù)處理操作。其中，分布式批處理任務(wù)也需要運(yùn)行在集群上。

下文以銳天投資基于Volcano的大規(guī)模分布式離線計(jì)算平臺(tái)的應(yīng)用實(shí)踐為例，描述Volcano的相關(guān)功能及解決方案。

二、技術(shù)選型

（1）Kubernetes作為容器集群管理工具

通過(guò)Container 隔離用戶環(huán)境。不同的用戶、開(kāi)發(fā)環(huán)境和策略各不相同，python/java，環(huán)境直接封裝在Container 中，方便快捷。

通過(guò)Device Plugin 支持GPU 等異構(gòu)設(shè)備，無(wú)論對(duì)于調(diào)度，還是對(duì)于資源管理，都是有很大的好處。

ETCD 的中心式數(shù)據(jù)存儲(chǔ)機(jī)制。整體管理非常好用，隨心所欲地重啟，如果備份整個(gè)集群，只需要對(duì)ETCD中數(shù)據(jù)進(jìn)行備份。

活躍健全的技術(shù)生態(tài)和社區(qū)內(nèi)容，新特性頻繁發(fā)布

Go 語(yǔ)言符合公司技術(shù)棧

（2）文件系統(tǒng)使用Ceph提供的分布式文件存儲(chǔ)CephFS

Posix Filesystem 權(quán)限與接口。對(duì)于普通用戶，最佳的文件獲取接口就是一個(gè)文件管理系統(tǒng)。Posix Filesystem 權(quán)限管理讓用戶將自己的權(quán)限無(wú)縫遷移到Ceph上面。

強(qiáng)一致性。在A節(jié)點(diǎn)寫入一個(gè)文件，B節(jié)點(diǎn)可以直接讀取，好處：通過(guò)數(shù)據(jù)交互的形式達(dá)到信息交互。

同時(shí)支持大規(guī)模小文件存取與大帶寬IO。CephFS元數(shù)據(jù)服務(wù)器，可以對(duì)多個(gè)子目錄深度進(jìn)行負(fù)載均衡，滿足大規(guī)模小文件存取。

層級(jí)化硬件支持，機(jī)械硬盤，SSD，能夠在提供穩(wěn)定性能的同時(shí)讓容量達(dá)到一定量級(jí)的唯一方案，讓硬件資源得到很好的利用，節(jié)省成本。

Kubernetes ReadWriteMany PV，所有節(jié)點(diǎn)讀取同一個(gè)原始數(shù)據(jù)，生成模型數(shù)據(jù)，必須是ReadWriteMany形式才可以。

三、選擇Volcano

容器管理和存儲(chǔ)已經(jīng)選擇完畢，剩下的關(guān)鍵就是資源調(diào)度的選擇。

（1）Why not default-scheduler

default-scheduler無(wú)法滿足需求，最重要的是無(wú)法滿足公平調(diào)度，通常多個(gè)團(tuán)隊(duì)同時(shí)使用集群，任務(wù)過(guò)多時(shí)，下一個(gè)任務(wù)資源應(yīng)該給誰(shuí)，這意味著基于隊(duì)列的公平調(diào)度和基于用戶的公平調(diào)度都是必不可少的。

缺少隊(duì)列調(diào)度

缺少公平調(diào)度

缺少多租戶支持

缺少高級(jí)調(diào)度策略，如Gang-Scheduling，浪費(fèi)資源，浪費(fèi)是最大的敵人

（2）Why not kube-batch

下圖為kube-batch在Github頁(yè)面介紹，圖中依舊很詳細(xì)的寫出了kube-batch只是一個(gè)調(diào)度器，不提供調(diào)度以外的任何解決方案。我們需要做一個(gè)批處理解決方案，而不只是需要一個(gè)調(diào)度器，那么顯然kube-batch是不滿足的。

（3）Why is Volcano

Volcano是CNCF 下首個(gè)也是唯一的基于Kubernetes的容器批量計(jì)算平臺(tái)，主要用于高性能計(jì)算場(chǎng)景。它提供了Kubernetes目前缺少的一套機(jī)制，這些機(jī)制通常是機(jī)器學(xué)習(xí)大數(shù)據(jù)應(yīng)用、科學(xué)計(jì)算、特效渲染等多種高性能工作負(fù)載所需的。

支持公平調(diào)度

支持豐富的高級(jí)調(diào)度策略，如Gang-Scheduling、Binpack等

支持通過(guò)SSH plugin 方式實(shí)現(xiàn)Pod 互訪

支持通過(guò)ENV plugin 方式向Pod 注入任務(wù)依賴，天然支持Tensorflow Worker Sharding

支持SVC plugin 方式對(duì)外提供服務(wù)

基于上述各種架構(gòu)平臺(tái)，整個(gè)系統(tǒng)服務(wù)架構(gòu)如下圖

基礎(chǔ)設(shè)施層是Ceph和Kubernetes，基于 Ceph 提供高性能存儲(chǔ)。

基于 Kubernetes 管理多種異構(gòu)硬件，通過(guò)Volcano調(diào)度整個(gè)系統(tǒng)。

Loki 和Grafana 用于收集日志，以及同時(shí)作為用戶面板與監(jiān)控面板。

應(yīng)用層為Batch Job、Machine Learning、ETL，基于 Batch Job 形式，擴(kuò)展多種業(yè)務(wù)場(chǎng)景。

中間件可選，Redis提供存儲(chǔ)，Kafka提供message信息處理，ClickHouse提供DB相關(guān)處理形式。同時(shí)中間件還有諸多好處：提供用戶更多的接口，實(shí)現(xiàn)更多的形式來(lái)讓用戶使用，中間件與應(yīng)用層混部，充分使用集群資源。

（4）多租戶問(wèn)題

采用的是社區(qū)中比較經(jīng)常使用的方案。Kubernetes namespace做用戶所有資源隔離 ，每個(gè)namespace對(duì)應(yīng)一個(gè)用戶，LDAP+OIDC與開(kāi)發(fā)對(duì)接，給用戶一個(gè)認(rèn)證。RBAC用戶資源的授權(quán)，授權(quán)用戶使用Pod Security Policy，限制用戶提交時(shí)必須采用Security Context寫上自己的UID，用戶運(yùn)行時(shí)的環(huán)境以此為準(zhǔn)。

（5）工作流

解決完上述問(wèn)題以后，一個(gè)基礎(chǔ)的工作流出現(xiàn)。本地渲染 Job Yaml進(jìn)行提交，用戶所有依賴數(shù)據(jù)全部同步在CephFS，并通過(guò)PVC掛載Pod。每個(gè)用戶Nmaespace下，擁有自己目錄的PVC權(quán)限。

四、Volcano的深度定制

上述功能和設(shè)計(jì)依然無(wú)法滿足部分需求，在系統(tǒng)運(yùn)行過(guò)程中，遇到了各種各樣的問(wèn)題，必須對(duì)Volcano進(jìn)行改造。

（1）自研提交工具——Jobctl

定制任何東西，都需要一個(gè)基礎(chǔ)的提交框架平臺(tái)，Jobctl同時(shí)支持命令行提交和 Python Lib 集成。兩種提交形式：異步：不停的提交任務(wù)，提交完就退出，可以提交各種參數(shù)組合提交一大堆任務(wù)到集群。同步：提交完一個(gè)任務(wù)以后，當(dāng)任務(wù)完成后再返回給用戶。以及可以自動(dòng)生成復(fù)雜 Job 配置，對(duì)用戶隔離 Kubernetes 復(fù)雜性。提供最基礎(chǔ)的按replicas并行與按天并行。

（2）OOM Auto Scale Up

問(wèn)題：用戶不是技術(shù)人員，不能很好預(yù)估內(nèi)存，OOM 后需要重復(fù)提交驗(yàn)證，可能需要重復(fù)多次，影響用戶體驗(yàn)。

解決：將OOMKill所申請(qǐng)的資源按比例放大，放大以后通過(guò)OOMKill Auto Scale Up 自動(dòng)重復(fù)提交，得到合理內(nèi)存申請(qǐng)值。能夠在用戶不參與的情況下重復(fù)提交，最終得到合理內(nèi)存申請(qǐng)值

（3）MinSuccess

問(wèn)題：minAvailable個(gè)Pod 結(jié)束，則任務(wù)結(jié)束，非Gang 的任務(wù)難以靈活調(diào)度。

解決：添加minSuccess參數(shù)，minSuccess個(gè)Pod 結(jié)束，則任務(wù)結(jié)束，以及解耦Gang 所需Task 數(shù)量和完成Job 所需任務(wù)數(shù)量，以此來(lái)完成整個(gè)任務(wù)的生命周期。

（4）NodeZone

問(wèn)題：一個(gè)Volcano 實(shí)例管理所有節(jié)點(diǎn), 無(wú)法解決Noisy Neighbor，以及無(wú)法做到緊急資源預(yù)留。

解決：隔離多個(gè)Volcano 實(shí)例，分別管理多個(gè)Zone，對(duì)某些任務(wù)做物理隔離。

（5）Volcano Namespace Quota

問(wèn)題：觸發(fā)原生Namespace Quota 時(shí)，Pod 直接Fail，然而對(duì)于某些 Fail的Pod，會(huì)導(dǎo)致其他Pod無(wú)法運(yùn)行，造成很大影響。

解決：觸發(fā)Volcano Namespace Quota 時(shí)，Pod 排隊(duì)延遲創(chuàng)建。

（6）Volcano 監(jiān)控與報(bào)警

希望可以直接依賴時(shí)序存儲(chǔ)，在Grafana直接展示監(jiān)控面板。監(jiān)控任務(wù)失敗報(bào)警，減少浪費(fèi)資源。

Volcano Exporter

輸出Task 的隊(duì)列標(biāo)簽

輸出隊(duì)列Capability

輸出Job 的開(kāi)始完成時(shí)間

WatchDog組件

注冊(cè)Informer，并收集Metrics

負(fù)責(zé)任務(wù)失敗與使用率報(bào)警

自動(dòng)更新隊(duì)列的Capability

五、高并發(fā)場(chǎng)景下的挑戰(zhàn)與解決方案

隨著平臺(tái)的發(fā)展和用戶的需求增加，依舊會(huì)出現(xiàn)很多問(wèn)題。主要是集群規(guī)模過(guò)大：

單集群計(jì)算節(jié)點(diǎn)數(shù)量200，存儲(chǔ)總量1.5PB，讀寫帶寬15GB/s。同時(shí)承載長(zhǎng)時(shí)間任務(wù)（1week）與短時(shí)間任務(wù)（1min），長(zhǎng)時(shí)間任務(wù)不能停止，非常耗費(fèi)時(shí)間，短時(shí)間任務(wù)，如遺傳算法不停的迭代，造成 pod增長(zhǎng)很快，進(jìn)一步的導(dǎo)致Pod 每日增長(zhǎng)量10W ~ 30W

（1）單個(gè)Job對(duì)象過(guò)大

問(wèn)題：在有大量Pod 時(shí)超過(guò)ETCD Max Request Size (1.5MB)。直接調(diào)整Max Request Size，大量的Object對(duì)ETCD 造成沖擊。

解決：通過(guò)單個(gè)Task 多Replica 的形式提交任務(wù)。Pod 內(nèi)部通過(guò)ENVplugin 插件提供的信息，以Sharding的形式讀取參數(shù)。

（2）Out Of CPU/Memory

問(wèn)題：節(jié)點(diǎn)數(shù)少，并且大量短時(shí)任務(wù)不停調(diào)度，KubeletPLEG 壓力大，Pod Binding 時(shí)間過(guò)長(zhǎng)。Volcano 默認(rèn)session 間隔時(shí)間為1s，造成Cache Snapshot不一致，導(dǎo)致Out of CPU 以及 Out of Memory。

解決：增加Node Binding Task Number，在Session 開(kāi)始創(chuàng)建Snapshot 時(shí)，跳過(guò)Binding Task Number > 0 的Node。

六、總結(jié)

通過(guò)Kubernetes 統(tǒng)一管理計(jì)算資源，CephFS統(tǒng)一管理存儲(chǔ)資源

通過(guò)用戶認(rèn)證與用戶Uid限制，保證權(quán)限統(tǒng)一

通過(guò)Volcano Job 的Replica 來(lái)Shading 每個(gè)Pod 讀取的參數(shù)

通過(guò)MinSuccess和MinAvaliable控制Job 的調(diào)度和完成行為

通過(guò)NodeZone和Queue 控制計(jì)算資源隔離共享分配

已在每日30W Pod 的大規(guī)模集群上穩(wěn)定運(yùn)行

通過(guò)分析銳天投資的基于Volcano的應(yīng)用實(shí)踐，對(duì)多個(gè)相似工具進(jìn)行比較中，Volcano是功能較為完善和高效的，Volcano繼承了Kubernetes接口的設(shè)計(jì)風(fēng)格和核心概念?？梢栽诔浞窒硎躒olcano的高效性和便利性的同時(shí)不用改變?nèi)魏我郧笆褂肒ubernetes的習(xí)慣，并且對(duì)于某些場(chǎng)景，原始Volcano即使不能很好滿足，用戶也可以自由定制，為己所用。

附：本文整理自銳天投資：基于Volcano的大規(guī)模分布式離線計(jì)算平臺(tái)的應(yīng)用實(shí)踐，點(diǎn)此回看

查看活動(dòng)：https://bbs.huaweicloud.com/blogs/266530

Kubernetes Volcano 分布式

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。