使用SparkSubmitOperator的Airflow任务完成后仍显示运行求助

问题基本特征 #

• 运行环境：Airflow v2.0.1，配套Spark v3.0.0，通过SparkSubmitOperator 以K8s集群模式（连接地址格式为k8s://）提交任务，依赖K8s动态调度管理Spark驱动、执行器Pod的全生命周期
• 故障表现：从Airflow UI触发DAG时会随机出现任务卡滞，Spark驱动Pod内的业务任务已执行完成，但Airflow UI始终将任务标记为运行中，任务日志反复输出相同内容
• 验证结论：单任务独立测试均可正常执行完成，在业务代码中添加spark.stop()、sys.exit(0) 的规范退出逻辑后，卡滞问题无改善
• 参考留存材料：DAG结构示意图、Airflow任务运行日志截图

核心排查方向与修复方案 #

1. Spark Provider版本兼容缺陷修复 #

Airflow v2.0.1 捆绑的内置SparkSubmitOperator 存在K8s集群模式下的轮询逻辑bug：当Spark驱动Pod正常结束后，operator的日志拉取线程未设置超时退出阈值，会无限循环重复拉取已读取完成的日志流，不会主动触发任务状态更新，直接导致UI侧任务永久卡滞。

• 修复操作：
  • 卸载Airflow内置的旧版Spark provider，替换为兼容Airflow 2.0.x的稳定版独立provider包
  • 给SparkSubmitOperator 显式配置参数，关闭无限流式日志拉取：

    SparkSubmitOperator(
        # 基础配置
        task_id="xxx",
        application=xxx,
        conn_id="spark_default",
        # 硬超时兜底配置
        execution_timeout=timedelta(minutes=30),
        # Spark侧K8s配置
        kwargs={
            "conf": {
                "spark.kubernetes.driver.deleteOnTermination": "true",
                "spark.kubernetes.executor.deleteOnTermination": "true"
            },
            "verbose": "false"
        }
    )
    

2. K8s API状态传播延迟问题排查 #

K8s集群的API Server存在缓存机制，当Spark驱动Pod进入Succeeded终态后，spark-submit客户端需要通过K8s API轮询获取Pod状态，如果存在状态更新延迟，客户端会卡在日志拉取环节，无法返回成功退出码。

• 排查与调整：
  • 确认spark-submit客户端的K8s权限范围：确保具备Spark运行命名空间下Pod资源的get/list/watch 权限，避免因权限不足无法获取Pod终态
  • 调整Spark K8s客户端的状态查询配置：将驱动Pod状态查询的超时阈值设置为10s，缩短缓存导致的状态同步延迟

3. Airflow Worker侧进程残留问题排查 #

当Airflow Worker节点与Spark驱动Pod之间出现短时网络抖动时，spark-submit提交的子进程不会被正常回收，会卡在日志重拉逻辑上，表现为UI侧日志内容重复输出。

• 排查操作：
  • 卡滞任务出现时，登到对应Airflow Worker节点查看进程列表，确认是否存在无响应的残留spark-submit 子进程
  • 在Airflow Worker侧配置进程回收钩子，对超过执行超时阈值未退出的spark-submit进程做强制回收，避免无意义的日志重复拉取

内容的提问来源于stack exchange，提问作者Ayushi Agarwal