Volcano成Spark默認batch調度器

摘要:對於Spark用戶而言,藉助Volcano提供的批量調度、細粒度資源管理等功能,可以更便捷的從Hadoop遷移到Kubernetes,同時大幅提升大規模數據分析業務的性能。

2022年6月16日,Apache Spark 3.3版本正式發布,其中《Support Customized Kubernetes Schedulers》作為Spark 3.3版本的重點(Highlight)特性,其關鍵能力是從框架層面支援訂製化的Kubernetes度器,並且將Volcano作為Spark on Kubernetes的默認batch調度器。這也是Apache Spark社區官方支援Volcano的第一個版本。對於Spark用戶而言,藉助Volcano提供的批量調度、細粒度資源管理等功能,可以更便捷的從Hadoop遷移到Kubernetes,同時大幅提升大規模數據分析業務的性能。

華為牽頭髮起,主流廠商協作

該特性由華為牽頭髮起,由來自華為、Apple、Cloudera、Netflix、Databricks等公司的開發者共同協作完成。通過在Apache Spark支援自定義調度能力,允許用戶插件化使用各種第三方自定義調度。

Spark + Volcano:更完善的調度能力

Spark的資源管理平台正在向Kubernetes演進,Apache Spark現有架構下,Job的單主、多從節點的分離調度,導致了Spark driver節點資源死鎖問題,尤其是在資源緊張的情況下,會經常出現此類問題。同時,由於原生Kubernetes的調度能力受限,也無法完成Job粒度諸如隊列調度、公平調度、資源預留等功能。

Volcano作為CNCF社區首個雲原生批量計算,於2019年6月在上海KubeCon正式開源,並在2020年4月成為CNCF官方項目。2022年4月,Volcano正式晉級為CNCF孵化項目。Volcano社區開源以來,在人工智慧、大數據、基因測序、轉碼、渲染等海量數據計算和分析場景得到快速應用,並構建起完善的上下游生態,目前騰訊、愛奇藝、小紅書、蘑菇街、唯品會、鵬程實驗室、銳天投資等企業均將Volcano應用於生產環境。

Spark 官方支援Volcano將會進一步加速大數據平台遷移到Kubernetes的進程,幫助Spark用戶應對以下常見的批量調度場景。

常見調度場景:

作業級的公平調度 (Job-based Fair-share)

當運行多個彈性作業(如流媒體分析)時,需要公平地為每個作業分配資源,以滿足多個作業競爭附加資源時的SLA/QoS要求。在最壞的情況下,單個作業可能會啟動大量的pod資源利用率低,從而阻止其他作業由於資源不足而無法運行。為了避免分配過小(例如,為每個作業啟動一個Pod),Volcano允許彈性作業定義應該啟動的Pod的最小可用數量。 超過指定的最小可用量的任何pod都將公平地與其他作業共享集群資源。

隊列 (Queue)

隊列還廣泛用於共享彈性工作負載和批處理工作負載的資源。隊列的主要目的是:

  • 在不同的「租戶」或資源池之間共享資源,例如將每一個部門映射到一個隊列,實現多個部門通過隊列的權重,動態共享集群的資源。
  • 為不同的「租戶」或資源池支援不同的調度策略或演算法,如FIFO、Fairness、Priority等

隊列被實現為集群範圍的CRD,和namespace實現了解耦。這允許將在不同namespace中創建的作業放置在一個共享隊列中。隊列還提供了min和max,min是隊列的最小保障資源,任何時刻該隊列有緊急任務提上來都保證有min資源可用,max是隊列資源使用上限。min和max之間的資源如果閑置,允許共享給其他隊列的任務來提升整體的資源利用率。

面向用戶的, 跨隊列的公平調度 (Namespace-based fair-share Cross Queue)

在隊列中,每個作業在調度循環期間有幾乎相等的調度機會,這意味著擁有更多作業的用戶有更大的機會安排他們的作業,這對其他用戶不公平。 例如,有一個隊列包含少量資源,有10個pod屬於UserA,1000個pod屬於UserB。在這種情況下,UserA的pod被綁定到節點的概率較小。

為了平衡同一隊列中用戶之間的資源使用,需要更細粒度的策略。考慮到Kubernetes中的多用戶模型,使用名稱空間來區分不同的用戶, 每個命名空間都將配置一個權重,作為控制其資源使用優先順序的手段。

搶佔 (Preemption & Reclaim)

通過公平分享來支援借貸模型,一些作業/隊列在空閑時會過度使用資源。但是,如果有任何進一步的資源請求,資源「所有者」將「收回」。 資源可以在隊列或作業之間共享:回收用於隊列之間的資源平衡,搶佔用於作業之間的資源平衡。

最小資源預留(minimal resource reservation)

運行擁有多個任務角色的作業時(如Spark)時,Spark driver pod會先創建並運行,然後請求Kube-apiserver創建Spark executor pod,在資源緊張或高並發的場景,時常會出現大量作業提交導致所有可用資源被Spark driver pod耗盡,Spark executor無法獲取資源,最終所有Spark作業無法正常運行。為解決此問題,用戶為Spark driver pod 和 executor pod創建專有節點進行靜態劃分,而這帶來了資源碎片、利用率低下的問題。Volcano提供的minimal resource reservation 允許為每個Spark作業預留資源,防止Spark executor無法獲取資源而導致的死鎖問題,相比於靜態劃分的作法,性能提升30%+。

預留與回填 (Reservation & Backfill)

當一個請求大量資源的「巨大」作業提交給Kubernetes時,當有許多小作業在管道中時,該作業可能會餓死,並最終根據當前的調度策略/演算法被殺死。為了避免飢餓, 應該有條件地為作業保留資源,例如超時。當資源被保留時,它們可能會處於空閑和未使用狀態。為了提高資源利用率,調度程式將有條件地將「較小」作業回填到那些保留資源中。 保留和回填都是根據插件的回饋觸發的:Volcano供了幾個回調介面,供開發人員或用戶決定哪些作業應該被填充或保留。

未來發展

隨著場景的日益豐富,Volcano也在不斷的添加新的演算法,同時,相應的介面也在不斷的完善,方便用戶擴展並自定義相應的演算法。另一方面,社區也在持續的擴大技術版圖支援新的場景如跨雲跨集群調度、混部、FinOps、智慧彈性調度、細粒度資源管理等。

近期我們還會對Spark 3.3中Volcano 帶來的批量調度能力進行詳細技術解讀,敬請期待。添加Volcano小助手k8s2222,進入Volcano社區交流群,大咖在側,定期分享。

Spark 3.3 release notes: //spark.apache.org/releases/spark-release-3-3-0.html

Volcano官網://volcano.sh/zh/docs/

Github : //github.com/volcano-sh/volcano

 

點擊關注,第一時間了解華為雲新鮮技術~