1 Overview

本文翻譯自 Lightbend 的一篇文章，文章日期還比較新，2019/02/26。文章分為兩部分，翻譯也將分為兩個(gè)部分。附上文章鏈接如下:

https://www.lightbend.com/blog/how-to-manage-monitor-spark-on-kubernetes-introduction-spark-submit-kubernetes-operator

2 譯文

翻譯開始

這兩部分的博客系列里，我們將介紹如何使用 spark-submit 和 K8S 的 Operation for Spark。在 Part 1 中，我們會(huì)介紹到如何監(jiān)控和管理部署在 K8S 的 Spark 集群。Part 2 里（譯文也在第二部分），我們將深入了解 K8S 的原生的 Operator for Spark。

不久前，Spark 在 2.3 版本的時(shí)候已經(jīng)將 K8S 作為原生的調(diào)度器實(shí)現(xiàn)了，這意味著我們可以按照官網(wǎng)的介紹，利用 spark-submit 來(lái)提交 Spark 作業(yè)到 K8S 集群，就像提交給 Yarn 和 Mesos 集群一樣。

盡管通過(guò)這種方法，還是比較容易使用的，但是這里仍然有很多的諸如管理和監(jiān)控的特性是用戶比較關(guān)注的，而 spark-submit 暫時(shí)無(wú)法提供的。這就是為什么 K8S 會(huì)去做一個(gè) Operator for Spark 出來(lái)了，因?yàn)橥ㄟ^(guò) Operator，作業(yè)管理和監(jiān)控都可以用更 K8S 的方式來(lái)原生實(shí)現(xiàn)，使用 Operator 會(huì)讓使用 K8S 運(yùn)行 Spark 作業(yè)更加容易。Operator for Spark 與其他 Operator 一樣，擴(kuò)展了 K8S API，實(shí)現(xiàn)了 CRD，也就是自定義資源類型 Custom Resource。

本文的目的就是去比較 spark-submit 和 Operator for Spark，在易用性和使用體驗(yàn)上的差異，也想為那些關(guān)注 Spark 和 K8S 生態(tài)的用戶和開發(fā)者、架構(gòu)師等，去了解這兩種方式的一些利弊。以下是本文的一些 highlight。

關(guān)于 spark-submit

• spark-submit 是 Apache Spark 項(xiàng)目的一部分
• 在即將到來(lái)的 Spark 3.0，關(guān)于 Spark Pods 的配置上會(huì)跟 Operator 靠攏
• 在管理 K8S 集群的 Spark 作業(yè)上有一定的局限性

關(guān)于 K8S 的 Operator for Spark

• 一個(gè)將 Spark 作業(yè)提交給 K8S 集群的工具
• 一個(gè)典型的基于 K8S Operator 模式的實(shí)現(xiàn)
• 使用了 spark-submit 作為 hook
• 支持定義 Spark Pods 的時(shí)候掛載 Volume 和 ConfigMap（Apache 2.4 并沒(méi)有提供的功能）
• 有專用的 CLI 來(lái)管理 Spark 作業(yè)

2.2 A Deeper Look At Spark-Submit

spark-submit 用來(lái)提交 Spark 作業(yè)到 K8S 集群，就像在 YARN 和 Mesos 集群都可以。它也允許用戶傳遞一些可選的參數(shù)給 Spark Master。以下是一個(gè)典型的提交 Spark 作業(yè)到 K8S 集群的命令。

spark-submit 利用 pod watcher 來(lái)監(jiān)控提交的過(guò)程，如果沒(méi)問(wèn)題的話，結(jié)束的時(shí)候輸出如下圖。

CLI 這種模式是比較容易實(shí)現(xiàn)的，只需要一個(gè)支持提交 K8S 集群的版本的 Spark 部署。但這種方案還是有點(diǎn)弊端的，比如說(shuō)不能針對(duì)提交過(guò)的作業(yè)提供更多的管理方法，又或者不允許 spark-submit 來(lái)定制 Spark 的 Pods，此種需求可能還是有必要的。當(dāng)然，這個(gè)問(wèn)題會(huì)在 Spark 3.0 得到解決。

2.3 How Does Spark-Submit Work

在 Client 模式，spark-submit 直接將 Spark 作業(yè)通過(guò) Spark 環(huán)境變量初始化了，這意味著，Spark 的 Driver 運(yùn)行在了 spark-submit 端，而 Spark 的 Executor 是運(yùn)行在 K8S 集群的。

在 Cluster 模式，spark-submit 代表了作業(yè)提交到 K8S 的帶哦度后端，是因?yàn)槠渫ㄟ^(guò) K8S 集群創(chuàng)建了 Driver 的 Pod，然后 Pods 再被 K8S 集群調(diào)度作為 Executor 來(lái)運(yùn)行 Spark 作業(yè)。

2.4 A Look At Kubernetes Operator For Apache Spark

