Cloud Composer2.1.8-Airflow2.2.5升级后Worker Pod频繁重启问题

一、Worker OOM但监控未超限的深层排查 #

• 检查节点级内存压力：Cloud Composer Worker运行在GKE节点上，SystemOOM通常是节点整体内存耗尽导致kubelet杀死Pod，而非单个Worker Pod资源超限。查看GKE节点的监控指标（节点内存使用率、剩余可用内存），重点关注每日8-9点节点的内存水位，确认是否有其他Pod（如系统组件、其他工作负载）占用过多内存触发节点OOM。
• 验证Worker Pod的内存请求/限制配置：确认升级后Worker的内存限制是否正确应用，执行kubectl describe pod <worker-pod-name>查看Resources字段，检查limits.memory是否设置为4GB，同时确认requests.memory配置合理，避免节点调度时分配的内存预留不足。
• 排查Airflow Worker内存泄漏：部分场景下内存泄漏会导致Pod内存缓慢增长，在任务密集时段触发节点OOM，即便单Pod监控未显示超限。启用Airflow Worker的内存 profiling，添加--memory-profile参数到Worker启动命令，或使用py-spy工具采样Worker进程内存使用，定位是否有任务代码或Airflow内置组件存在内存泄漏。

二、Worker重启后队列任务无法自动拾取的修复 #

• 检查任务状态一致性：Worker重启后，部分任务可能处于queued或running的中间状态，Airflow元数据库中任务状态与实际Worker状态不一致。执行airflow db check验证元数据库完整性，手动清理残留的异常任务状态：

  # 清理处于running状态但无Worker关联的任务实例
  airflow tasks clear --only-running <dag-id>
  

• 调整Airflow调度器配置：升级后调度器的任务拾取逻辑可能存在适配问题，修改airflow.cfg中的以下参数：
  • 增大max_tis_per_query：允许调度器一次性查询更多任务实例，避免遗漏队列任务
  • 启用schedule_after_task_execution：确保任务完成后调度器及时更新队列状态
  • 调整worker_autoscale：根据Worker资源配置合理设置自动扩缩容阈值，避免任务堆积
• 验证Celery Broker状态：Cloud Composer使用Redis作为Celery Broker，检查Redis的连接数、内存使用率，执行redis-cli info stats查看connected_clients和used_memory指标，确认Broker未出现阻塞或内存不足导致任务消息丢失。

三、Cloud Composer版本升级后的兼容性检查 #

• 核对组件版本匹配：确认Composer 2.1.8与Airflow 2.2.5的组件兼容性，检查GCS同步、Kubernetes Executor等插件是否存在版本冲突。执行gcloud composer environments describe <env-name> --location <region>查看环境组件版本，对比官方兼容性矩阵（本地核对即可，无需外链）。
• 检查升级后的配置变更：Composer升级可能自动覆盖部分自定义配置，查看airflow.cfg中的celery、core章节，确认之前的自定义配置（如worker_concurrency、task_concurrency）是否保留，尤其是worker_concurrency设置是否超过Worker资源承载能力（建议2CPU对应worker_concurrency=8-10）。

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