kube-airflow 故障排查指南5 个常见问题与解决方案【免费下载链接】kube-airflowA docker image and kubernetes config files to run Airflow on Kubernetes项目地址: https://gitcode.com/gh_mirrors/ku/kube-airflow在 Kubernetes 上部署 Airflow 时kube-airflow 是许多团队的首选方案——它提供了一套完整的 Docker 镜像和 Kubernetes 配置文件帮你快速搭建包含 webserver、scheduler、Celery worker 和 Flower 的完整 Airflow 集群。然而Airflow 在 Kubernetes 上的故障排查往往比传统部署更复杂组件之间依赖 PostgreSQL、RabbitMQ或 Redis等多个基础服务任何一个环节出问题都会让整个调度链停摆。本文总结了 kube-airflow 部署中最常见的 5 个问题并给出可直接照做的解决方案帮你快速定位并恢复集群。问题一Pod 反复重启容器一直处于 CrashLoopBackOff症状kubectl get pods查看时webserver、scheduler、worker 等多个 Pod 状态为CrashLoopBackOff或Error日志里反复出现 still not reachable, giving up。原因kube-airflow 的启动脚本script/entrypoint.sh会在容器启动时等待 RabbitMQ 和 PostgreSQL 就绪默认重试 10 次TRY_LOOP每次间隔 5 秒。如果依赖服务在 50 秒内仍未就绪容器就会直接退出进而触发 Kubernetes 的重启策略形成循环崩溃。解决方案先用kubectl get pods -n 命名空间确认 postgres、rabbitmq或 redisPod 是否处于Running状态。如果基础服务还没就绪可以在启动时调大重试次数TRY_LOOP30让容器有更多等待时间。检查 DNS 解析确保POSTGRES_HOST和RABBITMQ_HOST指向的服务名与airflow/templates/services.yaml中定义的一致。如果数据库一直起不来重点排查数据卷airflow/values.yaml中persistence.enabled开启时需要确认 PersistentVolume 是否被正确挂载。问题二任务一直处于 queued 状态迟迟不执行症状Web UI 中 DAG 已触发但任务长时间停留在queued没有任何 worker 接手。原因kube-airflow 默认使用 CeleryExecutor见config/airflow.cfg中的executor CeleryExecutor任务要经过 brokerRabbitMQ分发到 worker。最常见的原因是 broker 连接失败或 worker 数量配置为 0。解决方案确认 worker Pod 已启动kube-airflow 用 StatefulSet 管理 worker见airflow/templates/statefulsets-workers.yaml检查celery.num_workers是否大于 0。查看 RabbitMQ 管理界面端口 15672确认队列中有没有积压的未消费消息。检查config/airflow.cfg中的broker_url和celery_result_backend确保账号密码与POSTGRES_CREDS、RABBITMQ_CREDS环境变量一致。用kubectl logs worker-pod查看 worker 日志排查是否有 Cant connect to amqp 之类的报错。问题三DAG 不更新或运行时突然变成新版本症状代码合并到 Git 仓库后Airflow 里迟迟看不到新 DAG或者更糟——DAG 正在运行时执行逻辑突然变成了新代码导致结果不一致。原因kube-airflow 支持通过 git-sync 自动同步 DAGairflow/values.yaml中dags.git_sync_enabled开启后entrypoint 会拉取指定 Git 仓库。但 Airflow 官方已知的问题是如果 scheduler 在 dagrun 执行中途重载了 DAG本次运行会直接使用新版本代码这是非常危险的。解决方案如果业务要求高一致性建议改用 embedded DAGs 方式把 DAG 直接打进 Docker 镜像参考Dockerfile.template中的构建流程用make build重新构建镜像。若坚持使用 git-sync务必遵守两条铁律DAG 不可变不要修改已有 DAG永远新建运行中禁止拉取引入显式锁dagrun 进行中不更新。检查 git-sync 的拉取间隔dags.poll_interval_sec默认 60 秒确认分支名dags.git_branch配置正确。问题四Web UI 无法查看 Worker 日志症状在 Airflow Web UI 中点击任务日志时报错提示无法连接到 worker或日志一直加载不出来。原因kube-airflow 的 worker 使用 StatefulSet 而非 Deployment目的是借助 Headless Serviceairflow/templates/services.yaml中的name-workerclusterIP: None获得稳定的 Pod DNS让 webserver 能按需访问每个 worker 的日志端口 8793。如果 Headless Service 或 Pod DNS 不通日志自然无法读取。解决方案确认 worker 暴露了 8793 端口见airflow/templates/statefulsets-workers.yaml中的containerPort: 8793。从 webserver Pod 内测试连通性kubectl exec web-pod -- curl worker-pod-dns:8793worker 的 Pod DNS 形如release-worker-0.release-worker。检查是否有网络策略NetworkPolicy阻断了 webserver 到 worker 的访问。问题五配置解析失败密码或前缀带特殊字符导致崩溃症状容器启动后 airflow.cfg 内容异常或服务报配置错误重启多次依旧如此。原因kube-airflow 的config/airflow.cfg采用模板占位符机制如{{ POSTGRES_CREDS }}、{{ FERNET_KEY }}由script/entrypoint.sh在启动时用sed替换。README 中明确警告密码和 prefix 中不要使用、、/、\等特殊字符否则 sed 替换会出错导致配置文件损坏。解决方案检查airflow/values.yaml中配置的密码、url_prefix、flower.url_prefix是否包含特殊字符一律改为纯字母数字组合。自定义 airflow.cfg 时可通过 ConfigMap 方式注入参考airflow/myvalue-with-airflowcfg-configmap.yaml的示例注意保留模板占位符保证与集群中的环境变量对齐。如果密码已污染数据库连接串修改后记得重启 postgres、scheduler 和 worker 所有相关组件。总结与预防建议kube-airflow 的故障排查思路可以归纳为一条链路基础服务 → 配置解析 → 任务调度 → 日志回传。绝大多数问题都出在依赖服务未就绪、特殊字符污染配置、以及 DAG 同步策略选择不当这三个环节。最后给出三条预防建议一是部署前完整阅读项目根目录的 README 和airflow/Chart.yaml了解组件清单二是生产环境优先使用 embedded DAGs 而不是 git-sync三是为所有密码配置统一的命名规范坚决不出现特殊字符。做到这三点你的 Airflow 集群在 Kubernetes 上就能稳定运行很久。【免费下载链接】kube-airflowA docker image and kubernetes config files to run Airflow on Kubernetes项目地址: https://gitcode.com/gh_mirrors/ku/kube-airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
kube-airflow 故障排查指南5 个常见问题与解决方案【免费下载链接】kube-airflowA docker image and kubernetes config files to run Airflow on Kubernetes项目地址: https://gitcode.com/gh_mirrors/ku/kube-airflow在 Kubernetes 上部署 Airflow 时kube-airflow 是许多团队的首选方案——它提供了一套完整的 Docker 镜像和 Kubernetes 配置文件帮你快速搭建包含 webserver、scheduler、Celery worker 和 Flower 的完整 Airflow 集群。然而Airflow 在 Kubernetes 上的故障排查往往比传统部署更复杂组件之间依赖 PostgreSQL、RabbitMQ或 Redis等多个基础服务任何一个环节出问题都会让整个调度链停摆。本文总结了 kube-airflow 部署中最常见的 5 个问题并给出可直接照做的解决方案帮你快速定位并恢复集群。问题一Pod 反复重启容器一直处于 CrashLoopBackOff症状kubectl get pods查看时webserver、scheduler、worker 等多个 Pod 状态为CrashLoopBackOff或Error日志里反复出现 still not reachable, giving up。原因kube-airflow 的启动脚本script/entrypoint.sh会在容器启动时等待 RabbitMQ 和 PostgreSQL 就绪默认重试 10 次TRY_LOOP每次间隔 5 秒。如果依赖服务在 50 秒内仍未就绪容器就会直接退出进而触发 Kubernetes 的重启策略形成循环崩溃。解决方案先用kubectl get pods -n 命名空间确认 postgres、rabbitmq或 redisPod 是否处于Running状态。如果基础服务还没就绪可以在启动时调大重试次数TRY_LOOP30让容器有更多等待时间。检查 DNS 解析确保POSTGRES_HOST和RABBITMQ_HOST指向的服务名与airflow/templates/services.yaml中定义的一致。如果数据库一直起不来重点排查数据卷airflow/values.yaml中persistence.enabled开启时需要确认 PersistentVolume 是否被正确挂载。问题二任务一直处于 queued 状态迟迟不执行症状Web UI 中 DAG 已触发但任务长时间停留在queued没有任何 worker 接手。原因kube-airflow 默认使用 CeleryExecutor见config/airflow.cfg中的executor CeleryExecutor任务要经过 brokerRabbitMQ分发到 worker。最常见的原因是 broker 连接失败或 worker 数量配置为 0。解决方案确认 worker Pod 已启动kube-airflow 用 StatefulSet 管理 worker见airflow/templates/statefulsets-workers.yaml检查celery.num_workers是否大于 0。查看 RabbitMQ 管理界面端口 15672确认队列中有没有积压的未消费消息。检查config/airflow.cfg中的broker_url和celery_result_backend确保账号密码与POSTGRES_CREDS、RABBITMQ_CREDS环境变量一致。用kubectl logs worker-pod查看 worker 日志排查是否有 Cant connect to amqp 之类的报错。问题三DAG 不更新或运行时突然变成新版本症状代码合并到 Git 仓库后Airflow 里迟迟看不到新 DAG或者更糟——DAG 正在运行时执行逻辑突然变成了新代码导致结果不一致。原因kube-airflow 支持通过 git-sync 自动同步 DAGairflow/values.yaml中dags.git_sync_enabled开启后entrypoint 会拉取指定 Git 仓库。但 Airflow 官方已知的问题是如果 scheduler 在 dagrun 执行中途重载了 DAG本次运行会直接使用新版本代码这是非常危险的。解决方案如果业务要求高一致性建议改用 embedded DAGs 方式把 DAG 直接打进 Docker 镜像参考Dockerfile.template中的构建流程用make build重新构建镜像。若坚持使用 git-sync务必遵守两条铁律DAG 不可变不要修改已有 DAG永远新建运行中禁止拉取引入显式锁dagrun 进行中不更新。检查 git-sync 的拉取间隔dags.poll_interval_sec默认 60 秒确认分支名dags.git_branch配置正确。问题四Web UI 无法查看 Worker 日志症状在 Airflow Web UI 中点击任务日志时报错提示无法连接到 worker或日志一直加载不出来。原因kube-airflow 的 worker 使用 StatefulSet 而非 Deployment目的是借助 Headless Serviceairflow/templates/services.yaml中的name-workerclusterIP: None获得稳定的 Pod DNS让 webserver 能按需访问每个 worker 的日志端口 8793。如果 Headless Service 或 Pod DNS 不通日志自然无法读取。解决方案确认 worker 暴露了 8793 端口见airflow/templates/statefulsets-workers.yaml中的containerPort: 8793。从 webserver Pod 内测试连通性kubectl exec web-pod -- curl worker-pod-dns:8793worker 的 Pod DNS 形如release-worker-0.release-worker。检查是否有网络策略NetworkPolicy阻断了 webserver 到 worker 的访问。问题五配置解析失败密码或前缀带特殊字符导致崩溃症状容器启动后 airflow.cfg 内容异常或服务报配置错误重启多次依旧如此。原因kube-airflow 的config/airflow.cfg采用模板占位符机制如{{ POSTGRES_CREDS }}、{{ FERNET_KEY }}由script/entrypoint.sh在启动时用sed替换。README 中明确警告密码和 prefix 中不要使用、、/、\等特殊字符否则 sed 替换会出错导致配置文件损坏。解决方案检查airflow/values.yaml中配置的密码、url_prefix、flower.url_prefix是否包含特殊字符一律改为纯字母数字组合。自定义 airflow.cfg 时可通过 ConfigMap 方式注入参考airflow/myvalue-with-airflowcfg-configmap.yaml的示例注意保留模板占位符保证与集群中的环境变量对齐。如果密码已污染数据库连接串修改后记得重启 postgres、scheduler 和 worker 所有相关组件。总结与预防建议kube-airflow 的故障排查思路可以归纳为一条链路基础服务 → 配置解析 → 任务调度 → 日志回传。绝大多数问题都出在依赖服务未就绪、特殊字符污染配置、以及 DAG 同步策略选择不当这三个环节。最后给出三条预防建议一是部署前完整阅读项目根目录的 README 和airflow/Chart.yaml了解组件清单二是生产环境优先使用 embedded DAGs 而不是 git-sync三是为所有密码配置统一的命名规范坚决不出现特殊字符。做到这三点你的 Airflow 集群在 Kubernetes 上就能稳定运行很久。【免费下载链接】kube-airflowA docker image and kubernetes config files to run Airflow on Kubernetes项目地址: https://gitcode.com/gh_mirrors/ku/kube-airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
