Spark3.0onKubernetes的模式是怎樣的

這篇文章主要介紹“Spark 3.0 on Kubernetes的模式是怎樣的”，在日常操作中，相信很多人在Spark 3.0 on Kubernetes的模式是怎樣的問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Spark 3.0 on Kubernetes的模式是怎樣的”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

成都創(chuàng)新互聯(lián)公司主營監(jiān)利網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營網(wǎng)站建設(shè)方案,重慶App定制開發(fā),監(jiān)利h5成都小程序開發(fā)搭建,監(jiān)利網(wǎng)站營銷推廣歡迎監(jiān)利等地區(qū)企業(yè)咨詢

Spark 3.0發(fā)布后，對Kubernetes的原生支持得到大幅增強，從而方便了Spark在云原生環(huán)境中的快速部署和運行實例的管理。

1. Standalone 模式

Spark 運行在 Kubernetes 集群上的第一種可行方式是將 Spark 以 Standalone 模式運行，但是很快社區(qū)就提出使用 Kubernetes 原生 Scheduler 的運行模式，也就是 Native 的模式。

2. Kubernetes Native 模式

Native 模式簡而言之就是將 Driver 和 Executor Pod 化，用戶將之前向 YARN 提交 Spark 作業(yè)的方式提交給 Kubernetes 的 apiserver，提交命令如下：

$ bin/spark-submit \    --master k8s://https://<k8s-apiserver-host>:<k8s-apiserver-port> \    --deploy-mode cluster \    --name spark-pi \    --class org.apache.spark.examples.SparkPi \    --conf spark.executor.instances=5 \    --conf spark.kubernetes.container.image=<spark-image> \    local:///path/to/examples.jar

其中 master 就是 kubernetes 的 apiserver 地址。提交之后整個作業(yè)的運行方式如下，先將 Driver 通過 Pod 啟動起來，然后 Driver 會啟動 Executor 的 Pod。這些方式很多人應(yīng)該都了解了，就不贅述了，詳細信息可以參考：https://spark.apache.org/docs/latest/running-on-kubernetes.html 。

3. Spark Operator

除了這種直接向 Kubernetes Scheduler 提交作業(yè)的方式，還可以通過 Spark Operator 的方式來提交。Operator 在 Kubernetes 中是一個里程碑似的產(chǎn)物。在 Kubernetes 剛面世的時候，關(guān)于有狀態(tài)的應(yīng)用如何部署在 Kubernetes 上一直都是官方不愿意談?wù)摰脑掝}，直到 StatefulSet 出現(xiàn)。StatefulSet 為有狀態(tài)應(yīng)用的部署實現(xiàn)了一種抽象，簡單來說就是保證網(wǎng)絡(luò)拓撲和存儲拓撲。但是狀態(tài)應(yīng)用千差萬別，并不是所有應(yīng)用都能抽象成 StatefulSet，強行適配反正加重了開發(fā)者的心智負擔。

然后 Operator 出現(xiàn)了。我們知道 Kubernetes 給開發(fā)者提供了非常開放的一種生態(tài)，你可以自定義 CRD，Controller 甚至 Scheduler。而 Operator 就是 CRD + Controller 的組合形式。開發(fā)者可以定義自己的 CRD，比如我定義一種 CRD 叫 EtcdCluster 如下：

apiVersion: "etcd.database.coreos.com/v1beta2"kind: "EtcdCluster"metadata:  name: "example-etcd-cluster"spec:  size: 3  version: "3.1.10"  repository: "quay.io/coreos/etcd"

提交到 Kubernetes 之后 Etcd 的 Operator 就針對這個 yaml 中的各個字段進行處理，最后部署出來一個節(jié)點規(guī)模為 3 個節(jié)點的 etcd 集群。你可以在 github 的這個 repo：https://github.com/operator-framework/awesome-operators 中查看目前實現(xiàn)了 Operator 部署的分布式應(yīng)用。

Google 云平臺，也就是 GCP 在 github 上面開源了 Spark 的 Operator，repo 地址：GoogleCloudPlatform/spark-on-k8s-operator。Operator 部署起來也是非常的方便，使用 Helm Chart 方式部署如下，你可以簡單認為就是部署一個 Kubernetes 的 API Object （Deployment）。

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