關(guān)于 Spark 的 Operator 是由 Google 的 GCP 團(tuán)隊(duì)來(lái)做的，而且也已經(jīng)開源了。Operator for Spark 實(shí)現(xiàn)了 Operator 的模式，將 Spark Application 的運(yùn)行和管理封裝在了自定義資源 custom resources，以及定義了自定義的控制器 custom controller。

Operator 定義了兩個(gè)自定義資源，分別是 SparkApplication 和 ScheduledSparkApplication。他們是 Spark 作業(yè)為了運(yùn)行在 K8S 上的一層抽象。通過(guò)自定義資源，可以與提交到 K8S 集群的 Spark 作業(yè)交互，并且使用原生的 K8S 工具，例如 kuberctl 來(lái)調(diào)控這些作業(yè)。

自定義資源就是讓你存儲(chǔ)和獲取這些結(jié)構(gòu)化的 Spark 作業(yè)。當(dāng)和 custom controller 結(jié)合的時(shí)候，就會(huì)變成真正的解釋式的 API，這樣可以讓你指定需要的 Spark 作業(yè)狀態(tài)，以及嘗試去匹配真實(shí)狀態(tài)的 Spark 作業(yè)。

在上圖中，你可以看到一旦作業(yè)被描述為 spark-pi.yaml 文件，并且通過(guò) kubectl/sparkctl 提交到 K8S 的 API server，custom controller 就會(huì)將這個(gè)文件轉(zhuǎn)化為 CRD 對(duì)象，也就是 SparkApplication 或者 ScheduledSparkApplication。

然后 K8S 的相關(guān)參數(shù)以及 spark-submit 的參數(shù)就會(huì)結(jié)合一起，提交給 API Server，然后就會(huì)像寫 spark-submit 腳本一樣，在 K8S 集群中創(chuàng)建 Driver Pod 以及 Executor Pod。

這里再比較一下 spark-submit 和 Operator for Spark 的一些異同點(diǎn)。

首先，當(dāng)一個(gè) Volume 或者 ConfigMap 在 Pod 被設(shè)置了，一個(gè)修改的確定 webhook 會(huì)攔截 Pod 的創(chuàng)建請(qǐng)求，并且在 Pods 被持久化之前進(jìn)行修改。

然后就是 Operator 有一個(gè)組件叫做 pod event handler，可以檢測(cè) Spark Pods 的事件，以及根據(jù) SparkAppclication 和 ScheduledSparkApplcation 的事件不斷地更新自己的狀態(tài)。

Spark 作業(yè)的另一個(gè)表現(xiàn)形式可以是 ConfigMap，但是在實(shí)現(xiàn) Spark 作業(yè)的這種情況下，還是建議用 CRD，原因在于，如果希望將 Spark 作業(yè)更好的集成到 K8S 集群里，那么使用 CRD 這種方案，可以使用現(xiàn)成的 K8S 的工具棧，比如 kubectl，這些工具可以更方便的去構(gòu)建或者更新一個(gè) Spark 作業(yè)。

2.4 How Kubernetes Operator For Spark Works

SparkApplication 和 ScheduledSparkApplication 這些 CRD，可以用 YAML 文件來(lái)定義，并且被 K8S 解釋式的執(zhí)行。與 spark-submit 腳本不同的是，Operator 是需要安裝的，Helm chart 是常用的工具，而已管理 K8S 的 charts 等資源。Helm chart 可以視為是一組文件，可以描述 K8S 相關(guān)的一些資源，并且可以作為一個(gè)單元來(lái)部署。

helm repo add incubator http://storage.googleapis.com/kubernetes-charts-incubator helm install incubator/sparkoperator --namespace spark-operator

安裝成功的輸出如下圖可見。

這會(huì)安裝需要的 CRDs 和自定義的控制器，并且設(shè)置 RBAC，安裝了可變的權(quán)限 webhook，并且配置了 Prometheus 來(lái)做監(jiān)控。

pi.yaml

Spark Application 控制器負(fù)責(zé)監(jiān)控 SparkApplication CRD 對(duì)象，以及提交 Spark Application。在 App 被提交之后，控制器的監(jiān)視 Application 的狀態(tài)，例如 SUBMITTED, RUNNING, COMPLETED 等等。

Application 的狀態(tài)轉(zhuǎn)移可以從 Operator 的 Pod 日志中提取出來(lái)。下面是 SUBMITEED -> RUNNING 的轉(zhuǎn)移。

3 Summary

本文主要介紹了利用 Spark 官方對(duì) K8S 的支持，利用 spark-submit 提交 Spark 作業(yè)到 K8S 集群的方式，以及利用 K8S （非官方）的 Operator for Spark 來(lái)運(yùn)行 Spark 作業(yè)的異同點(diǎn)。

顯然本文反復(fù)提示的，就是 spark-submit，也就是目前 spark 2.4 提供的功能中，是不能對(duì) Spark 作業(yè)進(jìn)行交互式的參數(shù)調(diào)整的，而 Operator 方案相比 spark-submit 則是天然地支持這種方式。

總結(jié)

以上是生活随笔為你收集整理的spark中local模式与cluster模式使用场景_Spark-Submit 和 K8S Operation For Spark的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。