Helm Chart部署是最可行省事的路径，因其能统一管理webserver、scheduler、worker等多组件的资源、启动顺序与安全配置，避免手写YAML易漏initContainers、ConfigMap不一致、Pod安全策略拒绝等问题；新项目推荐官方Chart，社区版则适合已稳定运行的老集群。
直接用 Helm Chart 部署是最可行、最省事的路径，其他方式（如裸 YAML 手写、Kustomize、Operator）在生产环境里要么维护成本高，要么成熟度不够。
为什么不用自己写 Deployment 和 Service？
Airflow 不是单体应用，它至少包含 webserver、scheduler、worker（或 triggerer）、postgresql、redis（Celery 场景）等组件，每个组件对资源、启动顺序、健康检查、服务发现都有不同要求。手写 YAML 容易漏掉：
-
initContainers未等待数据库就绪，导致scheduler启动失败并反复 CrashLoopBackOff -
webserver和scheduler共享同一份AIRFLOW__CORE__SQL_ALCHEMY_CONN，但没统一注入 ConfigMap，改一处漏一处 - 没配
podSecurityContext和securityContext，Pod 在启用了 Pod Security Admission 的集群里直接被拒绝调度 -
worker的livenessProbe用/health端点，但 Celery Worker 默认不暴露该接口，探针永远失败
选官方 Helm Chart 还是社区 airflow-helm/charts？
官方 apache-airflow/airflow Chart（v1.15+）已足够稳定，支持 Airflow 2.8+ 和 Kubernetes 1.26+，且默认启用 KubernetesExecutor。社区版 airflow-helm/charts（非官方，GitHub 上 star 数超 3k）优势在于：
- 更细粒度的子 chart 拆分（比如可单独关掉
redis，只用postgresql做 Celery broker） - 内置
external-secrets集成模板，方便对接 Azure Key Vault / AWS Secrets Manager - 对
triggerer组件的资源配置项更明确（triggerer.resources），避免因 CPU 请求过低导致任务挂起 - 但它的文档更新滞后，部分参数名（如
executorType）和最新 Airflow 版本不一致，容易配错
建议：新项目优先用官方 Chart；已有集群长期使用社区版且稳定，无需切换。
执行器（Executor）怎么选？关键看任务隔离需求
不是“哪个快选哪个”，而是“哪个能避免任务互相污染”。常见组合：
-
KubernetesExecutor：每个任务起一个 Pod，资源、环境变量、镜像完全隔离。适合多团队共用、任务依赖冲突严重（比如 Python 包版本打架）、或需 GPU/特殊节点亲和性的场景。但调度延迟略高（Pod 创建开销），且必须确保airflow-worker命名空间有 RBAC 权限创建 Pod -
CeleryExecutor：Worker 是常驻进程，任务以消息形式投递，启动快、吞吐高。但所有任务共享 Worker Pod 的 Python 环境和内存，一个任务 OOM 可能拖垮整个 Worker -
LocalExecutor：仅限本地开发验证 DAG 逻辑，绝对不要用于任何类生产环境，它不支持多调度器，无法水平扩展
配置要点：KubernetesExecutor 必须设 executor=KubernetesExecutor，且 values.yaml 中显式开启 kubernetesExecutor.enabled=true；CeleryExecutor 要确认 redis.enabled=true 或已配置外部 Redis 地址。
部署后第一个要验证的不是 UI，而是 scheduler 日志
UI 能打开不代表 Airflow 在正常工作。真正关键的是 scheduler 是否持续解析 DAG 并触发任务。快速验证：
- 执行
kubectl logs -n airflow deploy/airflow-scheduler --tail=50 - 看到类似
INFO - Processing file .../dags/example_dag.py表示 DAG 加载成功 - 看到
INFO - Setting state for表示调度循环已启动 - 如果卡在
Waiting for database connection...，说明postgresql连接配置错误或 Pod 未就绪 - 如果反复报
Failed to fetch logs from worker，大概率是worker没起来，或core.logging_config_class指向了不存在的模块
最容易被忽略的是：DAG 文件挂载路径和 AIRFLOW__CORE__DAGS_FOLDER 环境变量必须严格一致，否则 scheduler 会静默跳过所有 DAG —— 它不会报错，只会安静地不干活。
