Apache Airflow sur Kubernetes: Guide pour la Production

Ce tutoriel est le premier d’une série visant à deployer des jobs spark sur kubernetes en les orchestrant avec apache airflow. Ce premier tutoriel vise à deployer airflow sur un cluster kubernetes tout en respectant les exigences de la production.

Apache Airflow

Apache Airflow est un outil open-source d’orchestration de workflows conçu pour automatiser et gérer des flux de données complexes. Sa structure fondamentale repose sur les Directed Acyclic Graphs (DAGs), qui définissent les dépendances et l’ordre d’exécution des différentes tâches.

Ses principales caractéristiques :

• Planification flexible : Airflow permet la planification basée sur le temps, les dépendances entre les tâches, ou des événements externes.
• Extensibilité : Il offre une bibliothèque étendue de connecteurs et d’opérateurs pré-construits, ainsi que la possibilité de créer des opérateurs personnalisés.
• Interface web conviviale : Une interface utilisateur web permet de surveiller les workflows, de visualiser les DAGs, et d’accéder aux journaux d’exécution.
• Intégration avec d’autres outils : Airflow peut s’intégrer à diverses technologies telles que Kubernetes, Docker, et des bases de données, offrant ainsi une grande flexibilité.
• Communauté active : En tant que projet open-source soutenu par la Apache Software Foundation, Airflow bénéficie d’une communauté active qui contribue à son développement continu.

En résumé, Apache Airflow simplifie l’automatisation des workflows, offrant une solution flexible et extensible pour la gestion efficace des opérations et des données.

Kubernetes

Kubernetes est une plateforme open-source d’orchestration de conteneurs qui simplifie et automatise le déploiement, la mise à l’échelle et la gestion d’applications conteneurisées. Au cœur de son fonctionnement se trouve la déclaration d’état désiré, où les utilisateurs spécifient l’état souhaité de leur application, et Kubernetes travaille pour maintenir cet état.

Airflow sur Kubernetes

Airflow présente une architecture distribuée, ce qui signifie que lors de son déploiement sur Kubernetes, chaque composant de cette architecture est représenté par une ressource distincte au sein de l’écosystème Kubernetes. Cette approche de déploiement offre des avantages en termes de scalabilité et de maintenance des composants.

Pour mieux comprendre le rôle de chaque composant dans cette architecture distribuée, vous pouvez consulter la documentation officielle d’ Airflow disponible à l’adresse suivante :

https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html

Apache propose également une chart Helm préconfigurée qui regroupe toutes les ressources nécessaires pour exécuter Airflow sur un cluster Kubernetes. Ces ressources sont adaptables en fonction de nos exigences spécifiques afin d’ajuster Airflow selon les besoins et les spécifications de l’environnement dans lequel il sera déployé.

Deploiement de la chart helm de Airflow

Il est important de s’assurer que les clients kubectl et helm sont bien installés.

• Ajouter la chart au repo local

helm repo add apache-airflow https://airflow.apache.org/

• Installer une release avec les configurations par défaut

# latest version
helm install  myairflow  apache-airflow/airflow --create-namespace --namespace airflow --debug

# version précise
helm install myairflow apache-airflow/airflow  --namespace airflow --version 1.11.0 --debug

• Vérifier l’état du déploiement

Kubectl get po -n airflow

Sortie:

kubectl port-forward svc/myairflow-webserver 8080:8080 --namespace airflow

Vous pouvez désormais accéder au airflow-UI à l’adresse localhost:8080

A cette étape nous avons un airflow qui fonctionne avec des configurations de base. La prochaine étape consistera à modifier les configurations suivant nos exigences.

Mise à jour des configurations

Dans un premier temps recupérer les values de la chart dans un fichier. C’est dans ce fichier que nous modifierons les configurations.

helm show values apache-airflow/airflow> values.yaml 

1- Customiser et étendre l’image airflow

L’image Docker utilisée dans les configurations par défaut est l’image de base de Airflow fournie par apache. Nous allons étendre cette image en y ajoutant les packages nécessaires pour exécuter nos DAGs et également le providers apache spark. N’oublions pas que notre objectif est d’intégrer spark et airflow.

• Créer le fichier de requirements avec tous les packages nécessaires (requirements.txt)

pandas==1.3.5
minio==6.0.2
numpy==1.21.6
pyspark==3.4.0
minio==6.0.2

• Construire notre image personnalisée (Dockerfile)

