那麼對於在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的設計思路和基本流程後，還需要深入瞭解的就是sparkapplication的狀態都包含哪些，他們之間是如何進行轉換的，因爲這是Spark Operator對於生命週期管理增強最重要的部分。

一個Spark的作業任務可以通過上述的狀態機轉換圖進行表示，一個正常的作業任務經歷如下幾個狀態：

而當任務失敗的時候會進行重試，若重試超過最大重試次數則會失敗。也就是說如果在任務的執行過程中，由於資源、調度等因素造成Pod被驅逐或者移除，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等能力的集成與支持。在下一篇中，會爲大家介紹在kubernetes集羣中，提交spark作業時的如何使用外部存儲存儲的最佳實踐。

-------------------------------

本文作者：莫源

原文鏈接：https://yq.aliyun.com/articles/695315?utm_content=g_1000050597

本文爲雲棲社區原創內容，未經允許不得轉載。

聲明：該文觀點僅代表作者本人，搜狐號系信息發佈平臺，搜狐僅提供信息存儲空間服務。