|
副标题[/!--empirenews.page--]
云原生时代，Kubernetes 的重要性日益凸显，这篇文章以 Spark 为例来看一下大数据生态 on Kubernetes 生态的现状与挑战。
1. Standalone 模式
Spark 运行在 Kubernetes 集群上的第一种可行方式是将 Spark 以 Standalone 模式运行，但是很快社区就提出使用 Kubernetes 原生 Scheduler 的运行模式，也就是 Native 的模式。关于 Standalone 模式这里就没有继续讨论的必要了。
2. Kubernetes Native 模式
Native 模式简而言之就是将 Driver 和 Executor Pod 化，用户将之前向 YARN 提交 Spark 作业的方式提交给 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 地址。提交之后整个作业的运行方式如下，先将 Driver 通过 Pod 启动起来，然后 Driver 会启动 Executor 的 Pod。这些方式很多人应该都了解了，就不赘述了，详细信息可以参考：https://spark.apache.org/docs/latest/running-on-kubernetes.html 。
3. 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 地址：。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
如果我要提交一个作业，那么我就可以定义如下一个 SparkApplication 的 yaml，关于 yaml 里面的字段含义，可以参考上面的 CRD 文档。
- apiVersion: sparkoperator.k8s.io/v1beta1
- kind: SparkApplication
- metadata:
- ...
- 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: Scala
- status:
- 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
提交作业。
- $ kubectl apply -f spark-pi.yaml
对比来看 Operator 的作业提交方式似乎显得更加的冗长复杂，但是这也是一种更 kubernetes 化的 api 部署方式，也就是 Declarative API，声明式 API。
4. 挑战
基本上，目前市面的大部门公司都是使用上面两种方式来做 Spark on Kubernetes 的，但是我们也知道在 Spark Core 里面对 Kubernetes 的这种 Native 方式支持其实并不是特别成熟，还有很多可以改善的地方：
1.scheduler 差异。
（编辑：核心网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
