K8s上Airflow1.10.15 JDBCOperator任务返回Negsignal.SIGKILL调度器显示成功

1. 优先排查Pod侧资源限制配置 #

• 该场景下Airflow UI报SIGKILL但Pod实际执行成功，绝大多数情况是Airflow Worker Pod的*日志采集侧车容器（sidecar）*触发OOM被K8s杀死导致：
  Airflow 1.10.15版本的KubernetesExecutor默认会给每个任务Pod启动独立的日志采集侧车，若未单独给侧车配置内存阈值，其默认内存配额极低，当Impala元数据刷新任务输出的日志量超过侧车内存上限时，K8s会直接杀掉侧车容器，此时Executor会误判整个任务失败返回SIGKILL，但实际执行Impala命令的主容器已经完成操作。
• 排查命令：执行kubectl describe pod <失败任务对应的Pod名>，查看Pod的State、Last State字段，确认是否存在sidecar容器被OOMKilled的记录。
• 修复方案：在Airflow的KubernetesExecutor配置中上调侧车容器的内存配额，参考配置如下：

executor_config = {
    "KubernetesExecutor": {
        "sidecar_resources": {
            "requests": {"memory": "256Mi", "cpu": "100m"},
            "limits": {"memory": "512Mi", "cpu": "500m"}
        }
    }
}

2. 检查JDBCOperator超时配置 #

• Airflow 1.10.15的JDBCOperator默认无全局执行超时限制，但若你配置的Impala JDBC连接串设置了较短的socket超时，或者任务单独设置的execution_timeout低于Impala元数据刷新的实际耗时，会导致任务进程被Airflow主动杀死，由于SQL命令已经提交到Impala服务端执行，就会出现服务端执行成功、Airflow侧提前终止的现象。
• 排查方向：核对任务的execution_timeout参数，以及JDBC连接参数中的socketTimeout、queryTimeout配置。

3. 确认Executor状态同步逻辑 #

• Airflow 1.10.15的KubernetesExecutor存在已知状态同步Bug：当任务Pod执行完成到状态上报的时间差小于Executor的轮询间隔时，Executor可能会漏抓Pod的Success状态，误返回状态为None，最终标记任务为SIGKILL终止。
• 修复方案：可升级Airflow到1.10.15的最新补丁版本，或在任务定义中增加retries=1的重试配置，规避偶发的状态同步遗漏问题。

内容的提问来源于stack exchange，提问作者Rajat Mishra