Bereitstellung von Apache Airflow auf Azure Kubernetes Service

In diesem Beitrag wird beschrieben, wie Sie Apache Airflow mit dem Kubernetes Executor auf Azure Kubernetes Service (AKS) einsetzen können. Außerdem erfahren Sie mehr über die Registrierung eines geeigneten Domainnamens für Airflow, der über HTTPS läuft. Um diesen Beitrag optimal nutzen zu können, sollten Sie über Grundkenntnisse in helm, kubectl und Docker verfügen, da die Befehle hier nicht im Detail erklärt werden. Kurz gesagt: Docker ist derzeit die beliebteste Container-Plattform und ermöglicht es Ihnen, in sich geschlossene Umgebungen zu isolieren und zu packen. Kubernetes (zugänglich über das Kommandozeilen-Tool kubectl) ist eine leistungsstarke und umfassende Plattform für die Orchestrierung von Docker-Containern. Helm ist eine auf kubectl aufbauende Schicht und ein Anwendungsmanager für Kubernetes, der die gemeinsame Nutzung und Installation komplexer Anwendungen auf Kubernetes erleichtert.

Erste Schritte

Um loszulegen und mitzumachen:

1. Klonen Sie das Airflow-Docker-Image-Repository
2. Klonen Sie die Airflow-Steuerkarte

Erstellen Sie eine Kopie von ./airflow-helm/airflow.yaml nach ./airflow-helm/airflow-local.yaml. Wir werden diese Datei im Laufe dieses Handbuchs ändern.

Kubernetes Executor auf Azure Kubernetes Service (AKS)

Der Kubernetes-Executor für Airflow führt jede einzelne Aufgabe in einem separaten Pod aus. Dies geschieht, indem er mit dem Befehl airflow run einen neuen Lauf der Aufgabe in einem neuen Pod startet. Der Executor sorgt auch dafür, dass der neue Pod eine Verbindung zur Datenbank und den Speicherort der DAGs und Protokolle erhält.

AKS ist ein verwalteter Kubernetes-Dienst, der in der Microsoft Azure Cloud läuft. Es wird davon ausgegangen, dass der Leser bereits einen solchen Cluster eingerichtet hat - dies ist in der Tat recht einfach, wenn Sie die Schnellstartanleitung verwenden. Hinweis: Diese Anleitung wurde mit der AKS-Version 1.12.7 geschrieben.

Der Fernet-Schlüssel in Airflow ist dafür gedacht, geheime Werte von der Datenbank zum Executor zu übermitteln. Wenn der Executor keinen Zugriff auf den fernet-Schlüssel hat, kann er keine Verbindungen entschlüsseln. Um sicherzustellen, dass dies möglich ist, setzen Sie den folgenden Wert in airflow-local.yaml:

Luftstrom:
  fernetKey:

Verwenden Sie bcb.github.io/airflow/fernet-key, um einen fernet-Schlüssel zu erzeugen.

Diese Einstellung sorgt dafür, dass der Fernet-Schlüssel an die Executor-Pods weitergegeben wird. Dies geschieht automatisch durch den Kubernetes Executor in Airflow.

Bereitstellen mit Helm

Stellen Sie zusätzlich zum airflow-helm Repository sicher, dass Ihr kubectl so konfiguriert ist, dass es den richtigen AKS-Cluster verwendet (wenn Sie mehr als einen haben). Wenn Sie einen Kubernetes-Cluster namens aks-airflow haben, können Sie das Azure CLI oder kubectl verwenden.

az aks get-credentials --name aks-airflow --resource-group MeineRessourcenGruppe

oder

kubectl config use-context aks-airflow

auf. Beachten Sie, dass letzteres nur funktioniert, wenn Sie den ersten Befehl mindestens einmal aufgerufen haben.

Azure Postgres

