、三种式：
1. 原kubernetes的调度式。官档《Running Spark on Kubernetes》;
2. 是由歌发起维护的管Spark应程序命周期的Kubernetes插件，叫做SparkOperator。官档《spark-on-k8s-operator》;
3. 就是standalone的式，就是在Kubernetes集群直接跑套Spark的集群。这个没有官档参考；
、分析：
第种：
1. 该项本来是由第三在持直到前被DEPRECATED，项地址《Apache Spark enhanced with native Kubernetes scheduler
back-end》。现在该项的后续持已经交由Spark官在集成，但是各项在被DEPRECATED的那个项中的功能还没完全集成官的Spark
应中，如：本地件依赖管的持等。
2. 该式的调度就没有master、worker的概念，通过spark submit提交应程序到kubernetes直接启动的是driver和excutor，具体启
动instance的数和要使的资源根据配置定。并且在也会在kubernetes集群中直运着spark的进程，是每次提交应的时候才
启动driver和excutor，当计算应结束后excutor所在的pod被回收，driver会被下供查看志等并等待kubernetes动回收策
回收或者预删除pod。
3. 提交应和原spark提交唯参数区别就是master样，实如下：
bin/spark-submit \
--master k8s://https://10.0.10.197:6443 \
--deploy-mode cluster \
--name spark-SparkPi \
--class org.apache.spark.examples.SparkPi \
--conf spark.executor.instances=1 \
--conf spark.kubernetes.container.image=kubespark/spark:2.3.2 \
--conf spark.kubernetes.namespace=default \
--conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
--conf spark.kubernetes.submission.waitAppCompletion=false \
local:///opt/spark/examples/jars/spark-examples_2.11-2.3.2.java
4. 这我们看到，提交Spark的应程序则需要我们在任何提交Spark应的机上要有个编译好的Spark进制包（需要运，只是借助
它的spark-submit命令能），并需要配置java环境供spark-submit运。
5. 该式需要编译Spark来持kubernetes，当然官打包编译好的件是已经持的，如果编译就需要带上-Pkubernetes参数，可参
考如下命令：
./build/mvn -Pkubernetes -Phadoop-2.7 -Dhadoop.version=2.7.3 -Phive -Phive-thriftserver -DskipTests clean
packag
6. 当然该式也是需要我们打包个持Kubernetes的docker镜像的，并且需要将镜像分发到所有的Kubernetes机节点或者上传到我们的
私有镜像仓库中供kubernetes使，打包镜像命令官也提供，参考如下命令：
./bin/docker-image-tool.sh -r kubespark -t 2.3.2 buil
8. 应志查看式再出现Spark Master UI，也没有History Server存储运后的志，且Driver UI只能在Driver运期间才
能查看，旦Driver命周期结束也就能查看。但是我们可以通过Kubernetes来查看运情况，如通过kubectl logs driver-
pod-name或者通过Kubernetes Dashboard从界去查看。
9. 资源的分配直接交由kubernetes管。
第种：
1. 该式需要在Kubernetes集群部署SparkOperator以持直接通过部署常规应样来部署Spark应，这样我们就可以直接通过编
写yaml件来运Spark应，也需要应程序提交客户机上要有持spark-submit的持，只需要个yaml件。运件实：
apiVersion: "sparkoperator.k8s.io/v1beta1"
kind: SparkApplication
metadata:
name: spark-pi
namespace: default
spec:
type: Scala
mode: cluster
image: "kubespark/spark:2.4.2"
imagePullPolicy: IfNotPresent
mainClass: org.apache.spark.examples.SparkPi
mainApplicationFile: "http://10.0.10.197:30010/spark/spark-examples_2.12-2.4.2.jar"
sparkVersion: "2.4.2"
restartPolicy:
type: Never
driver:
cores: 0.1
coreLimit: "200m"
memory: "512m"
labels:
version: 2.4.2
serviceAccount: spark
executor:
cores: 1
instances: 1
memory: "512m"
labels:
version: 2.4.2
2. 但是该项还处于beta阶段还在断的完善。
3. 该式除需要再Kubernetes集群部署SparkOperator以外，同样需要第种式中的持Kubernetes的Spark编译打包后的镜像，
打包式同第种式。
4. 该式和第种样，没有Spark进程实现运着等待应提交，机制和第种样只运driver和excutor，也没有master和worker的概
念。
5. 资源的使也是直接交由kubernetes管。
第三种：
1. 这种式和宿主机直接运Spark集群乎没么得区别，唯的就是得于Kubernetes的能Worker可以很任性的伸缩。
2. 这种式就是在Kubernetes集群中部署套Spark的Standalone的集群，并且是直运着Master和N份Worker等待应的提交。启动
yaml配置如下：
apiVersion: v1
kind: Namespace
metadata:
name: spark-cluster
labels:
name: spark-cluster
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: spark-master
namespace: spark-cluster
labels:
name: spark-master
spec:
replicas: 1
template:
metadata:
labels:
name: spark-master
spec:
hostname: spark-master
containers:
- name: spark-master
image: spark:2.3.2
imagePullPolicy: IfNotPresent
ports:
- containerPort: 7077
- containerPort: 8080
- containerPort: 6066
command:
- "/bin/bash"
- "-c"
args :
- './start-master.sh ; tail -f /dev/null'
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: spark-worker
namespace: spark-cluster
labels:
name: spark-worker
spec:
replicas: 3
template:
metadata:
labels:
name: spark-worker
spec:
containers:
- name: spark-worker
image: spark:2.3.2
imagePullPolicy : IfNotPresent
ports:
- containerPort: 8081
command:
- "/bin/bash"
- "-c"
args :
- './start-worker.sh ; tail -f /dev/null'
---
kind: ReplicationController
apiVersion: v1
metadata:
name: spark-ui-proxy
namespace: spark-cluster
spec:
replicas: 1
selector:
name: spark-ui-proxy
template:
metadata:
labels:
name: spark-ui-proxy
spec:
hostname: spark-ui-proxy
containers:
- name: spark-ui-proxy
image: spark-ui-proxy:1.0
imagePullPolicy : IfNotPresent
ports:
- containerPort: 80
resources:
requests:
cpu: 100m
args:
- spark-master:8080
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 120
timeoutSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: spark-master
namespace: spark-cluster
labels:
name: spark-master
spec:
clusterIP: None
ports:
- name: webui
port: 8080
targetPort: 8080
- name: spark
port: 7077
targetPort: 7077
- name: rest
port: 6066
targetPort: 6066
selector:
name: spark-master
---
kind: Service
apiVersion: v1
metadata:
name: spark-worker
namespace: spark-cluster
spec:
ports:
- name: workerui
port: 8081
targetPort: 8081
selector:
name: spark-worker
---
kind: Service
apiVersion: v1
metadata:
name: spark-ui-proxy
namespace: spark-cluster
spec:
ports:
- port: 80
targetPort: 80
selector:
name: spark-ui-proxy
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: spark-ingress
namespace: spark-cluster
spec:
rules:
- http:
paths:
- path: /sparkui
backend:
serviceName: spark-ui-proxy
servicePort: 80
- path: /proxy
backend:
serviceName: spark-ui-proxy
servicePort: 80
- path: /app
backend:
serviceName: spark-ui-proxy
servicePort: 80
3. 该种式唯由Kubernetes接管的资源就是Master和Work可资源，就是启动Master和Worker的时候给它们配置的资源，但是我们提交的
应程序需要的资源仍然是由Master来管控的，当然Master能多少是Kubernetes来管控的。
4. 该种运式在提交应程序在deploy-mode使cluster的时候由于Worker运Excutor的时候使的计算机的hostname作为Driver
URL使，spark集群所在计算机的hostname需要事先配置好，但是搬到Kubernetes上后由于Worker节点是通过Kubernetes的pod启动的
多副本Deployment，hostname是随机成可预知能提前配置导致exceutor能启动。经多番折腾通过Kubernetes暂能解决该问
题，最后只能通过修改spark源码通过ip式可以解决。但是影响范围需要张奇确认（论对spark源码熟悉度张奇莫属）。
5. 提交应式也是通过spark-submit式，和宿主机部署集群提交式样。实：
./bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master spark://spark-master:7077 \
--deploy-mode client \
--executor-memory 1G \
--total-executor-cores 2 \
/spark/examples/jars/spark-examples_2.11-2.3.2.jar \
1000
./bin/spark-submit \
--class org.apache.spark.examples.SparkPi \
--master spark://spark-master:6066 \
--deploy-mode cluster \
--executor-memory 1G \
--total-executor-cores 2 \
/spark/examples/jars/spark-examples_2.11-2.3.2.jar \
1000
6. 此式我们也需要将spark打包成docker镜像来运，打包式和上两种式对kubernetes原始资源持需要的镜像包有所同，就是将宿
主机运式的命令使在镜像已。
7. 志的查看和宿主机运也没缺别，管是Master UI还是History Server。
三、对：
1. 第种式有官持，应该会越来越好，且持原的Kubernetes资源调度；
2. 第种式也是持，基于第种式和Kubernetes的深度集成（建议采这种式）；
3. 第三种standalone式，只是把Spark集群部署搬到Kubernetes持Kubernetes原资源调度，只是和只是集群交由Kubernetes管
控已；
评论0