Apache Airflow 的 Helm Chart¶

此 Chart 將使用 Helm 包管理器，在 Kubernetes 叢集上引導 Airflow 部署。

要求¶

Kubernetes 1.29+ 叢集
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.tw
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 hook 建立的某些 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 manifest 的不變性。

如果您在 helm install 命令中使用 --wait 引數，這也適用。

注意

在使用 Argo 部署此 Helm Chart 時，您可能會遇到資料庫遷移在升級時不會自動執行的問題。

要使用 Argo CD 自動執行資料庫遷移，您需要新增

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

這將使資料庫遷移在 Argo CD 中每次發生 Sync 事件時都執行。雖然在每次同步時都執行遷移並不理想，但這是一種權衡，可以使它們自動執行。

如果您使用內建 Redis 的 Celery(Kubernetes)Executor，建議您透過提供 redis.passwordSecretName 和 data.brokerUrlSecretName 或 redis.password 來設定一個靜態 Redis 密碼。

預設情況下，Helm hook 也對 extraSecrets 或 extraConfigMaps 啟用。當使用上述 CI/CD 工具時，您可能會由於這些預設的 hook 而遇到問題。

為了避免潛在問題，建議透過設定 useHelmHooks=false 來停用這些 hook，如下例所示

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，您可以照常進行，不會出現意外行為。