K8s集群多命名空间部署Airflow实例遇Pod崩溃重启问题求助

常见触发原因及修复方案 #

• 端口/网络资源冲突
  官方Helm Chart默认可能开启hostNetwork，多个实例共享节点网络时会抢占Airflow默认端口（如8080、调度器内部通信端口），直接导致Pod启动失败或崩溃。

  • 修复：在每个实例的Helm values中设置hostNetwork: false，或者为不同实例配置独立的service端口，避免端口重叠。

• 元数据库未隔离
  多个实例错误共用同一个元数据库（或同schema）时，调度器和Worker会在数据库层面产生锁竞争、表结构冲突，引发频繁崩溃。

  • 修复：为DEV/TEST/PROD分别配置独立的数据库实例，或为每个实例分配专属的数据库schema，修改Helm values中的data.metadataConnection参数指定对应连接信息。

• 集群资源配额不足
  多实例并行运行时，若命名空间未配置资源配额或单个实例资源请求/限制过高，会导致Pod因OOM被杀死或无法调度。

  • 修复：为每个命名空间配置ResourceQuota，分配合理的CPU、内存额度；同时调整Airflow组件（调度器、Worker）的resources.requests和resources.limits参数，避免资源过度占用。

• RBAC/权限配置未隔离
  若使用默认的集群级RBAC配置，多个实例的ServiceAccount可能拥有跨命名空间的权限，导致组件互相干扰。

  • 修复：为每个命名空间的Airflow实例创建独立的ServiceAccount，确保rbac.create: true且权限仅限定在当前命名空间内，避免跨实例权限冲突。

快速排查步骤 #

1. 查看崩溃Pod的日志：

   kubectl logs <崩溃Pod名称> -n <目标命名空间>
   

   重点关注日志中的端口占用、数据库连接错误、资源耗尽（OOM）等关键信息。
2. 检查集群资源使用：

   kubectl top nodes
   kubectl top pods -n <目标命名空间>
   

   确认是否存在节点或Pod层面的资源耗尽情况。
3. 验证数据库隔离性：登录各实例的元数据库，检查是否存在跨实例的表操作冲突或锁等待。
4. 对比配置差异：导出不同实例的Helm配置，检查是否有未做隔离的共享资源配置：

   helm get values <Airflow发布名称> -n <目标命名空间>
   

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