摘要：本篇文章將會從Spark on Kubernetes 發展歷程以及工作原理，以及介紹一下Spark with Volcano，Volcano如何能夠幫助 Spark運行地更高效。
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)支持動態資源分配
