Konfiguration des Celery Kubernetes Executor für Airflow 2.0
Stehst du vor dem Dilemma, welchen Executor du für dein nächstes Airflow-Projekt wählen sollst? Celery Executor und Kubernetes Executor sind eine interessante Kombination – der Celery Kubernetes Executor vereint die Vorteile beider Lösungen. Möchtest du wissen, wie man ihn konfiguriert? Lies unseren Artikel, um es herauszufinden.
Airflow Kubernetes Executor vs Celery Executor – ein erster Blick
Airflow bietet zwei Executor-Typen, die die parallele Ausführung vieler Tasks ermöglichen. Der erste ist der Celery Executor, mit dem Aufgaben auf viele Worker verteilt werden können. Die Anzahl der Worker und deren Ressourcen werden im Voraus festgelegt. Diese Tasks können parallel auf jedem Worker ausgeführt werden, und die maximale Anzahl an Tasks pro Worker wird durch die Variable worker_concurrency definiert. Die Einschränkung ist, dass die Anzahl der Worker und deren Ressourcen im Voraus definiert und ständig aktiv sind – auch wenn keine Tasks ausgeführt werden, werden Ressourcen verbraucht und Kosten entstehen. Für den ordnungsgemäßen Betrieb des Celery Executor ist ein Message Broker (RabbitMQ / Redis) erforderlich, was die Konfiguration erschwert.
Ein weiterer Executor für die Arbeit mit vielen Tasks ist der Kubernetes Executor, der jede Task-Instanz in einem eigenen Kubernetes Pod ausführt. Der Vorteil ist, dass jede Task ihren eigenen dedizierten Ressourcenbereich hat. Ein Fehler in einer Task beeinflusst die anderen nicht. Bei der Konfiguration des Airflow Kubernetes Executor ist es notwendig, ein „template“ zu verwenden, das zur Erstellung neuer Pods für die jeweiligen Tasks dient.
Beide Lösungen haben Vor- und Nachteile, aber bei größeren Projekten kann die Wahl schwierig sein. Hier kommt die neueste Lösung in Airflow 2.0 ins Spiel – der Celery Kubernetes Executor.
In diesem Beispiel haben wir Teile unseres neuesten Produkts auf Basis des Airflow 2.0 Service verwendet, das von DS Stream aktiv entwickelt wird (daher können wir den vollständigen Code nicht bereitstellen). Bei Interesse an Details kontaktiere bitte unseren Vertrieb. Bald werden weitere Informationen zu diesem Projekt auf unserer Website verfügbar sein.
Celery Kubernetes Executor – Konfiguration
Dies ist eine Kombination der beiden oben genannten Lösungen. Sie ermöglicht die gleichzeitige Nutzung von Celery und Kubernetes Executor. Diese Kombination bietet mehr Möglichkeiten, erfordert aber auch mehr Aufwand, da beide Executor konfiguriert werden müssen. Sie ist vor allem ideal für Prozesse, bei denen viele einfache Tasks (für Celery) und gleichzeitig ressourcenintensive oder isolierte Tasks (für Kubernetes) anfallen.
Konfiguration des Celery Kubernetes Executor
Um Airflow für die Nutzung des Celery Kubernetes Executor zu konfigurieren, benötigst du:
- Eine externe Datenbank
- Einen Message Broker (RabbitMQ/Redis)
- pod-template.yaml – das Pod-Template, das der Kubernetes Executor zur Erstellung neuer Pods benötigt
In der Konfigurationsdatei airflow.cfg ist executor=CeleryKubernetesExecutor und kubernetes_queue = kubernetes zu setzen. In diesem Fall ist Celery Executor der Standard-Executor. Möchte man den Kubernetes Executor nutzen, muss dies in der DAG-Datei im Operator über die Variable queue=’kubernetes’ angegeben werden:
Unser System läuft auf dem Kubernetes Service in Microsoft Azure. Dafür muss ein Docker Image für das Airflow-Setup konfiguriert werden. Wir verwenden das Apache Airflow Image in Version 2.1.4 von https://hub.docker.com. Beispielhafter Dockerfile-Code:
Wichtig ist die Erstellung der pod-template.yaml, die der Kubernetes Executor beim Erstellen neuer Pods verwendet. Hier können die benötigten Ressourcen und Limits für jeden Pod definiert werden. Lade diese Datei in das Image, das in der Airflow-Konfiguration verwendet wird, in das Verzeichnis ${AIRFLOW_HOME}/.
Der Pfad zu dieser Datei muss in pod_template_file in der airflow.cfg gespeichert werden (pod_template_file = /opt/airflow/pod-template.yaml).
Die Konfiguration von Celery mit dem Message Broker ist identisch mit der des Celery Executor. Wir haben dies in einem anderen Artikel beschrieben.
Testen
Mit dieser Konfiguration kann Airflow je nach Projektbedarf beide Executor nutzen. Zum Testen habe ich Airflow wie oben beschrieben konfiguriert und überprüft, ob beide Executor verwendet werden können. Es wurden zwei DAGs erstellt:
- test_10_task_celery – Celery Executor (10 parallele Tasks)
- test_10_task_kubernetes – zum Testen des Kubernetes Executor (10 parallele Tasks)
Der einzige Unterschied ist der Parameter queue=”kubernetes” in test_10_task_kubernetes.
Für den Celery Executor gibt es 10 Worker (worker-deployment-%), für den Kubernetes Executor entstehen 10 temporäre Worker (test10taskkubernetestask#.%):
Nach Abschluss von test_10_task_kubernetes werden die temporären Worker gelöscht, aber die Celery Worker bleiben aktiv.
Der so konfigurierte Celery Kubernetes Executor ermöglicht auch das Ausführen von 1000 parallelen Tasks, sowohl mit dem Celery Executor als auch mit dem Kubernetes Executor. Dafür wurden folgende Parameter gesetzt:
- scheduler_heartbeat_sec = 1
- worker_pods_creation_batch_size = 16
- worker_pods_pending_timeout = 600
- worker_pods_queued_check_interval = 10
Der Vorteil des Kubernetes Executor ist, dass Ressourcen nicht ständig verbraucht werden. Celery verbraucht Ressourcen permanent, da die Worker rund um die Uhr laufen, während Kubernetes nur Ressourcen nutzt, wenn Tasks ausgeführt werden. Die Frage ist – welche Lösung ist finanziell vorteilhafter? Wir haben einen kleinen Vergleich mit dem Azure Pricing Calculator gemacht. Wir haben angenommen, dass der Kubernetes Executor 1 Stunde pro Tag läuft (13 Nodes); zusätzlich werden 2 Nodes für Webserver und Scheduler benötigt.
Für den Celery Executor werden 6 Nodes für den gesamten Monat benötigt. Die Ergebnisse des Vergleichs:
Der Unterschied beträgt über 1000 USD zugunsten des Kubernetes Executor! Die Kosten können stark variieren, aber jeder Fall muss individuell analysiert werden. Wenn die Ressourcen nicht 1, sondern 5 Stunden pro Tag benötigt würden, wären die Kosten beider Lösungen gleich.
Fazit
Sowohl Celery als auch Kubernetes Executor haben ihre Vor- und Nachteile. Keiner ist für jede Aufgabe perfekt. Der Celery Executor ist ideal für viele Tasks, die wenig Ressourcen benötigen. Der Kubernetes Executor ermöglicht es, für jede Task eine eigene Umgebung zu schaffen, was anspruchsvollere Tasks erlaubt. Außerdem hält der Kubernetes Executor keine unnötigen, ungenutzten Pods vor, wenn keine Tasks anstehen, während der Celery Executor eine festgelegte Anzahl an Workern dauerhaft betreibt – unabhängig von der Auslastung. Ihre Kombination, möglich mit Airflow 2.0 – der Celery Kubernetes Executor – ermöglicht noch bessere und effizientere Arbeit, ohne die Kompromisse, die bei der Wahl eines einzelnen Executors notwendig wären.
Wie kann Airflow deinem Unternehmen helfen? Besuche unsere Seite zur Data Pipeline Automation und finde die passende Lösung für deine Anforderungen. Der gesamte Airflow-Startprozess wird durch unsere Anwendung automatisiert, sodass du die gesamte Infrastruktur mit einem Klick einrichten kannst. Bei der Entwicklung werden moderne Konzepte und Technologien wie CI/CD, Terraform oder Kubernetes eingesetzt. Für weitere Details – kontaktiere unseren Vertrieb.
Verteilte systeme und das cap theorem
Databricks verbindung zum cluster vom lokalen ide
Was ist eine relationale datenbank
