Spark 3.1.1 on Kubernetes 1.19 如何配置自动清理已完成的Driver Pod

当前使用的Spark 3.1.1版本原生支持Driver Pod自动回收能力，存在明确的可配置参数，无需引入额外第三方组件即可实现回收目标。

核心配置逻辑 #

Spark默认不会主动删除作业终态的Driver Pod，核心原因是对应删除开关默认处于关闭状态：

• 核心配置项为 spark.kubernetes.driver.deleteOnTermination，默认值为false，这也是当前集群中Completed状态Driver Pod长期留存的根本原因——该默认配置的设计目的是保留Driver运行时资源，方便后续排查日志、定位运行异常。
• 当将该参数值设置为 true 时，无论作业是正常成功结束还是异常失败退出，Driver Pod进入终态后，Spark都会主动触发删除操作，和Executor Pod的自动回收逻辑保持一致。
• 该参数从Spark 3.1.0版本正式纳入稳定特性，完全适配Kubernetes 1.19的API版本兼容性要求，无版本适配障碍。

配置落地路径 #

可根据实际作业提交场景选择任意一种配置渠道：

• 单作业临时生效：在spark-submit命令中追加配置参数，即 --conf spark.kubernetes.driver.deleteOnTermination=true
• 集群全局生效：在集群共享的spark-defaults.conf配置文件中，新增配置行 spark.kubernetes.driver.deleteOnTermination=true，所有提交到该集群的Spark作业都会默认启用Driver自动回收能力
• 应用代码内生效：在初始化Spark应用的SparkConf阶段，通过conf.set("spark.kubernetes.driver.deleteOnTermination", "true")完成配置注入

非原生备选实现方案 #

如果受限于现有作业配置的历史兼容性，无法直接启用上述原生参数，也可以借助Kubernetes原生的已完成Pod回收能力实现间接回收：

• 针对Driver Pod所在的命名空间，配置Pod生命周期的TTL策略，为所有处于Completed/Failed状态的Driver Pod设置固定的留存时长，超时后由Kubernetes内置的GC组件自动完成资源清理。
• 该方案的局限性是无法实现作业终态后的即时回收，必须等待固定TTL周期，且需要配套的命名空间RBAC权限支持，整体回收效果弱于Spark原生的参数配置。

配置生效后，作业进入终态阶段的Driver Pod会被即时触发清理，集群中不会长期留存历史Completed状态的Driver Pod资源。

内容的提问来源于stack exchange，提问作者Shivaji Mutkule