一、k8s的优点
k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。
1、故障迁移
2、资源调度
3、资源隔离
4、负载均衡
5、跨平台部署
二、Spark on K8s工作原理
具体流程，包括以下几步：
①：用户使用kubectl 创建 SparkApplication 对象，提交sparkApplication的请求到api-server，并把sparkApplication的CRD持久化到etcd；
②：SparkApplication controller 从 kube-api server 接收到有对象请求，创建 submission （实际上就是 参数化以后的 spark-submit 命令），然后发送给 submission runner。
③：Submission runner 提交 app 到 k8s 集群，并创建 driver pod。一旦 driver pod 正常运行，则由 driver pod 创建 executor pod。 当应用正常运行时，spark pod monitor 监听 application 的 pod 状态，（通过kubectl可以通过list、status看到）并将pod 状态的更新发送给 controller，由 controller 负责调用 kube-api 更新 spark application 的状态（实际上是更新 SparkApplication CRD 的状态字段）。
④：mutating adminission webhook创建svc，可以查看spark web ui
三、Spark on K8s 的优势
优势1：
它的部署环境非常简单，我们现在使用的是云上托管的 K8s 服务，我们不需要去维护它的控制节点，当然每个云服务的 EMR 都有自己的产品，如 AWS 的 EKS，华为云的 CCE，谷歌的 GKE。这种类似的产品，我们不需要维护它的控制节点，也不需要在上面常驻任何 Spark 的服务就可以运行 Spark 作业。另外它也没有环境依赖，因为运行时所有的大数据作业都是容器化的，不需要节点上有一些提前预置好的环境，也就决定了运行的时候多版本可以共存。
优势2：
是其弹性优势。无论我们使用涉及开源的 K8s 的 cluster-auto scaler 插件，还是某些云商自己实现的基于 K8s 的更高效的扩缩容机制，都可以保证集群能够极快地自动扩缩容。这个时候，因为可以快速的把不用的节点关闭，也就相应地节约了计算的成本。
优势3：
它没有按节点来收取服务费用，只需要收取一个控制面的服务费用，这个服务费用是非常低的，在公司级的资源使用下，这部分的费用几乎是可以忽略不计的。
优势4：
它有更高的资源使用率。它是使用 go 语言编写的 kubelet 服务，它所需要预留的资源会远远低于 JVM 上所需要的，其节点利用率可以达到 90% 甚至更高。
四、spark app 开发
对于spark app 开发，实际上核心还是对于以来管理的处理解决方法比较多
all in one spark
直接打包到spark 应用中，可能需要频繁修改spark
app 使用fat jar
在打包的时候包含以来到jar 中，比较方便，但是可能会造成jar 太大
通过pacakges 坐标模式（运行时自动下载依赖）
in spark fat jar 混合模式
将部分常用，同时比较重要的放到spark 中，fat jar 只存储应用自己需要的领域特定的
五、SparkSQL迁移到K8s的收益
1、可以将计算和存储进行解耦，即存算分离。在存储和计算耦合的架构中，由于各业务场景对存储和计算的需求不平衡，绑定两者同步进行伸缩，会出现其中一种资源浪费的情况；将计算和存储解耦后则可以根据需要分别进行弹性伸缩，系统在负载均衡调度方面可以更加灵活。
2、统一算力资源池实现统筹调度，SparkSQL可以作为离线业务与其它在线业务进行混混部达到峰谷互补的效果，有助于提升服务器资源利用率和管理运维效率，节约总成本。
六、Spark on k8s的挑战
挑战1：
我个人认为最重要的，就是Shuffle的流程，按照目前的Shuffle方式，我们是没办法打开动态资源特性的。而且还需要挂载云盘，云盘面临着Shuffle数据量的问题，挂的比较大会很浪费，挂的比较小又支持不了Shuffle Heavy的任务。
挑战2：
调度和队列管理问题，调度性能的衡量指标是，要确保当大量作业同时启动时，不应该有性能瓶颈。作业队列这一概念对于大数据领域的同学应该非常熟悉，他提供了一种管理资源的视图，有助于我们在队列之间控制资源和共享资源。
跳转3：
读写数据湖相比较HDFS，在大量的Rename，List等场景下性能会有所下降，同时OSS带宽也是一个不可避免的问题。
七、Spark on k8s的解决方案
1、如果用是Docker的文件系统，问题是显而易见的，因为性能慢不说，容量也是极其有限，对于Shuffle过程是十分不友好的。
2、如果用Hostpath，熟悉Spark的同学应该知道，是不能够启动动态资源特性的，这个对于Spark资源是一个很大的浪费，而且如果考虑到后续迁移到Serverless K8s，那么从架构上本身就是不支持Hostpath的。
4、如果是Executor挂云盘的PV，同样道理，也是不支持动态资源的，而且需要提前知道每个Executor的Shuffle数据量，挂的大比较浪费空间，挂的小Shuffle数据又不一定能够容纳下。
