怎么進行Spark in action on Kubernetes - Spark Operator的原理解析

怎么進行Spark in action on Kubernetes - Spark Operator的原理解析，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

前言

今天我們會繼續使用Playground進行調試與解析，幫助大家更深入的理解Spark Operator的工作原理。

Spark Operator的內部實現

在深入解析Spark Operator之前，我們先補充一些關于kubernetes operator的知識。2018年可以說是kubernetes operator泛濫的一年,各種operator如雨后春筍般出現。operator是擴展kubernetes以及與kubernetes集成的最佳方式之一。在kubernetes的設計理念中，有很重要的一條就是進行了抽象，比如對存儲進行抽象、對應用負載進行抽象、對接入層進行抽象等等。每個抽象又對應了各自生命周期管理的controller，開發者提交的Yaml實際上是對抽象終態的描述，而controller會監聽抽象的變化、解析并進行處理，最終嘗試將狀態修正到終態。

那么對于在kubernetes中未定義的抽象該如何處理呢，答案就是operator。一個標準operator通常包含如下幾個部分：1. CRD抽象的定義，負責描述抽象所能包含的功能。 2.CRD Controller ，負責解析CRD定義的內容以及生命周期的管理。3.clent-go的SDK，負責提供代碼集成時使用的SDK。

有了這個知識儲備，那么我們回過頭來看Spark Operator的代碼，結構基本就比較明晰了。核心的代碼邏輯都在pkg下，其中apis下面主要是定義了不同版本的API；client目錄下主要是自動生成的client-go的SDK；crd目錄下主要是定義的兩個自定義資源sparkapplication和scheduledsparkapplication的結構。controller目錄下主要定義的就是這個operator的生命周期管理的邏輯；config目錄下主要處理spark config的轉換。了解一個Operator能力最快捷的方式，就是查看CRD的定義。在Spark Operator中定義了sparkapplication和scheduledsparkapplication兩個CRD，他們之間有什么區別呢？

sparkapplication 是對常規spark任務的抽象，作業是單次運行的，作業運行完畢后，所有的Pod會進入Succeed或者Failed的狀態。而scheduledsparkapplication是對離線定時任務的一種抽象，開發者可以在scheduledsparkapplication中定義類似crontab的任務，實現spark離線任務的周期性定時調度。

上面這張圖是Spark中kubernetes的集成圖，也就是說當我們通過spark-submit提交作業的時候，會自動生成driver pod與exector pods。那么引入了Spark Operator后，這個流程變成了什么呢？

其實到此，我們就已經基本了解Spark Operator做的事情了，首先定義了兩種不同的CRD對象，分別對應普通的計算任務與定時周期性的計算任務，然后解析CRD的配置文件，拼裝成為spark-submit的命令，通過prometheus暴露監控數據采集接口，創建Service提供spark-ui的訪問。然后通過監聽Pod的狀態，不斷回寫更新CRD對象，實現了spark作業任務的生命周期管理。

Spark Operator的任務狀態機

當我們了解了Spark Operator的設計思路和基本流程后，還需要深入了解的就是sparkapplication的狀態都包含哪些，他們之間是如何進行轉換的，因為這是Spark Operator對于生命周期管理增強最重要的部分。

一個Spark的作業任務可以通過上述的狀態機轉換圖進行表示。

而當任務失敗的時候會進行重試，若重試超過最大重試次數則會失敗。也就是說如果在任務的執行過程中，由于資源、調度等因素造成Pod被驅逐或者移除，Spark Operator都會通過自身的狀態機狀態轉換進行重試。

Spark Operator的狀態排查

我們已經知道了Spark Operator最核心的功能就是將CRD的配置轉換為spark-submit的命令，那么當一個作業運行不預期的時候，我們該如何判斷是哪一層出現的問題呢？首先我們要判斷的就是spark-submit時所生成的參數是否是預期的，因為CRD的Yaml配置雖然可以增強表達能力，但是提高了配置的難度與出錯的可能性。

默認情況下Spark Operator會通過glog level=2等級對外輸出每次作業提交后轉換的提交命令。而默認情況下，glog的level即為2，因此通過檢查Spark Operator的Pod日志可以協助開發者快速排查問題。此外在sparkapplication上面也會通過event的方式進行狀態的記錄，上述狀態機之間的轉換都會通過event的方式體現在sparkapplication的對象上。掌握這兩種方式進行問題排查，可以節省大量排錯時間。

使用Spark Operator是在kubernetes上實踐spark的最佳方式，和傳統的spark-submit相比提供了更多的故障恢復與可靠性保障，并且提供了監控、日志、UI等能力的集成與支持。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。