Spark in action on Kubernetes -
前言
Spark是非常流行的大数据处理引擎，数据科学家们使用Spark以及相关生态的大数据套件完成了大量又丰富场景的数据分析与挖掘。Spark目前已经逐渐成为了业界在数据处理领域的行业标准。但是Spark本身的设计更偏向使用静态的资源管理，虽然Spark也支持了类似Yarn等动态的资源管理器，但是这些资源管理并不是面向动态的云基础设施而设计的，在速度、成本、效率等领域缺乏解决方案。随着Kubernetes的快速发展，数据科学家们开始考虑是否可以用Kubernetes的弹性与面向云原生等特点与Spark进行结合。在Spark 2.3中，Resource Manager中添加了Kubernetes原生的支持，而本系列我们会给大家介绍如何用更Kubernetes的方式在集群中使用Spark进行数据分析。本系列不需要开发者有丰富的Spark使用经验，对着系列的逐渐深入，会穿插讲解使用到的Spark特性。
搭建Playground
很多的开发者在接触Hadoop的时候，被安装流程的复杂度打消了很多的积极性。为了降低学习的门槛，本系列会通过spark-on-k8s-operator作为Playground，简化大家的安装流程。spark-on-k8s-operator顾名思义是为了简化Spark操作而开发的operator，如果对operator不是很了解的开发者，可以先自行搜索了解下，理解operator能做什么可以快速帮你掌握spark-on-k8s-operator的要领。
在讲解内部原理前，我们先将环境搭建起来，通过一个简单的demo，跑通整个的运行时环境。
1. 安装spark-on-k8s-operator
官方的文档是通过Helm Chart进行安装的，由于很多开发者的环境无法连通google的repo，因此此处我们通过标准的yaml进行安装。
## 下载repo
git clone git@github.com:AliyunContainerService/spark-on-k8s-operator.git
## 安装crd
kubectl apply -f manifest/spark-operator-crds.yaml
## 安装operator的服务账号与授权策略
kubectl apply -f manifest/spark-operator-rbac.yaml
## 安装spark任务的服务账号与授权策略
kubectl apply -f manifest/spark-rbac.yaml
## 安装spark-on-k8s-operator
kubectl apply -f manifest/spark-operator.yaml
验证安装结果
此时在spark-operator的命名空间下的无状态应用下，可以看到一个运行中的sparkoperator，表名此时组件已经安装成功，接下来我们运行一个demo应用来验证组件是否可以正常工作。
2. Demo验证
学习Spark的时候，我们运行的第一个任务是官方文档中介绍的圆周率运行的例子。今天我们换一种方式，通过Kubernetes的方式再运行一次。
## 下发spark-pi任务
kubectl apply -f examples/spark-pi.yaml
任务下发成功后，可以通过命令行观察任务的状态。
## 查询任务
kubectl describe sparkapplication spark-pi
## 任务结果
Name: spark-pi
Namespace: default
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"sparkoperator.k8s.io/v1alpha1","kind":"SparkApplication","metadata":{"annotations":{},"name":"spark-pi","namespace":"defaul...
API Version: sparkoperator.k8s.io/v1alpha1
Kind: SparkApplication
Metadata:
Creation Timestamp: 2019-01-20T10:47:08Z
Generation: 1
Resource Version: 4923532
Self Link: /apis/sparkoperator.k8s.io/v1alpha1/namespaces/default/sparkapplications/spark-pi
UID: bbe7445c-1ca0-11e9-9ad4-062fd7c19a7b
Spec:
Deps:
Driver:
Core Limit: 200m
Cores: 0.1
Labels:
Version: 2.4.0
Memory: 512m
Service Account: spark
Volume Mounts:
Mount Path: /tmp
Name: test-volume
Executor:
Cores: 1
Instances: 1
Labels:
Version: 2.4.0
Memory: 512m
Volume Mounts:
Mount Path: /tmp
Name: test-volume
Image: gcr.io/spark-operator/spark:v2.4.0
Image Pull Policy: Always
Main Application File: local:///opt/spark/examples/jars/spark-examples_2.11-2.4.0.jar
Main Class: org.apache.spark.examples.SparkPi
Mode: cluster
Restart Policy:
Type: Never
Type: Scala
Volumes:
Host Path:
Path: /tmp
Type: Directory
Name: test-volume
Status:
Application State:
Error Message:
State: COMPLETED
Driver Info:
Pod Name: spark-pi-driver
Web UI Port: 31182
Web UI Service Name: spark-pi-ui-svc
Execution Attempts: 1
Executor State:
Spark - Pi - 1547981232122 - Exec - 1: COMPLETED
Last Submission Attempt Time: 2019-01-20T10:47:14Z
Spark Application Id: spark-application-1547981285779
Submission Attempts: 1
Termination Time: 2019-01-20T10:48:56Z
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SparkApplicationAdded 55m spark-operator SparkApplication spark-pi was added, Enqueuing it for submission
Normal SparkApplicationSubmitted 55m spark-operator SparkApplication spark-pi was submitted successfully
Normal SparkDriverPending 55m (x2 over 55m) spark-operator Driver spark-pi-driver is pending
Normal SparkExecutorPending 54m (x3 over 54m) spark-operator Executor spark-pi-1547981232122-exec-1 is pending
Normal SparkExecutorRunning 53m (x4 over 54m) spark-operator Executor spark-pi-1547981232122-exec-1 is running
Normal SparkDriverRunning 53m (x12 over 55m) spark-operator Driver spark-pi-driver is running
Normal SparkExecutorCompleted 53m (x2 over 53m) spark-operator Executor spark-pi-1547981232122-exec-1 completed
此时我们发现任务已经执行成功，查看这个Pod的日志，我们可以到计算最终的结果为Pi is roughly 3.1470557352786765。至此，在Kubernetes上，已经跑通了第一个Job，接下来我们要来详解一下刚才这一波操作到底都做了些什么。
Spark Operator的基础架构浅析
这张图是Spark Operator的流程图，在上面的操作中，第一个步骤里面，实际上是将图中的中心位置蓝色的Spark Operator安装到集群中，Spark Opeartor本身即是是一个CRD的Controller也是一个Mutating Admission Webhook的Controller。当我们下发spark-pi模板的时候，会转换为一个名叫SparkApplication的CRD对象，然后Spark Operator会监听Apiserver，并将SparkApplication对象进行解析，变成spark-submit的命令并进行提交，提交后会生成Driver Pod，用简单的方式理解，Driver Pod就是一个封装了Spark Jar的镜像。如果是本地任务，就直接在Driver Pod中执行；如果是集群任务，就会通过Driver Pod再生成Exector Pod进行执行。当任务结束后，可以通过Driver Pod进行运行日志的查看。此外在任务的执行中，Spark Operator还会动态attach一个Spark UI到Driver Pod上，希望查看任务状态的开发者，可以通过这个UI页面进行任务状态的查看。
最后
在本文中，我们讨论了Spark Operator的设计初衷，如何快速搭建一个Spark Operator的Playground以及Spark Operator的基本架构与流程。在下一篇文章中，我们会深入到Spark Operator的内部，为大家讲解其内部的实现原理以及如何与Spark更无缝的集成。
本文作者：莫源
本文为云栖社区原创内容，未经允许不得转载。
