摘要：本篇文章将会从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)反对动静资源分配
点击关注，第一工夫理解华为云陈腐技术~