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 组件,并删除该版本。
注意
执行 helm uninstall
后,Chart helm 钩子 创建的一些 Kubernetes 资源可能会保留在命名空间中,例如 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 密码,方法是提供 redis.passwordSecretName
和 data.brokerUrlSecretName
或 redis.password
。
命名约定¶
对于新安装,强烈建议开始使用标准命名约定。默认情况下不启用它,因为这可能会导致现有安装出现意外行为。但是,您可以使用 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
,则可以照常进行,不会出现意外行为。