Spark on Kubernetes中Pod异常崩溃问题排查求助

看起来你遇到的是Spark on Kubernetes环境下作业随机崩溃的典型问题——从你给出的堆栈日志来看，广播清理失败、Shuffle拉取失败这些都是Executor/Driver Pod被Kubernetes意外终止后的连锁反应，核心根因不在Spark本身，而是K8s层面的Pod终止或者资源配置不匹配。下面是一步步的排查和解决方向：

一、先揪出Kubernetes杀死Pod的真正原因 #

这是最关键的第一步，Spark的错误堆栈都是结果，不是根源：

• 用kubectl describe pod <你的driver/executor pod名>查看Pod的事件日志，重点看Events区块：有没有OOMKilled（哪怕你监控显示内存没到上限，也要确认K8s给Pod设置的memory limit是不是等于spark.executor.memory + spark.executor.memoryOverhead——如果K8s的limit比这个总和小，哪怕Spark内部没超，K8s也会直接杀Pod）、NodeLost、Evicted（节点资源不足被驱逐）这类事件。
• 检查Pod所在的Node节点状态：用kubectl describe node <节点名>，看看节点是不是磁盘满了、内存碎片化严重，或者被标记为NotReady——节点出问题会直接导致上面的Pod被杀死。

二、针对Spark与K8s集成的配置优化 #

1. 调整Executor的健康检查策略 #

默认的Spark on K8s健康检查阈值太严格，很容易因为临时的GC停顿、Shuffle繁忙误判为Pod不健康，建议添加以下配置：

spark.kubernetes.executor.livenessProbe.enabled true
spark.kubernetes.executor.livenessProbe.initialDelaySeconds 300  # 延迟5分钟再开始健康检查，给作业启动留足时间
spark.kubernetes.executor.livenessProbe.timeoutSeconds 10
spark.kubernetes.executor.readinessProbe.enabled true
spark.kubernetes.executor.readinessProbe.initialDelaySeconds 60

2. 优化Shuffle容错机制 #

从堆栈2和3的Shuffle失败来看，Executor被杀死后Shuffle元数据直接丢失，导致后续任务失败。启用External Shuffle Service可以让Shuffle数据脱离Executor生命周期，同时开启动态分配自动补充被杀死的Executor：

spark.shuffle.service.enabled true
spark.dynamicAllocation.enabled true
spark.dynamicAllocation.executorIdleTimeout 300s
spark.dynamicAllocation.minExecutors 50  # 保持你需要的Executor数量下限

3. 完善Kryo序列化配置 #

你已经启用了Kryo，但可以进一步优化：

spark.kryo.registrationRequired true  # 强制注册序列化类，避免未知对象序列化的内存开销
spark.kryoserializer.buffer.max 128mb  # 调大缓冲区上限，防止大对象序列化失败

如果你的作业有自定义类，记得在Kryo里注册它们，避免序列化时的性能问题或内存溢出。

三、关于日志疑问的解答 #

你提到的18/05/11 07:23:23 INFO DAGScheduler: failed: Set()日志，确实表示当前没有失败的任务或阶段。这是DAGScheduler定期打印的状态快照，Set为空说明打印这个日志的时刻，作业没有失败的任务——和你遇到的Pod突发被杀死的问题不冲突，可能是故障发生前或者间隙期的状态。

四、其他排查方向 #

• 检查HDFS稳定性：你的EventLog和作业数据都存在HDFS，如果Namenode或者DataNode有波动，可能导致Spark作业出现异常，进而被K8s判定为不健康。可以查看HDFS的NameNode日志，确认是否有异常。
• 升级Spark版本：如果用的是Spark 2.x版本，Spark on K8s存在不少已知的稳定性bug，建议升级到Spark 3.1及以上版本，官方修复了很多K8s集成的问题。
• 查看K8s集群组件日志：比如kubelet、kube-proxy的日志，看看是否有节点级别的网络问题、资源调度异常，这些都可能导致Pod被驱逐或杀死。

内容的提问来源于stack exchange，提问作者kaushik H S