大數據場景下Volcano高效調度能力實踐

Spark on Kubernetes

我們來看Spark on Kubernetes的背景。其實Spark在從2.3這個版本開始之后，就已經支持了Kubernetes native，可以讓Spark的用戶可以把作業運行在Kubernetes上，用Kubernetes去管理資源層。在2.4版本里增加了client mode和Python語言的支持。而在今年的發布的Spark 3.0里面，對Spark on Kubernetes這一方面也增加了很多重要的特性，增加動態資源分配、遠端shuffle service以及 Kerberos 支持等。

Spark on Kubernetes的優勢：

1）彈性擴縮容

2）資源利用率

3）統一技術棧

4）細粒度的資源分配

5）日志和監控

Spark submit 工作原理

Spark對于Kubernetes的支持，最早的一種工作方式是通過 Spark官方的spark submit方式去支持，Clinet通過Spark submit提交作業，然后spark driver會調用apiserver的一些api去申請創建 executor，executor都起來之后，就可以執行真正的計算任務，之后會做日志備份。

這種方式有一個優勢是，傳統的 Spark用戶切換到這種方式之后用戶體驗改變大。但也存在缺少作業周期管理的缺陷。

Spark-operator 工作原理

第二種Spark on Kubernetes的使用方式就是operator。operator是更Kubernetes的方式，你看他的整個作業提交，先是yaml文件通過kubectl提交作業，在這里面它有自己的crd，即SparkApplication，Object。創建了SparkApplication之后， Controller可以watch到這些資源的創建，后邊流程其實是復用的第一種工作模式，但是通過這種模式，做的更完善的一些。

相對于第一種方式來講，這里的Controller可以維護對象生命周期，可以watch spark driver的狀態，并更新application的狀態，是一個更完善的解決方案。

這兩種不同的使用方式使用是各有優勢，不少的公司兩種方式都有使用。這一塊在官網也有介紹。

Spark with Volcano

Volcano對于上面提到兩種工作方式都進行了集成和支持。這個鏈接是我們維護的 Spark開源代碼倉庫：

https://github.com/huawei-cloudnative/spark/tree/spark-2.4-volcano-0.1

在這里面Volcano做的事情其實也很簡單，你看整個提交的過程，首先是通過spark submit提交作業，提交作業時會創建一個podgroup，podgroup包含了用戶配置的一些調度相關的信息。它的yaml文件大家可以看到，頁面右邊這個部分，增加了driver和executor兩個角色。

Volcano 隊列

隊列其實我們在第一堂和第二堂課里面也講到了。因為Kubernetes里面沒有隊列的支持，所以它在多個用戶或多個部門在共享一個機器的時候資源沒辦法做共享。但不管在HPC還是大數據領域里，通過隊列進行資源共享都是基本的需求。

在通過隊列做資源共享時，我們提供了多種機制。圖最上面的這種，這里面我們創建兩個隊列，通過這兩個隊列去共享整個集群的資源，一個隊列給他分40%的咨詢資源，另一個給他分60%的資源，這樣的話就可以把這兩個不同的隊列映射到不同的部門或者是不同的項目各自使用一個隊列。這在一隊列里，資源不用的時候，可以給另外一個隊列里面的作業去使用。下面講的是兩個不同的namespace之間的資源平衡。Kubernetes里當兩個不同的應用系統的用戶都去提交作業時，提交作業越多的用戶，他獲得的集群的資源會越多，所以在這里面基于namespace，我們進行公平的調度，保證namespace之間可以按照權重分享集群的資源。

Volcano: Pod delay creation

之前介紹這個場景的時候，有些同學反映沒有太聽懂，所以我加了幾頁PPT擴展一下。

舉個例子，我們在做性能測試的時候，提交16個并發的作業，對于每個作業來講，它的規格是1 driver+4 executor，整個集群總共有4臺機器16個核，這樣的一個情況。

同時提交16個spark job的時候，driver pod的創建和executor pod的創建之間有一個時間差。因為有這個時間差，當16個spark的job跑起來之后把整個機群全部占滿了，就會導致同時提交并發量特別大作業的時候，整個集群卡死。

為了解決這種情況，我們做了這樣的事情。

讓一個節點專門去跑driver pod。其他三個節點專門去跑executor pod，防止driver pod占用更多的資源，就可以解決被卡死的問題。

但也有不好的地方，這個例子里節點是1:3的關系。在真實的場景下，用戶的作業的規格都是動態的， 而這種分配是通過靜態的方式去劃分，沒辦法跟真實的業務場景里動態的比例保持一致，總是會存在一些資源碎片，會有資源的浪費。

因此，我們增加了Pod delay creation的功能，增加這個功能之后不需要對node去做靜態的劃分，整個還是4個節點，在16個作業提上來的時候，對于每個作業增加了podgroup的概念。Volcano的調度器會根據提上來作業的podgroup進行資源規劃。

這樣就不會讓過多的作業會提交上來。不但可以把4個節點里面所有的資源全部用完，而且沒有任何的浪費，在高并發的場景下控制pod創建的節奏。它的使用也非常簡單，可以按照你的需求配資源量，解決高并發的場景下運行卡死或者運營效率不高的情況。

Volcano: Spark external shuffle service

我們知道原來的Spark已經很完善了，有很多特別好用的功能，Volcano保證了遷移到Kubernetes上之后沒有大的功能缺失：

1)ESS以daemonset的方式部署在每個節點

2)Shuffle本地寫Shuffle數據，本地、遠端讀shuffle數據

3)支持動態資源分配

Kubernetes 大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。