其实关于Spark on k8s笔者很早就接触了，而且也进行过实战,而且也改造分析过，
比如spark on k8s 与 spark on k8s operator的对比这里进行了比对
kubernetes(k8s) scheduler backend 调度的实现和KubernetesClientException: too old resource version 原因分析这里进行了基于k8s作为backend的调度系统的改造升级以及遇到的问题解决
对于SPARK 3.4.0支持多k8s调度的调度器，其实对于我个人来说是有一些感悟的：
-
就像spark一开始支持 mesos到yarn再到k8s一样，spark前期对于k8s的支持功能很不完善，笔者遇到的问题就是，所有的spark driver都提交上去了，但是却没没有获得pod去启动executor，导致任务运行很长
后面k8s原生调度器CNCF volcano的出现，支持了podgroup的概念，所以也可以从某种程度上解决这种死锁问题（最主要是支持以job为粒度的调度）
后面出现的Apache yunikorn出现，是为了让k8s的调度更加像Yarn的调度一样，让使用yarn的用户能够无缝的切换到k8s中去 -
一开始的时候，k8s的内部调度的吞吐是很慢的
毕竟k8s一开始的就是只是支撑online服务的，并不是用来做批调度的，当然这就存在问题了，在真实线上环境的时候，需要被调度的pod很可能是一下就来了几千个，这种情况下会发现，你的任务一直处于被调度的状态。
当然volcano现在的调度吞吐已经达到了每秒调度上千的能力 -
为什么很多厂家都选择了k8s，而放弃了yarn
- k8s 是为容器而生的，不像yarn是基于JVM的调度平台，k8s只要有对应的镜像就可以运行，可以运行各种语言程序
- k8s 一开始是为了online服务而生的，其高可用性，以及自动负载均衡，灰度发布等特性，再加上后来对于批调度的支持，这些组合在一起完全碾压了yarn
- 已经有了k8s，再维护一套yarn，增加了维护成本
从Spark 3.4.0开始， Spark支持选择不同的k8s调度器，只要设置spark.kubernetes.scheduler.name 为volcano或者yunikorn ，具体的设计文档见:Support Customized Kubernetes Schedulers Proposal
注意：无论选择volcano还是yunikorn，都是k8s内部支持的事情，跟spark这边关系不太大,代码层面不会有改动