Cloud Composer环境中Airflow 2运行大任务触发SIGKILL终止问题咨询

1. 单任务资源配额调整（无需全局集群扩容） #

Cloud Composer 基于GKE运行，默认给每个worker pod设置的资源上限远低于节点总可用资源，你观测到的集群总内存足够不代表单个任务的pod配额足够，绝大多数非超时导致的SIGKILL都是pod内存超limit被kubelet强制终止。
可以给两个大资源任务单独配置executor参数覆盖默认资源限制，示例如下：

from datetime import timedelta
from airflow.operators.python import PythonOperator

samba_backfill_task = PythonOperator(
    task_id="samba_to_gcs_backfill",
    python_callable=your_samba_sync_func,
    execution_timeout=timedelta(hours=12), # 按实际最长耗时调整
    executor_config={
        "pod_override": {
            "resources": {
                "requests": {"memory": "4Gi", "cpu": "2"},
                "limits": {"memory": "8Gi", "cpu": "4"}
            }
        }
    }
)

你可以根据两个任务本地运行时的峰值内存调整limit数值，不需要修改集群整体节点配置。

2. Celery Worker 存活与超时配置调整 #

Cloud Composer默认的worker回收机制会强制终止运行时间过长的任务，你需要在Composer环境的Airflow配置覆盖页修改以下参数：

• core.worker_pod_refresh_interval：调整为86400（单位秒，即24小时，覆盖最长任务运行时长），避免worker pod运行过程中被自动回收
• celery.task_adoption_timeout：调整为3600（单位秒），避免worker异常重启后任务被判定为僵尸任务直接杀死
• 确认两个任务的execution_timeout参数设置值大于任务实际需要的最长运行时间，不能只调整DAG级超时，任务级超时优先级更高

3. IO密集型任务专项优化 #

你提到的两个任务均为网络IO密集型，卡顿或连接中断大概率不是Airflow本身问题，是中间链路限制：

• Samba同步任务：修改为流式读写逻辑，读取分片数据后直接写入GCS，不要全量加载到本地内存再上传，既降低内存峰值，也避免长时间空闲连接被本地机房防火墙、VPC防火墙强制断开
• Salesforce对接任务：开启SDK的自动重试与分页拉取配置，单次请求拉取数据量不超过2000条，同时配置请求的keep-alive头，避免短时间大量建联触发Salesforce侧限流或连接重置

4. 节点调度策略调整 #

默认Composer的工作节点可能触发GKE节点维护、资源抢占导致任务被终止，你可以给这两个任务的executor_config中添加节点亲和性配置，调度到资源使用率更低的专用worker节点，避免与系统组件、其他小任务抢占资源。

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