這個 Operator 涉及到的 CRD 如下：

ScheduledSparkApplication
|__ ScheduledSparkApplicationSpec
    |__ SparkApplication
|__ ScheduledSparkApplicationStatus

|__ SparkApplication
|__ SparkApplicationSpec
    |__ DriverSpec
        |__ SparkPodSpec
    |__ ExecutorSpec
        |__ SparkPodSpec
    |__ Dependencies
    |__ MonitoringSpec
        |__ PrometheusSpec
|__ SparkApplicationStatus
    |__ DriverInfo

如果我要提交一個作業(yè)，那么我就可以定義如下一個 SparkApplication 的 yaml，關(guān)于 yaml 里面的字段含義，可以參考上面的 CRD 文檔。

apiVersion: sparkoperator.k8s.io/v1beta1kind: SparkApplicationmetadata:  ...spec:  deps: {}  driver:    coreLimit: 200m    cores: 0.1    labels:      version: 2.3.0    memory: 512m    serviceAccount: spark  executor:    cores: 1    instances: 1    labels:      version: 2.3.0    memory: 512m  image: gcr.io/ynli-k8s/spark:v2.4.0  mainApplicationFile: local:///opt/spark/examples/jars/spark-examples_2.11-2.3.0.jar  mainClass: org.apache.spark.examples.SparkPi  mode: cluster  restartPolicy:      type: OnFailure      onFailureRetries: 3      onFailureRetryInterval: 10      onSubmissionFailureRetries: 5      onSubmissionFailureRetryInterval: 20  type: Scalastatus:  sparkApplicationId: spark-5f4ba921c85ff3f1cb04bef324f9154c9  applicationState:    state: COMPLETED  completionTime: 2018-02-20T23:33:55Z  driverInfo:    podName: spark-pi-83ba921c85ff3f1cb04bef324f9154c9-driver    webUIAddress: 35.192.234.248:31064    webUIPort: 31064    webUIServiceName: spark-pi-2402118027-ui-svc    webUIIngressName: spark-pi-ui-ingress    webUIIngressAddress: spark-pi.ingress.cluster.com  executorState:    spark-pi-83ba921c85ff3f1cb04bef324f9154c9-exec-1: COMPLETED  LastSubmissionAttemptTime: 2018-02-20T23:32:27Z

提交作業(yè)。

$ kubectl apply -f spark-pi.yaml

對比來看 Operator 的作業(yè)提交方式似乎顯得更加的冗長復雜，但是這也是一種更 kubernetes 化的 api 部署方式，也就是 Declarative API，聲明式 API。

4. 挑戰(zhàn)

基本上，目前市面的大部門公司都是使用上面兩種方式來做 Spark on Kubernetes 的，但是我們也知道在 Spark Core 里面對 Kubernetes 的這種 Native 方式支持其實并不是特別成熟，還有很多可以改善的地方，下面簡單舉例幾個地方：

1.scheduler 差異

資源調(diào)度器可以簡單分類成集中式資源調(diào)度器和兩級資源調(diào)度器。兩級資源調(diào)度器有一個中央調(diào)度器負責宏觀資源調(diào)度，對于某個應(yīng)用的調(diào)度則由下面分區(qū)資源調(diào)度器來做。兩級資源調(diào)度器對于大規(guī)模應(yīng)用的管理調(diào)度往往能有一個良好的支持，比如性能方面，缺點也很明顯，實現(xiàn)復雜。其實這種設(shè)計思想在很多地方都有應(yīng)用，比如內(nèi)存管理里面的 tcmalloc 算法，Go 語言的內(nèi)存管理實現(xiàn)。大數(shù)據(jù)的資源調(diào)度器 Mesos/Yarn，某種程度上都可以歸類為兩級資源調(diào)度器。

集中式資源調(diào)度器對于所有的資源請求進行響應(yīng)和決策，這在集群規(guī)模大了之后難免會導致一個單點瓶頸，毋庸置疑。但是 Kubernetes 的 scheduler 還有一點不同的是，它是一種升級版，一種基于共享狀態(tài)的集中式資源調(diào)度器。Kubernetes 通過將整個集群的資源緩存到 scheduler 本地，在進行資源調(diào)度的時候在根據(jù)緩存的資源狀態(tài)來做一個 “樂觀” 分配（assume + commit）來實現(xiàn)調(diào)度器的高性能。

