Apache Airflow 的 Helm Chart¶

此 Chart 将使用 Helm 包管理器在 Kubernetes 集群上引导 Airflow 部署。

要求¶

Kubernetes 1.26+ 集群
Helm 3.0+
底层架构中的 PV 供应器支持（可选）

特性¶

支持的执行器：LocalExecutor、CeleryExecutor、KubernetesExecutor、LocalKubernetesExecutor、CeleryKubernetesExecutor
支持的 Airflow 版本：1.10+、2.0+
支持的数据库后端：PostgreSQL、MySQL
KEDA 为 CeleryExecutor 提供自动扩缩
带有经过实战测试配置的 PostgreSQL 和 PgBouncer
监控
- Airflow 的 StatsD/Prometheus 指标
- PgBouncer 的 Prometheus 指标
- Flower
新部署后自动进行数据库迁移
部署期间创建管理员帐户
Kerberos 安全配置
任何类型的执行器的一键式部署。您无需提供其他服务，例如 Redis/数据库来测试 Airflow。

安装 Chart¶

要使用 Helm 3 安装此 Chart，请运行以下命令

helm repo add apache-airflow https://airflow.apache.org
helm upgrade --install airflow apache-airflow/airflow --namespace airflow --create-namespace

该命令在 Kubernetes 集群上以默认配置部署 Airflow。参数参考部分列出了安装期间可以配置的参数。

提示

使用 helm list 列出所有版本。

升级 Chart¶

要升级发布名称为 airflow 的 Chart

helm upgrade airflow apache-airflow/airflow --namespace airflow

注意

要升级到新版本的 Chart，请先运行 helm repo update。

卸载 Chart¶

要卸载/删除 airflow 部署

helm delete airflow --namespace airflow

该命令会删除与 Chart 关联的所有 Kubernetes 组件并删除发布版本。

注意

Chart 创建的一些 Kubernetes 资源 helm hooks 在执行 helm uninstall 后可能会保留在命名空间中，例如， brokerUrlSecret 或 fernetKeySecret。

使用 Argo CD、Flux、Rancher 或 Terraform 安装 Chart¶

使用 Argo CD、Flux、Rancher 或 Terraform 安装 Chart 时，您必须设置以下四个值，否则您的应用程序将不会启动，因为迁移将不会运行

createUserJob:
  useHelmHooks: false
  applyCustomEnv: false
migrateDatabaseJob:
  useHelmHooks: false
  applyCustomEnv: false

这是为了使这些 CI/CD 服务可以执行更新而不会出现问题，并保持 Kubernetes Job 清单的不变性。

如果您在 helm install 命令中使用 --wait 安装 Chart，则也适用。

注意

在使用 Argo 部署此 Helm Chart 时，您可能会遇到数据库迁移在升级时不会自动运行的问题。

要使用 Argo CD 自动运行数据库迁移，您需要添加

migrateDatabaseJob:
    jobAnnotations:
        "argocd.argoproj.io/hook": Sync

这将每次在 Argo CD 中发生 Sync 事件时运行数据库迁移。虽然在每次同步时运行迁移并不理想，但这是一个允许它们自动运行的权衡。

如果将 Celery(Kubernetes)Executor 与内置的 Redis 一起使用，建议您通过提供 redis.passwordSecretName 和 data.brokerUrlSecretName 或 redis.password 来设置静态 Redis 密码。

默认情况下，Helm 钩子也为 extraSecrets 或 extraConfigMaps 启用。使用上述 CI/CD 工具时，您可能会由于这些默认钩子而遇到问题。

为了避免潜在的问题，建议通过设置 useHelmHooks=false 来禁用这些钩子，如以下示例所示

extraSecrets:
  '{{ .Release.Name }}-example':
    useHelmHooks: false
    data: |
      AIRFLOW_VAR_HELLO_MESSAGE: "Hi!"

extraConfigMaps:
  '{{ .Release.Name }}-example':
    useHelmHooks: false
    data: |
      AIRFLOW_VAR_HELLO_MESSAGE: "Hi!"

命名约定¶

对于新安装，强烈建议开始使用标准命名约定。默认情况下未启用，因为这可能会导致现有安装出现意外行为。但是，您可以使用 useStandardNaming 来启用它

useStandardNaming: true

对于现有安装，您的所有资源都将使用新名称重新创建，并且 helm 将删除先前的资源。

这不会删除 StatefulSets/Deployments 使用的日志的现有 PVC，但会使用全新的 PVC 重新创建它们。如果您确实想保留日志历史记录，则需要在部署后手动将这些卷的数据复制到新卷中。根据您使用的存储后端/类，此过程可能会有所不同。如果您不介意从新的日志/redis 卷开始，您可以直接删除旧的持久卷声明，例如

kubectl delete pvc -n airflow logs-gta-triggerer-0
kubectl delete pvc -n airflow logs-gta-worker-0
kubectl delete pvc -n airflow redis-db-gta-redis-0

注意

如果在升级后没有更改 useStandardNaming 或 fullnameOverride，您可以像往常一样继续，并且不会出现意外行为。