GCP上Airflow 2.4.3的Flower Pod持续重启问题排查求助

先明确：当前日志里的警告并非重启直接原因 #

你提供的日志里全是**DeprecationWarning（弃用警告）**和pip更新提示，这些只是配置不符合新版本规范，不会直接导致Pod重启。得先找到触发Pod重启的核心原因。

第一步：定位Pod重启的直接触发点 #

在GCP环境里，先通过以下操作获取关键信息：

• 查看Pod事件日志：执行kubectl describe pod <flower-pod-name>，重点看Events区块，有没有OOMKilled（内存不足）、CrashLoopBackOff、健康检查失败这类事件。
• 查看崩溃前的完整日志：当前日志只到启动初期，执行kubectl logs <flower-pod-name> --previous，获取上一次Pod崩溃时的完整日志。
• 检查资源限制：确认Flower Pod的CPU/内存请求和限制是否合理，Airflow 2.4.x的Flower默认至少需要256Mi内存，限制过低很容易触发OOM。

第二步：解决配置警告（消除干扰项） #

你说已经调整了配置但警告还在，大概率是这些原因：

• 配置未生效：检查是否存在多配置源冲突（比如环境变量覆盖了配置文件，或者ConfigMap更新后没同步到Pod）。执行kubectl exec <flower-pod-name> -- cat $AIRFLOW_HOME/airflow.cfg，确认最终生效的配置内容。
• 旧配置项没删干净：哪怕把sql_alchemy_pool_size移到[database]段，只要[core]段还留着这个配置项，就会触发警告，得彻底删掉[core]段下的旧条目。
• AIRFLOW_HOME配置冲突：日志提示同时设置了AIRFLOW_HOME环境变量和配置文件里的airflow_home，删掉配置文件中的airflow_home条目，只保留环境变量设置。

第三步：针对常见Flower重启场景的修复方案 #

1. 内存不足（OOMKilled）

   • 调高Flower Pod的内存限制，比如在部署配置里设置resources.limits.memory: 512Mi，请求值设为resources.requests.memory: 256Mi。
   • 调整sql_alchemy_pool_size：当前设置的1000过大，会占用大量内存，建议改成20-50（Airflow默认是5），这很可能是内存过载的诱因。

2. 健康检查失败

   • 确认Flower的健康检查端点是否正常，Airflow 2.4.x的Flower默认健康检查端点是/health，检查部署中的livenessProbe和readinessProbe配置是否正确，超时时间是否足够。

3. Celery依赖组件连接失败

   • 如果你用的是CeleryExecutor，Flower依赖Redis或RabbitMQ获取Worker状态，要是连接失败会直接崩溃。检查Redis/RabbitMQ的地址、密码配置是否正确，Flower Pod能不能访问到这些服务。

补充建议 #

• 优先处理sql_alchemy_pool_size=1000的问题，这个配置会占用大量数据库连接和内存，是潜在的崩溃风险点。
• 把pip升级到指定版本，执行python -m pip install --upgrade pip==22.3.1，避免不必要的干扰。

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