Kubernetes 的默認調(diào)度器在某種程度上并不能很好的 match Spark 的 job 調(diào)度需求，對此一種可行的技術(shù)方案是再提供一種 custom scheduler 或者直接重寫，比如 Spark on Kubernetes Native 方式的參與者之一的大數(shù)據(jù)公司 Palantir 就開源了他們的 custom scheduler，github repo: https://github.com/palantir/k8s-spark-scheduler。

2. Shuffle 處理

由于 Kubernetes 的 Executor Pod 的 Shuffle 數(shù)據(jù)是存儲在 PV 里面，一旦作業(yè)失敗就需要重新掛載新的 PV 從頭開始計算。針對這個問題，F(xiàn)acebook 提出了一種 Remote Shuffle Service 的方案，簡單來說就是將 Shuffle 數(shù)據(jù)寫在遠端。直觀感受上來說寫遠端怎么可能比寫本地快呢？而寫在遠端的一個好處是 Failover 的時候不需要重新計算，這個特性在作業(yè)的數(shù)據(jù)規(guī)模異常大的時候比較有用。

3. 集群規(guī)模

基本上現(xiàn)在可以確定的是 Kubernetes 會在集群規(guī)模達到五千臺的時候出現(xiàn)瓶頸，但是在很早期的時候 Spark 發(fā)表論文的時候就聲稱 Spark Standalone 模式可以支持一萬臺規(guī)模。Kubernetes 的瓶頸主要體現(xiàn)在 master 上，比如用來做元數(shù)據(jù)存儲的基于 raft 一致性協(xié)議的 etcd 和 apiserver 等。對此在剛過去的 2019 上海 KubeCon 大會上，阿里巴巴做了一個關(guān)于提高 master 性能的 session: 了解 Kubernetes Master 的可擴展性和性能，感興趣的可以自行了解。

4.Pod 驅(qū)逐（Eviction）問題

在 Kubernetes 中，資源分為可壓縮資源（比如 CPU）和不可壓縮資源（比如內(nèi)存），當不可壓縮資源不足的時候就會將一些 Pod 驅(qū)逐出當前 Node 節(jié)點。國內(nèi)某個大廠在使用 Spark on kubernetes 的時候就遇到因為磁盤 IO 不足導致 Spark 作業(yè)失敗，從而間接導致整個測試集都沒有跑出來結(jié)果。如何保證 Spark 的作業(yè) Pod (Driver/Executor) 不被驅(qū)逐呢？這就涉及到優(yōu)先級的問題，1.10 之后開始支持。但是說到優(yōu)先級，有一個不可避免的問題就是如何設(shè)置我們的應(yīng)用的優(yōu)先級？常規(guī)來說，在線應(yīng)用或者 long-running 應(yīng)用優(yōu)先級要高于 batch job，但是顯然對于 Spark 作業(yè)來說這并不是一種好的方式。

5. 作業(yè)日志

Spark on Yarn 的模式下，我們可以將日志進行 aggregation 然后查看，但是在 Kubernetes 中暫時還是只能通過 Pod 的日志查看，這塊如果要對接 Kubernetes 生態(tài)的話可以考慮使用 fluentd 或者 filebeat 將 Driver 和 Executor Pod 的日志匯總到 ELK 中進行查看。

6.Prometheus 生態(tài)

Prometheus 作為 CNCF 畢業(yè)的第二個項目，基本是 Kubernetes 監(jiān)控的標配，目前 Spark 并沒有提供 Prometheus Sink。而且 Prometheus 的數(shù)據(jù)讀取方式是 pull 的方式，對于 Spark 中 batch job 并不適合使用 pull 的方式，可能需要引入 Prometheus 的 pushgateway。

到此，關(guān)于“Spark 3.0 on Kubernetes的模式是怎樣的”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

文章標題：Spark3.0onKubernetes的模式是怎樣的
本文鏈接：http://muchs.cn/article32/jepspc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、外貿(mào)網(wǎng)站建設(shè)、App設(shè)計、做網(wǎng)站、網(wǎng)站設(shè)計、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)