Um die Cloud-Funktionen vollständig nutzen zu können, werden wir mit einer verwalteten Azure Postgres-Instanz verbunden. Wenn Sie noch keine haben, ist die Schnellstartanleitung Ihr Freund. Der gesamte Status von Airflow wird im Metaspeicher gespeichert. Wenn Sie sich für diese verwaltete Datenbank entscheiden, müssen Sie sich auch nicht mehr um Backups kümmern.

Das in der Steuerkarte verwendete Docker-Image verwendet eine entrypoint.sh, die einige unangenehme Annahmen macht:

Es erstellt den Wert AIRFLOWCORESQL_ALCHEMY_CONN mit den Postgres-Werten host, port, user und password. Das Problem ist, dass es standardmäßig eine unverschlüsselte (keine SSL) Verbindung erwartet. Da dieser Blogpost eine externe Postgres-Instanz verwendet, müssen wir SSL-Verschlüsselung verwenden.

Die einfachste Lösung für dieses Problem ist, die Dockerfile zu ändern und die Zeilen ENTRYPOINT und CMD vollständig zu entfernen. Dazu müssen Sie allerdings ein eigenes Image erstellen und es in Ihre Container-Registry einspeisen. Die Azure Container Registry (ACR) würde diesen Zweck sehr gut erfüllen.

Anschließend können wir mit psql den Benutzer und die Datenbank für Airflow erstellen. Am einfachsten ist es, sich im Azure-Portal anzumelden, eine Cloud-Shell zu öffnen und sich mit Ihrem Admin-Benutzer mit der Postgres-Datenbank zu verbinden. Von hier aus können Sie den Benutzer, die Datenbank und die Zugriffsrechte für Airflow erstellen mit

erstellen Datenbank Luftstrom;
Benutzer airflow mit verschlüsseltem Passwort 'foo' anlegen;
gewähren Sie airflow alle Rechte für die Datenbank airflow;

Sie können dann den folgenden Wert (unter der Annahme, dass Ihre Postgres-Instanz posgresdbforairflow heißt) in airflow-local.yaml einstellen:

Luftstrom:
  sqlalchemy_connection: postgresql+psycopg2://airflow@posgresdbforairflow:foo@posgresdbforairflow.postgres.database.azure.com:5432/airflow?sslmode=require

Beachten Sie die sslmode=require am Ende, die Airflow anweist, eine verschlüsselte Verbindung zu Postgres zu verwenden.

Da wir ein benutzerdefiniertes Bild verwenden, müssen wir dies an helm weitergeben. Stellen Sie die folgenden Werte in airflow-local.yaml ein:

Luftstrom:
  Bild:
    Repository: youracrservice.azurecr.io/custom-docker-airflow
    Tag: 1.10.2
    pullPolicy: IfNotPresent
    pullSecret: acr-auth

Beachten Sie das acr-auth pull secret. Sie können es entweder selbst erstellen oder - noch besser - helm darum kümmern lassen. Damit helm das Geheimnis für Sie erstellt, setzen Sie die folgenden Werte in airflow-local.yaml:

imageCredentials:
  Registry: youracrservice.azurecr.io
  Benutzername: youracrservice
  Passwort: passwort-für-azure-container-registry

Der Sqlalchemy-Verbindungsstring wird auch an die Executor-Pods weitergegeben. Wie der fernet-Schlüssel wird auch dies vom Kubernetes Executor durchgeführt.

Dauerhafte Protokolle und Dags mit Azure Fileshare

Microsoft Azure bietet eine Möglichkeit, SMB-Dateifreigaben in jeden Kubernetes-Pod einzuhängen. Um eine dauerhafte Protokollierung zu ermöglichen, konfigurieren wir das Steuerdiagramm für die Einbindung einer Azure-Dateifreigabe (AFS). Die Einrichtung von logrotate fällt aus dem Rahmen, wird aber dringend empfohlen, da Airflow (insbesondere der Scheduler) sehr viele Protokolle erzeugt. In dieser Anleitung werden wir auch ein AFS für den Speicherort der Dags verwenden.

Stellen Sie die folgenden Werte ein, um die Protokollierung auf einer Dateifreigabe in airflow-local.yaml zu aktivieren.