FROM apache/airflow:2.7.3
LABEL maintainer="Yasmine"
SHELL ["/bin/bash", "-o", "pipefail", "-c"]
USER root
RUN apt-get update \
  && apt-get install -y --no-install-recommends \
         openjdk-11-jre-headless \
  && apt-get autoremove -yqq --purge \
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/*
USER airflow
COPY requirement.txt .
RUN pip install -r requirement.txt
ENV JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
RUN pip install --no-cache-dir "apache-airflow==${AIRFLOW_VERSION}" apache-airflow-providers-apache-spark==2.1.3

docker build . -t myairflow:1.0.0

Pousser cette image sur un hub public (docker hub) ou le hub privé de votre institution (habor)

docker tag myairflow:1.0.0 docker.io/yasminekd/myairflow:1.0.0
docker push docker.io/yasminekd/myairflow:1.0.0

Note: Les providers tels que ceux de spark ou encore amazon évoluent indépendamment de airflow core. Toutes les fois où vous souhaiterez upgrade ou ajouter l’un des providers, il vous faudra réecrire l’image.

• Mettre à jour le fichier de values

2- Configurer gitSync

Il existe plusieurs approches pour stocker les DAGs. On peut les placer directement dans l’image, les stocker dans un hostPath, mais notre préférence va à la sauvegarde des DAGs sur un dépôt Git. Grâce à GitSync, nos workers pourront ainsi lire les DAGs depuis le dépôt Git configuré.

• Créer le kubernetes secret contenant les credentials de connexion à votre repo (credentialSecret.yaml)

 apiVersion: v1
 kind: Secret
 metadata:
   name: git-credentials
 data:
   GIT_SYNC_USERNAME: <base64_encoded_git_username>
   GIT_SYNC_PASSWORD: <base64_encoded_git_password>

Remplacer <base64_encoded_git_username> par le username encodé en base64. De même pour le password.

kubectl apply -f credentialSecrets.yaml -n airflow

• Mettre à jour le fichier de values

Note:

• Si vous utilisez github, le mot de passe est remplacé par un token à générer sur votre compte github
• La connexion peut également se faire via SSH

3- Configurer le metastore

La chart Helm installe par défaut un conteneur PostgreSQL pour stocker les métadonnées. Cependant, en environnement de production, il est recommandé d’avoir une base de données externe fonctionnant soit sur une machine dédiée soit sur un service cloud tel qu’AWS RDS.

• Désactiver la création de la sous chart postgresql

• configurer l’accès à votre serveur postgres

Note: Soit vous créer un kubernetes secret soit vous renseigner directement les accès.

4. Exposer l’interface utilisateur de airflow

Afin de le rendre accessible même en dehors du cluster, nous allons exposer le service de l’interface utilisateur d’Airflow (UI) via un NodePort ou un loadBalancer.

Vous pouvez acceder à l’interface via l’URL suivante: <IP-noeud-cluster:31151>

Pour récuperer l’IP d’un noeud de votre cluster

kubectl get no -o wide

5. Connexion au web serveur

Pensez à génerer une clé secrète forte

6- Application des modifications

helm upgrade  myairflow  apache-airflow/airflow -f values.yaml --namespace airflow --debug

Nous avons examiné certaines bonnes pratiques de production que nous appliquons généralement dans nos environnements. Il existe d’autres pratiques que nous ne détaillerons pas ici.

Parmi ces pratiques, on retrouve :

• La définition des ressources de requêtes (requests) et des limites (limits) pour tous les services. Cela peut être défini dans le fichier values.yaml. Par exemple, spécifier la quantité de CPU ou de mémoire que chaque service peut demander ou utiliser.
• La configuration des securityContext pour définir les permissions et contrôles de sécurité pour les conteneurs.
• La mise en place de services de métriques pour surveiller les performances des applications, ce qui sera abordé dans un article ultérieur.

Ces pratiques sont essentielles pour garantir la sécurité, les performances et la fiabilité des environnements de production, mais elles peuvent nécessiter une analyse plus approfondie pour leur mise en œuvre.

CONCLUSION

Il semble que nous ayons réussi le déploiement d’Airflow dans votre cluster Kubernetes, sans réplication des services pour le moment. Dans un prochain article, nous explorerons comment effectuer un déploiement multi-workers et comment gérer efficacement les logs.

Pour la suite de cette série, nous aborderons l’exécution d’un job Spark sur un cluster Kubernetes. Cela implique l’intégration de Spark avec Kubernetes pour permettre l’exécution de tâches Spark dans votre environnement Kubernetes.