Airflow任务无限卡在队列状态问题排查（Openshift+LDAP环境）

核心现象 #

• 多次启动DAG后任务无限卡在队列状态
• Web-server Pod重复打印日志：INFO: updated user Airflow Admin、INFO: Login failed for user: airflow
• 添加airflow用户至LDAP后，问题仍未解决

可能的原因及排查方向 #

1. LDAP权限映射配置错误 #

• 即使LDAP中存在airflow用户，若Airflow的LDAP配置未将该用户（或其所属组）映射至Admin角色，用户将无触发任务、操作DAG的权限，导致任务无法从队列被调度。需检查webserver_config.py中的以下配置：
  • AUTH_LDAP_GROUP_MAP：确认用户所属LDAP组是否被映射到Admin角色
  • AUTH_LDAP_USER_FLAGS_BY_GROUP：验证是否正确配置了管理员组的映射规则
  • AUTH_LDAP_USERNAME_ATTR：确认是否使用了正确的用户标识字段（如uid或cn），避免因字段不匹配导致用户识别失败
• 执行命令airflow users get -u airflow，直接查看该用户在Airflow中的角色权限，确认是否为Admin

2. Worker节点的LDAP同步或连接问题 #

• Openshift上的Airflow Worker Pod可能未正确加载LDAP配置，或无权限访问LDAP服务器：
  • 检查Worker Pod日志，排查是否存在LDAP连接超时、认证失败等错误
  • 确认Worker的配置文件（如webserver_config.py）或环境变量与Web-server完全一致，避免Worker无法同步LDAP用户权限信息
• 若Worker无法完成LDAP权限校验，会拒绝执行队列中的任务，导致任务持续卡住

3. 元数据库脏数据残留 #

• 多次启动DAG时，可能已在Airflow元数据库中生成无权限的任务记录，即使后续添加了LDAP用户，旧任务的权限标识未自动更新：
  • 执行命令airflow tasks clear <dag_id>清空目标DAG的任务队列，再重新触发DAG测试
  • 直接检查元数据库的user表和dag_permission表，确认airflow用户存在且拥有对应DAG的执行权限

4. Openshift网络/权限限制 #

• 若LDAP服务器在Openshift集群外部，需确认Worker Pod的网络策略是否允许访问LDAP端口（通常为389或636）：
  • 检查Openshift的NetworkPolicy配置，确保Worker所在命名空间有访问LDAP服务器的出站权限
  • 验证Worker使用的ServiceAccount是否具备访问外部LDAP服务的权限

5. Executor配置不兼容 #

• 若使用CeleryExecutor：
  • 检查Redis/RabbitMQ的连接状态，确认无消息堆积
  • 确保Celery Worker的LDAP配置与Web-server一致，否则无法处理Web-server发送的任务请求
• 若使用KubernetesExecutor：
  • 检查任务Pod模板是否正确挂载了LDAP配置文件，或是否传递了正确的LDAP环境变量，避免任务Pod无法完成权限校验

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