Ausdauer:
  Dateispeicher:
    storageAccountName: IhrZeichenSpeicherkontoname
    storageAccountKey: Ihr Azurestorage-Kontoschlüssel
  Protokolle:
    secretName: logssecret
    shareName: yourlogssharename
  dags:
    secretName: dagssecret
    shareName: yourdagssharename

Der Name von shareName muss mit einem AFS übereinstimmen, den Sie vor dem Einsatz der Steuerkarte erstellt haben.

Jetzt ist alles für die persistente Protokollierung und persistente Dags eingerichtet.

Damit ist die Arbeit mit helm abgeschlossen und airflow kann nun eingesetzt werden! Führen Sie den folgenden Befehl von dem Pfad aus, in dem sich Ihr airflow-local.yaml befindet:

helm install --namespace  "Luftstrom"  --name  "Luftstrom"  -f airflow-local.yaml airflow/

Der nächste Schritt wäre exec -it im Webserver oder Scheduler Pod und die Erstellung von Airflow-Benutzern. Dies würde den Rahmen dieses Handbuchs sprengen.

helm install stable/nginx-ingress --namespace airflow --set controller.replicaCount=2  ----set rbac.create=false

kubectl -n airflow get service --watch

IP=$(kubectl -n airflow get service nameIhrer-nginx-ingress-controller -o  jsonpath={.status.loadBalancer.ingress..ip})

# Name, der mit der öffentlichen IP-Adresse verknüpft werden soll
DNSNAME="IhrAirflowdnsname"

# Abrufen der Ressourcen-ID der öffentlichen IP
PUBLICIPID=$(az network public-ip list --query  "[?ipAddress!=null]|[?contains(ipAddress, '$IP')].[id]"  --Ausgabe tsv)

# Öffentliche IP-Adresse mit DNS-Namen aktualisieren
az network public-ip update --ids $PUBLICIPID --dns-name  $DNSNAME

# Installieren Sie die CustomResourceDefinition-Ressourcen separat.
kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.7/deploy/manifests/00-crds.yaml

# Erstellen Sie den Namespace für cert-manager
kubectl create Namespace cert-manager

# Kennzeichnen Sie den cert-manager-Namensraum, um die Ressourcenüberprüfung zu deaktivieren.
kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true

# Fügen Sie das Jetstack Helm Repository hinzu.
helm repo jetstack hinzufügen https://charts.jetstack.io

# Aktualisieren Sie den Cache Ihres lokalen Helm Chart-Repositorys.
helm repo update

# Installieren Sie den cert-manager Helm Chart
Steuerruder installieren  
  --name cert-manager  
  --namespace cert-manager  
  --version v0.7.0  
  jetstack/cert-manager

apiVersion: certmanager.k8s.io/v1alpha1
Art: ClusterIssuer
Metadaten:
  Name: letsencrypt-prod
  Namensraum: airflow
spec:
  acme:
  Server: https://acme-v02.api.letsencrypt.org/directory
  E-Mail: youremail@domain.com
  privateKeySecretRef:
  Name: letsencrypt-prod
  http01:  {}

kubectl apply -f cluster-issuer.yaml

apiVersion: erweiterungen/v1beta1
freundlich: Eindringen
Metadaten:
  Name: airflow-ingress
  Namespace: Luftstrom
  Anmerkungen:
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt-prod
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - Wirte:
        - yourairflowdnsname.yourazurelocation.cloudapp.azure.com
      secretName: tls-geheim
  Regeln:
    - Gastgeber: yourairflowdnsname.yourazurelocation.cloudapp.azure.com
      http:
        Pfade:
          - Pfad: /
            Backend:
              serviceName: airflow-web
              servicePort: 8080

kubectl apply -f ingress-routes.yaml

Upgrade des Steuerrads  
  --Chaos installieren  
  --set  dryRun=false 
  --set  Intervall=5m  
  --set  Namespaces=Luftstrom  
  --set  Etiketten="app=airflow-scheduler" 
  stabil/chaoskube