共计 2651 个字符，预计需要花费 7 分钟才能阅读完成。
摘要：本篇文章将会从 Spark on Kubernetes 倒退历程以及工作原理，以及介绍一下 Spark with Volcano，Volcano 如何可能帮忙 Spark 运行地更高效。
本篇文章将会从 Spark on Kubernetes 倒退历程以及工作原理，第二局部大略介绍一下 Spark with Volcano，Volcano 如何可能帮忙 Spark 运行地更高效。
Spark on Kubernetes
咱们来看 Spark on Kubernetes 的背景。其实 Spark 在从 2.3 这个版本开始之后，就曾经反对了 Kubernetes native，能够让 Spark 的用户能够把作业运行在 Kubernetes 上，用 Kubernetes 去治理资源层。在 2.4 版本里减少了 client mode 和 Python 语言的反对。而在往年的公布的 Spark 3.0 外面，对 Spark on Kubernetes 这一方面也减少了很多重要的个性，减少动静资源分配、远端 shuffle service 以及 Kerberos 反对等。
Spark on Kubernetes 的劣势：
1）弹性扩缩容
2）资源利用率
3）对立技术栈
4）细粒度的资源分配
5）日志和监控
Spark submit 工作原理
Spark 对于 Kubernetes 的反对，最早的一种工作形式是通过 Spark 官网的 spark submit 形式去反对，Clinet 通过 Spark submit 提交作业，而后 spark driver 会调用 apiserver 的一些 api 去申请创立 executor，executor 都起来之后，就能够执行真正的计算工作，之后会做日志备份。
这种形式有一个劣势是，传统的 Spark 用户切换到这种形式之后用户体验扭转大。但也存在短少作业周期治理的缺点。
Spark-operator 工作原理
第二种 Spark on Kubernetes 的应用形式就是 operator。operator 是更 Kubernetes 的形式，你看他的整个作业提交，先是 yaml 文件通过 kubectl 提交作业，在这外面它有本人的 crd，即 SparkApplication，Object。创立了 SparkApplication 之后，Controller 能够 watch 到这些资源的创立，后边流程其实是复用的第一种工作模式，然而通过这种模式，做的更欠缺的一些。
绝对于第一种形式来讲，这里的 Controller 能够保护对象生命周期，能够 watch spark driver 的状态，并更新 application 的状态，是一个更欠缺的解决方案。
这两种不同的应用形式应用是各有劣势，不少的公司两种形式都有应用。这一块在官网也有介绍。
Spark with Volcano
Volcano 对于下面提到两种工作形式都进行了集成和反对。这个链接是咱们保护的 Spark 开源代码仓库：
https://github.com/huawei-clo…
在这外面 Volcano 做的事件其实也很简略，你看整个提交的过程，首先是通过 spark submit 提交作业，提交作业时会创立一个 podgroup，podgroup 蕴含了用户配置的一些调度相干的信息。它的 yaml 文件大家能够看到，页面左边这个局部，减少了 driver 和 executor 两个角色。
Volcano 队列
队列其实咱们在第一堂和第二堂课外面也讲到了。因为 Kubernetes 外面没有队列的反对，所以它在多个用户或多个部门在共享一个机器的时候资源没方法做共享。但不论在 HPC 还是大数据畛域里，通过队列进行资源共享都是根本的需要。
在通过队列做资源共享时，咱们提供了多种机制。图最下面的这种，这外面咱们创立两个队列，通过这两个队列去共享整个集群的资源，一个队列给他分 40% 的征询资源，另一个给他分 60% 的资源，这样的话就能够把这两个不同的队列映射到不同的部门或者是不同的我的项目各自应用一个队列。这在一队列里，资源不必的时候，能够给另外一个队列外面的作业去应用。上面讲的是两个不同的 namespace 之间的资源均衡。Kubernetes 里当两个不同的利用零碎的用户都去提交作业时，提交作业越多的用户，他取得的集群的资源会越多，所以在这外面基于 namespace，咱们进行偏心的调度，保障 namespace 之间能够依照权重分享集群的资源。
Volcano: Pod delay creation
之前介绍这个场景的时候，有些同学反映没有太听懂，所以我加了几页 PPT 扩大一下。
举个例子，咱们在做性能测试的时候，提交 16 个并发的作业，对于每个作业来讲，它的规格是 1 driver+4 executor，整个集群总共有 4 台机器 16 个核，这样的一个状况。
同时提交 16 个 spark job 的时候，driver pod 的创立和 executor pod 的创立之间有一个时间差。因为有这个时间差，当 16 个 spark 的 job 跑起来之后把整个机群全副占满了，就会导致同时提交并发量特地大作业的时候，整个集群卡死。
为了解决这种状况，咱们做了这样的事件。
让一个节点专门去跑 driver pod。其余三个节点专门去跑 executor pod，避免 driver pod 占用更多的资源，就能够解决被卡死的问题。
但也有不好的中央，这个例子里节点是 1:3 的关系。在实在的场景下，用户的作业的规格都是动静的，而这种调配是通过动态的形式去划分，没方法跟实在的业务场景里动静的比例保持一致，总是会存在一些资源碎片，会有资源的节约。
因而，咱们减少了 Pod delay creation 的性能，减少这个性能之后不须要对 node 去做动态的划分，整个还是 4 个节点，在 16 个作业提上来的时候，对于每个作业减少了 podgroup 的概念。Volcano 的调度器会依据提上来作业的 podgroup 进行资源布局。
这样就不会让过多的作业会提交上来。岂但能够把 4 个节点外面所有的资源全副用完，而且没有任何的节约，在高并发的场景下管制 pod 创立的节奏。它的应用也非常简单，能够依照你的需要配资源量，解决高并发的场景下运行卡死或者经营效率不高的状况。
Volcano: Spark external shuffle service
咱们晓得原来的 Spark 曾经很欠缺了，有很多特地好用的性能，Volcano 保障了迁徙到 Kubernetes 上之后没有大的性能缺失：
1)ESS 以 daemonset 的形式部署在每个节点
2)Shuffle 本地写 Shuffle 数据，本地、远端读 shuffle 数据
3) 反对动静资源分配
点击关注，第一工夫理解华为云陈腐技术~
