Cloud Composer中Airflow Worker频繁Warm shutdown重启问题咨询

• 运行环境：Cloud Composer 1.17.6 托管Airflow集群，内置Airflow版本为2.0.2
• 集群配置：小规模部署，初始配置4个Worker Pod、1个Scheduler Pod，已开启集群自动扩缩容功能
• 故障现象：集群仅运行少量任务时，Airflow Worker仍频繁出现异常重启
• 故障定位线索：通过kubectl logs --previous查看Worker重启前的日志，仅观测到如下关键输出：

worker: Warm shutdown (MainProcess)

• 已尝试的修复操作：
  • 将Celery配置项acks_late设置为True
  • 将Celery配置项worker_max_tasks_per_child设置为500
  • 以上调整未解决故障，需要定位根因与可行解决方案

日志中打印的worker: Warm shutdown (MainProcess)是Celery Worker收到SIGTERM信号后触发优雅关停的标准输出，不属于进程崩溃类异常，可按以下优先级逐一排查：

1. 自动扩缩容策略配置不合理 #

这是小规模Composer集群该类问题的最高发原因：

• 若自动扩缩容配置的Worker最小副本数低于初始配置的4个，缩容控制器会持续根据队列指标尝试关停多余Worker，哪怕任务量极低，也会因为指标采样波动出现反复缩容、扩容的循环，触发Worker优雅关停
• 若缩容冷却时间设置过短（默认值通常为2-5分钟），短时间的队列长度波动就会触发缩容动作
• 排查方法：执行kubectl get events -n <你的composer集群命名空间>，查看是否有ScalingReplicaSet类事件与Worker重启时间点对齐
• 修复方案：
  • 将Worker最小副本数设置为与初始副本数一致（即4个），小规模集群无高弹性需求时可直接关闭Worker缩容能力
  • 将缩容冷却时间调整至10分钟以上，避免指标波动触发误缩容
  • 检查集群节点资源预留配置，确认是否存在节点资源不足导致kubelet主动驱逐Worker Pod的情况

2. Worker存活探针误判 #

Airflow 2.0.2版本内置的Celery Worker存活探针存在已知兼容问题：

• 默认探针超时时间、失败阈值设置过严，若Worker上运行的任务出现短时间IO阻塞、或者启动阶段预取任务负载过高，kubelet会误判Worker进程无响应，发送SIGTERM触发关停
• 排查方法：执行kubectl describe pod <重启的Worker Pod名>，查看Events字段是否有Liveness probe failed类记录与重启时间对齐
• 修复方案：
  • 调整Worker存活探针参数：将初始延迟initialDelaySeconds设为120秒以上，超时时间timeoutSeconds设为30秒，失败阈值failureThreshold设为5次
  • 将Celery配置项worker_prefetch_multiplier设为1，减少Worker启动阶段的预取负载，避免探针无响应

3. Celery配置项版本兼容冲突 #

当前调整的两个配置项在Airflow 2.0.2 + Composer 1.17.6版本存在已知兼容问题：

• worker_max_tasks_per_child=500会触发Celery子进程主动回收逻辑，和Composer内置的Worker进程守护逻辑冲突，导致父进程被误触发关停
• acks_late=True未配合Broker可见性超时配置时，若任务执行时长超过Broker默认的1小时可见性超时，Broker会重发任务并触发原Worker进程的关停逻辑
• 修复方案：
  • 将worker_max_tasks_per_child设置为0，关闭Celery自带的子进程回收能力，通过worker_concurrency参数（单Worker建议设为4-8）控制单Worker负载
  • 调整celery_broker_transport_options中的可见性超时参数，设置值为集群内最长任务执行时长的1.5倍，避免Broker误判任务丢失触发Worker异常

4. 资源配额触顶触发优雅关停 #

若Worker Pod的内存、CPU配额设置过低，哪怕任务量少，个别存在内存泄漏的任务也会让Worker资源占用触达Limit阈值：

• K8s在Pod资源触达Limit时会先发送SIGTERM触发优雅关停，该阶段日志只会打印Warm shutdown，不会输出OOM类报错，只有优雅关停超时后才会强制杀进程
• 排查方法：查看Composer监控面板中Worker Pod重启前的资源占用曲线，确认是否接近配置的配额上限
• 修复方案：
  • 单Worker内存配额建议不低于2G，CPU配额不低于1核
  • 排查自定义Operator、任务逻辑是否存在未释放资源的内存泄漏问题

内容的提问来源于stack exchange，提问作者Jay-r Bangit