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；已有集群长期使用社区版且稳定，无需切换。

Kubernetes Security Posture Scorecard

评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……

下载

执行器（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 <taskinstance: example_dag.task_1 scheduled> to None</taskinstance:> 表示调度循环已启动
• 如果卡在 Waiting for database connection...，说明 postgresql 连接配置错误或 Pod 未就绪
• 如果反复报 Failed to fetch logs from worker，大概率是 worker 没起来，或 core.logging_config_class 指向了不存在的模块

最容易被忽略的是：DAG 文件挂载路径和 AIRFLOW__CORE__DAGS_FOLDER 环境变量必须严格一致，否则 scheduler 会静默跳过所有 DAG —— 它不会报错，只会安静地不干活。