摘要：本篇文章将会从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-cloudnative/spark/tree/spark-2.4-volcano-0.1
在这里面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)支持动态资源分配
