Spark-Submit 和 K8S Operation For Spark

文章目录

  • 1 Overview
  • 2 译文
    • 2.2 A Deeper Look At Spark-Submit
    • 2.3 How Does Spark-Submit Work
    • 2.4 A Look At Kubernetes Operator For Apache Spark
    • 2.4 How Kubernetes Operator For Spark Works
  • 3 Summary

1 Overview

本文翻译自 Lightbend 的一篇文章,文章日期还比较新,2019/02/26。文章分为两部分,翻译也将分为两个部分。附上文章链接如下:

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 中,我们会介绍到如何监控和管理部署在 K8S 的 Spark 集群。Part 2 里(译文也在第二部分),我们将深入了解 K8S 的原生的 Operator for Spark。

不久前,Spark 在 2.3 版本的时候已经将 K8S 作为原生的调度器实现了,这意味着我们可以按照官网的介绍,利用 spark-submit 来提交 Spark 作业到 K8S 集群,就像提交给 Yarn 和 Mesos 集群一样。

尽管通过这种方法,还是比较容易使用的,但是这里仍然有很多的诸如管理和监控的特性是用户比较关注的,而 spark-submit 暂时无法提供的。这就是为什么 K8S 会去做一个 Operator for Spark 出来了,因为通过 Operator,作业管理和监控都可以用更 K8S 的方式来原生实现,使用 Operator 会让使用 K8S 运行 Spark 作业更加容易。Operator for Spark 与其他 Operator 一样,扩展了 K8S API,实现了 CRD,也就是自定义资源类型 Custom Resource。

本文的目的就是去比较 spark-submit 和 Operator for Spark,在易用性和使用体验上的差异,也想为那些关注 Spark 和 K8S 生态的用户和开发者、架构师等,去了解这两种方式的一些利弊。以下是本文的一些 highlight。

关于 spark-submit

  • spark-submit 是 Apache Spark 项目的一部分
  • 在即将到来的 Spark 3.0,关于 Spark Pods 的配置上会跟 Operator 靠拢
  • 在管理 K8S 集群的 Spark 作业上有一定的局限性

关于 K8S 的 Operator for Spark

  • 一个将 Spark 作业提交给 K8S 集群的工具
  • 一个典型的基于 K8S Operator 模式的实现
  • 使用了 spark-submit 作为 hook
  • 支持定义 Spark Pods 的时候挂载 Volume 和 ConfigMap(Apache 2.4 并没有提供的功能)
  • 有专用的 CLI 来管理 Spark 作业

2.2 A Deeper Look At Spark-Submit

spark-submit 用来提交 Spark 作业到 K8S 集群,就像在 YARN 和 Mesos 集群都可以。它也允许用户传递一些可选的参数给 Spark Master。以下是一个典型的提交 Spark 作业到 K8S 集群的命令。

./spark-submit
--master  k8s://https://  
--deploy-mode cluster \
--name spark-pi \
--class org.apache.spark.examples.SparkPi \
--conf spark.kubernetes.namespace=spark \
--conf spark.kubernetes.authenticate.driver.serviceAccountName=spark-sa \
--conf spark.executor.instances=2 \
--conf spark.kubernetes.container.image.pullPolicy=Always \
--conf spark.kubernetes.container.image=lightbend/spark:2.0.1-OpenShift-2.4.0-rh \
local:///opt/spark/examples/jars/spark-examples_2.11-2.4.0.jar

Spark-Submit 和 K8S Operation For Spark_第1张图片

spark-submit 利用 pod watcher 来监控提交的过程,如果没问题的话,结束的时候输出如下图。

Spark-Submit 和 K8S Operation For Spark_第2张图片

CLI 这种模式是比较容易实现的,只需要一个支持提交 K8S 集群的版本的 Spark 部署。但这种方案还是有点弊端的,比如说不能针对提交过的作业提供更多的管理方法,又或者不允许 spark-submit 来定制 Spark 的 Pods,此种需求可能还是有必要的。当然,这个问题会在 Spark 3.0 得到解决。

2.3 How Does Spark-Submit Work

在 Client 模式,spark-submit 直接将 Spark 作业通过 Spark 环境变量初始化了,这意味着,Spark 的 Driver 运行在了 spark-submit 端,而 Spark 的 Executor 是运行在 K8S 集群的。

在 Cluster 模式,spark-submit 代表了作业提交到 K8S 的带哦度后端,是因为其通过 K8S 集群创建了 Driver 的 Pod,然后 Pods 再被 K8S 集群调度作为 Executor 来运行 Spark 作业。

Spark-Submit 和 K8S Operation For Spark_第3张图片

2.4 A Look At Kubernetes Operator For Apache Spark

