Apache Airflow 的 Helm Chart¶

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

需求條件¶

Kubernetes 1.26+ 叢集
Helm 3.0+
底層基礎架構中的 PV Provisioner 支援（選用）

功能特色¶

支援的執行器： 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.dev.org.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 組件，並刪除發行版本。

注意

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 Manifest 的不可變性。

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

注意

使用 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 hooks 也會針對 extraSecrets 或 extraConfigMaps 啟用。當使用上述 CI/CD 工具時，您可能會因為這些預設 hooks 而遇到問題。

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

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，您可以照常繼續，並且不會出現非預期的行為。