Spark on Kubernetes 的現狀與挑戰

搜狐財經 2019-09-27 01:27 搶發第一評

原標題：Spark on Kubernetes 的現狀與挑戰

作者:

陶克路，花名敵琺，阿里巴巴技術專家。Apache Pulsar 等開源軟件 Contributor。技術領域包括大數據和云原生技術棧，目前致力于構建大數據領域業界領先的 APM 產品。

云原生時代，Kubernetes 的重要性日益凸顯，這篇文章以 Spark 為例來看一下大數據生態 on Kubernetes 生態的現狀與挑戰。

Standalone 模式

Spark 運行在 Kubernetes 集群上的第一種可行方式是將 Spark 以 Standalone 模式運行，但是很快社區就提出使用 Kubernetes 原生 Scheduler 的運行模式，也就是 Native 的模式。關于 Standalone 模式這里就沒有繼續討論的必要了。

Kubernetes Native 模式

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

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

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

Spark Operator

除了這種直接想 Kubernetes Scheduler 提交作業的方式，還可以通過 Spark Operator 的方式來提交。Operator 在 Kubernetes 中是一個非常重要的里程碑。在 Kubernetes 剛面世的時候，關于有狀態的應用如何部署在 Kubernetes 上一直都是官方不愿意談論的話題，直到 StatefulSet 出現。StatefulSet 為有狀態應用的部署實現了一種抽象，簡單來說就是保證網絡拓撲和存儲拓撲。但是狀態應用千差萬別，并不是所有應用都能抽象成 StatefulSet，強行適配反正加重了開發者的心智負擔。

然后 Operator 出現了。我們知道 Kubernetes 給開發者提供了非常開放的一種生態，你可以自定義 CRD，Controller 甚至 Scheduler。而 Operator 就是 CRD + Controller 的組合形式。開發者可以定義自己的 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 中的各個字段進行處理，最后部署出來一個節點規模為 3 個節點的 etcd 集群。你可以在 github 的這個 repo：https://github.com/operator-framework/awesome-operators 中查看目前實現了 Operator 部署的分布式應用。

Google 云平臺，也就是 GCP 在 github 上面開源了 Spark 的 Operator，repo 地址：https://github.com/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 --namespacespark-operator

這個 Operator 涉及到的 CRD 如下：

ScheduledSparkApplication |__ ScheduledSparkApplicationSpec |__SparkApplication |__ ScheduledSparkApplicationStatus

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

apiVersion: sparkoperator.k8s.io/v1beta1kind: SparkApplicationmetadata:...spec:deps: {}driver:coreLimit: 200mcores: 0.1labels:version: 2.3.0memory: 512mserviceAccount: sparkexecutor:cores: 1instances: 1labels:version: 2.3.0memory: 512mimage: gcr.io/ynli-k8s/spark:v2.4.0mainApplicationFile: local:///opt/spark/examples/jars/spark-examples_2.11-2.3.0.jarmainClass: org.apache.spark.examples.SparkPimode: clusterrestartPolicy:type: OnFailureonFailureRetries: 3onFailureRetryInterval: 10onSubmissionFailureRetries: 5onSubmissionFailureRetryInterval: 20type: Scalastatus:sparkApplicationId: spark-5f4ba921c85ff3f1cb04bef324f9154c9applicationState:state: COMPLETEDcompletionTime: 2018-02-20T23:33:55ZdriverInfo:podName: spark-pi-83ba921c85ff3f1cb04bef324f9154c9-driverwebUIAddress: 35.192.234.248:31064webUIPort: 31064webUIServiceName: spark-pi-2402118027-ui-svcwebUIIngressName: spark-pi-ui-ingresswebUIIngressAddress: spark-pi.ingress.cluster.comexecutorState:spark-pi-83ba921c85ff3f1cb04bef324f9154c9-exec-1: COMPLETEDLastSubmissionAttemptTime: 2018-02-20T23:32:27Z

提交作業。

$kubectl apply -f spark-pi.yaml

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

挑戰

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

1.scheduler 差異。

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

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

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

2.集群規模瓶頸。

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

3.Pod 驅逐（Eviction）問題。

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

4.作業日志。

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

5.Prometheus 生態。

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

結語

被稱為云上 OS 的 Kubernetes 是 Cloud Native 理念的一種技術承載與體現，但是如何通過 Kubernetes 來助力大數據應用還是有很多可以探索的地方。歡迎交流。

參考：