关于 Spark 的 Operator 是由 Google 的 GCP 团队来做的,而且也已经开源了。Operator for Spark 实现了 Operator 的模式,将 Spark Application 的运行和管理封装在了自定义资源 custom resources,以及定义了自定义的控制器 custom controller。

Operator 定义了两个自定义资源,分别是 SparkApplication 和 ScheduledSparkApplication。他们是 Spark 作业为了运行在 K8S 上的一层抽象。通过自定义资源,可以与提交到 K8S 集群的 Spark 作业交互,并且使用原生的 K8S 工具,例如 kuberctl 来调控这些作业。

自定义资源就是让你存储和获取这些结构化的 Spark 作业。当和 custom controller 结合的时候,就会变成真正的解释式的 API,这样可以让你指定需要的 Spark 作业状态,以及尝试去匹配真实状态的 Spark 作业。

Spark-Submit 和 K8S Operation For Spark_第4张图片

在上图中,你可以看到一旦作业被描述为 spark-pi.yaml 文件,并且通过 kubectl/sparkctl 提交到 K8S 的 API server,custom controller 就会将这个文件转化为 CRD 对象,也就是 SparkApplication 或者 ScheduledSparkApplication。

然后 K8S 的相关参数以及 spark-submit 的参数就会结合一起,提交给 API Server,然后就会像写 spark-submit 脚本一样,在 K8S 集群中创建 Driver Pod 以及 Executor Pod。

这里再比较一下 spark-submit 和 Operator for Spark 的一些异同点。

首先,当一个 Volume 或者 ConfigMap 在 Pod 被设置了,一个修改的确定 webhook 会拦截 Pod 的创建请求,并且在 Pods 被持久化之前进行修改。

然后就是 Operator 有一个组件叫做 pod event handler,可以检测 Spark Pods 的事件,以及根据 SparkAppclication 和 ScheduledSparkApplcation 的事件不断地更新自己的状态。

Spark 作业的另一个表现形式可以是 ConfigMap,但是在实现 Spark 作业的这种情况下,还是建议用 CRD,原因在于,如果希望将 Spark 作业更好的集成到 K8S 集群里,那么使用 CRD 这种方案,可以使用现成的 K8S 的工具栈,比如 kubectl,这些工具可以更方便的去构建或者更新一个 Spark 作业。

2.4 How Kubernetes Operator For Spark Works

SparkApplication 和 ScheduledSparkApplication 这些 CRD,可以用 YAML 文件来定义,并且被 K8S 解释式的执行。与 spark-submit 脚本不同的是,Operator 是需要安装的,Helm chart 是常用的工具,而已管理 K8S 的 charts 等资源。Helm chart 可以视为是一组文件,可以描述 K8S 相关的一些资源,并且可以作为一个单元来部署。

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

安装成功的输出如下图可见。

Spark-Submit 和 K8S Operation For Spark_第5张图片

这会安装需要的 CRDs 和自定义的控制器,并且设置 RBAC,安装了可变的权限 webhook,并且配置了 Prometheus 来做监控。

pi.yaml:

apiVersion: "sparkoperator.k8s.io/v1beta1"
kind: SparkApplication
metadata:
  name: spark-pi
  namespace: spark
spec:
  type: Scala
  mode: cluster
  image: "lightbend/spark:2.0.0-OpenShift-2.4.0"
  imagePullPolicy: Always
  mainClass: org.apache.spark.examples.SparkPi
  mainApplicationFile: "local:///opt/spark/examples/jars/spark-examples_2.11-2.4.0.jar"
  sparkVersion: "2.4.0"
  restartPolicy:
    type: Never
  driver:
    cores: 0.1
    coreLimit: "200m"
    memory: "512m"
    labels:
      version: 2.4.0
    serviceAccount: spark-sa
  executor:
    cores: 1
    instances: 1
    memory: "512m"
    labels:
      version: 2.4.0

Spark Application 控制器负责监控 SparkApplication CRD 对象,以及提交 Spark Application。在 App 被提交之后,控制器的监视 Application 的状态,例如 SUBMITTED, RUNNING, COMPLETED 等等。

Application 的状态转移可以从 Operator 的 Pod 日志中提取出来。下面是 SUBMITEED -> RUNNING 的转移。

Spark-Submit 和 K8S Operation For Spark_第6张图片

3 Summary

本文主要介绍了利用 Spark 官方对 K8S 的支持,利用 spark-submit 提交 Spark 作业到 K8S 集群的方式,以及利用 K8S (非官方)的 Operator for Spark 来运行 Spark 作业的异同点。

显然本文反复提示的,就是 spark-submit,也就是目前 spark 2.4 提供的功能中,是不能对 Spark 作业进行交互式的参数调整的,而 Operator 方案相比 spark-submit 则是天然地支持这种方式。

你可能感兴趣的:(Spark,Kubernetes)