Premiers pas avec OKDP, la plateforme de données sur Kubernetes

L’Open Kubernetes Data Platform (OKDP) est une plateforme de gestion de données cloud-native couvrant l’intégralité du cycle de vie de la donnée. Elle intègre des outils open source de référence, dont Apache Spark et Apache Trino comme moteurs de traitement, Apache Superset pour la visualisation, et Apache Airflow pour l’ordonnancement des traitements. Actuellement en développement actif, la release 1.0.0 est prévue le 14 septembre 2026. Conçue de manière modulaire, OKDP vise à simplifier chaque étape du parcours de la donnée.

Une présentation d’OKDP, l’Open Kubernetes Data Platform offre une vue d’ensemble du projet. Ce guide explore certaines fonctionnalités de la plateforme en déployant un cluster local via la sandbox OKDP. Intégrant une interface graphique pour la gestion de la plateforme ainsi qu’une suite complète d’outils data, le sandbox constitue un environnement de démonstration idéal pour explorer le potentiel du projet OKDP.

Prérequis

La machine hôte doit satisfaire les conditions suivantes avant de démarrer.

16 Go de RAM et 4 cœurs CPU minimum
Docker
Kind
kubectl
Flux CLI

Installation initiale

Démarrer avec la plateforme OKDP est remarquablement simple. Le provisionnement complet du cluster et l’installation des composants de base s’effectuent en moins de 30 minutes, permettant d’explorer immédiatement Spark et Trino.

Initialisation du cluster et installation des composants de base

Après avoir vérifié que la machine hôte satisfait les prérequis, l’installation commence par le clonage du dépôt en local.

git clone https://github.com/OKDP/okdp-sandbox.git
cd okdp-sandbox

Le sandbox est lancé via kind, un outil permettant de faire tourner Kubernetes localement dans des conteneurs Docker. Un fichier de configuration temporaire est créé puis transmis à la commande kind create cluster pour démarrer le cluster.

# Création de la configuration du cluster
cat > /tmp/okdp-sandbox-config.yaml <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: okdp-sandbox
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30080
    hostPort: 80
  - containerPort: 30443
    hostPort: 443
  - containerPort: 30053
    hostPort: 30053
    protocol: UDP
EOF
# Création du cluster
kind create cluster --config /tmp/okdp-sandbox-config.yaml

Flux est l’outil GitOps utilisé par le sandbox. Il est installé dans le cluster via le CLI flux.

# Installation de Flux
flux install

L’environnement sandbox utilise KuboCD, qui étend Flux et Helm pour simplifier le déploiement et la gestion des composants de la plateforme. KuboCD permet de définir l’état désiré de manière déclarative via un ensemble de ressources personnalisées. L’une des ressources les plus importantes est le Context, un objet YAML centralisant les valeurs de configuration partagées — suffixes d’ingress, paramètres d’authentification — applicables à plusieurs déploiements.

L’extension KuboCD est activée dans le cluster via kubectl apply, puis son bon démarrage est vérifié par une série de commandes wait avant de continuer.

# Installation de KuboCD
kubectl apply -f clusters/sandbox/flux/kubocd.yaml
# Attente de la disponibilité des CRDs
kubectl wait --for=condition=Established --timeout=300s \
  crd/contexts.kubocd.kubotal.io \
  crd/releases.kubocd.kubotal.io \
  crd/configs.kubocd.kubotal.io \
  crd/clustercontracts.kubocd.kubotal.io \
  crd/connections.kubocd.kubotal.io
# Attente du démarrage du contrôleur KuboCD
kubectl -n kubocd wait \
  --for=condition=Available deploy/kubocd-ctrl-controller --timeout=300s
# Attente de la fin d'installation du chart
kubectl -n flux-system wait \
  --for=condition=Ready helmrelease/kubocd-controller --timeout=300s

Le metrics-server est installé pour surveiller les ressources du cluster.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
kubectl patch deployment metrics-server -n kube-system --type=json \
  -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--kubelet-insecure-tls"},
       {"op": "replace", "path": "/spec/template/spec/containers/0/livenessProbe/timeoutSeconds", "value": 3},
       {"op": "replace", "path": "/spec/template/spec/containers/0/readinessProbe/timeoutSeconds", "value": 3}]'
# Attente de l'application de la mise à jour du pod
kubectl -n kube-system rollout status deploy/metrics-server --timeout=300s
# Attente de la disponibilité de l'API
kubectl wait --for=condition=Available apiservice/v1beta1.metrics.k8s.io --timeout=300s
# Vérification du bon fonctionnement du serveur
kubectl top nodes
#> NAME                         CPU(cores)   CPU(%)   MEMORY(bytes)   MEMORY(%)
#> okdp-sandbox-control-plane   428m         2%       14489Mi         15%

Le cluster est initialisé avec les composants de base, notamment Keycloak pour la gestion des identités et des accès, et CloudNativePG pour le contrôleur PostgreSQL.

# Chargement du contexte par défaut
kubectl apply -f clusters/sandbox/contracts/
kubectl apply --server-side -f clusters/sandbox/contexts/
# Déploiement des composants de base
kubectl apply -f clusters/sandbox/releases/

Le déploiement des composants système prend généralement entre 10 et 15 minutes. Deux options permettent de suivre l’avancement de l’installation. La commande --watch affiche les mises à jour en temps réel dans le terminal, mais nécessite une sortie manuelle une fois tous les composants prêts. La commande wait, quant à elle, ne fournit pas d’informations de progression mais se termine automatiquement.

kubectl get releases -A --watch
# Alternative :
# kubectl wait --for=jsonpath='{.status.phase}'=READY release --all -n kubocd-system --timeout=900s

Configuration DNS

Plusieurs options de configuration DNS sont disponibles, notamment le déploiement d’un serveur DNS local ou la modification manuelle du fichier /etc/hosts. Ce guide utilise la configuration recommandée avec un serveur DNS local pour gérer automatiquement la résolution de tous les services. Consultez la documentation de configuration DNS pour les autres options disponibles, y compris les instructions de configuration manuelle via /etc/hosts.

Le répertoire resolved.conf.d est créé s’il n’existe pas. Un fichier de configuration est ensuite généré dans un emplacement temporaire puis déplacé dans le répertoire système. Enfin, systemd-resolved est redémarré pour charger la nouvelle configuration.

sudo mkdir -p /etc/systemd/resolved.conf.d
cat <<INI | sudo tee /etc/systemd/resolved.conf.d/okdp-sandbox.conf
[Resolve]
DNS=127.0.0.1:30053
Domains=~okdp.sandbox
INI
sudo systemctl restart systemd-resolved

Après le redémarrage du service systemd-resolved, exécutez dig et nslookup pour vérifier que les paramètres sont bien pris en compte.

# Test avec dig
dig @127.0.0.1 -p 30053 okdp-ui.okdp.sandbox

# Test de résolution DNS
nslookup -port=30053 okdp-ui.okdp.sandbox 127.0.0.1
# Doit résoudre vers 127.0.0.1

Configuration SSL

Le sandbox utilise une autorité de certification auto-signée. Lors de la première connexion, le navigateur affiche une erreur de certificat. Les utilisateurs doivent soit importer l’autorité de certification dans le navigateur, soit ignorer le message d’erreur. Choisir d’ignorer les avertissements de sécurité nécessite de se connecter à Keycloak et d’accepter le certificat pour garantir la bonne communication entre les services OKDP.

Procédure d’importation du certificat dans Firefox

Pour ne plus avoir à accepter manuellement l’autorité de certification, Firefox doit être configuré pour faire confiance au CA d’OKDP. Commencez par récupérer le certificat public .crt depuis le cluster via la commande kubectl get secret.

kubectl get secret default-issuer -n cert-manager -o jsonpath='{.data.ca\.crt}' | base64 -d > okdp-sandbox-ca.crt

Ouvrez un nouvel onglet ou une nouvelle fenêtre dans le navigateur et accédez à about:preferences, puis recherchez certificates. Cliquez sur manage certificates pour ouvrir une nouvelle fenêtre. Choisissez l’option import, naviguez jusqu’au certificat obtenu précédemment. Une boîte de dialogue s’ouvre : sélectionnez les niveaux de confiance souhaités et enregistrez.

Première connexion avec Keycloak

En accédant à l’interface graphique pour la première fois, un écran de connexion s’affiche. En cliquant sur l’option de connexion, l’utilisateur est redirigé vers l’écran de connexion Keycloak. L’utilisateur administrateur est préconfiguré avec identifiant : adm et mot de passe : adm.

Après authentification, l’utilisateur est redirigé vers l’interface sandbox OKDP.

Déploiement d’un projet de démonstration

Dans OKDP, un project regroupe un namespace avec ses secrets, ses instances PostgreSQL, ses connexions et ses services data. Bien que les administrateurs OKDP puissent gérer les projets et leurs composants directement depuis l’interface, la sandbox fournit des fichiers de configuration pour provisionner rapidement un projet via kubectl apply.

# Installation du stockage objet SeaweedFS depuis les composants optionnels
kubectl apply -f clusters/sandbox/optional/storage/storage.yaml
kubectl -n kubocd-system wait --for=jsonpath='{.status.phase}'=READY release/storage --timeout=10m
# Installation de la stack data de démonstration
kubectl apply -f clusters/sandbox/project-demo/00-namespace.yaml
kubectl apply -f clusters/sandbox/project-demo/10-secrets.yaml
kubectl -n demo wait --for=jsonpath='{.status.phase}'=READY release/demo-secrets --timeout=5m
kubectl apply -f clusters/sandbox/project-demo/20-storage-demo.yaml
kubectl -n kubocd-system wait --for=jsonpath='{.status.phase}'=READY release/storage --timeout=10m
kubectl apply -f clusters/sandbox/project-demo/30-postgres.yaml
kubectl -n demo wait --for=condition=Ready cluster/demo-pg --timeout=10m
kubectl -n demo wait --for=jsonpath='{.status.applied}'=true \
        database/demo-pg-hive database/demo-pg-superset database/demo-pg-superset-examples database/demo-pg-polaris database/demo-pg-airflow \
        --timeout=10m
kubectl apply -f clusters/sandbox/project-demo/40-connections.yaml
kubectl -n demo wait --for=jsonpath='{.status.phase}'=READY \
         connection/demo-db-hive connection/demo-db-superset connection/demo-db-superset-examples connection/demo-db-polaris connection/demo-db-airflow connection/demo-storage \
        --timeout=10m
kubectl apply -f clusters/sandbox/project-demo/50-services.yaml
kubectl -n demo wait --for=jsonpath='{.status.phase}'=READY release -l okdp.io/project=demo --timeout=30m
kubectl apply -f clusters/sandbox/project-demo/60-polaris-catalog-job.yaml
kubectl -n demo wait --for=condition=complete job/demo-polaris-catalog --timeout=10m

Le déploiement du projet de démonstration provisionne les services Airflow, Hive Metastore, JupyterHub, Polaris, Spark History Server, Superset et Trino dans le cluster OKDP. Une fois déployé, l’interface fournit un tableau de bord pour surveiller l’état des services, l’utilisation CPU et la consommation mémoire.

En sélectionnant un composant depuis le tableau de bord, une vue détaillée du service s’ouvre, avec des liens directs vers les pods du service et l’URL du service le cas échéant.

Enfin, le sandbox inclut un pipeline de traitement de données de bout en bout, explorable en lançant une instance JupyterHub et en utilisant les notebooks okdp-examples pour construire un data lakehouse à partir des données de taxis new-yorkais.

Nettoyage

Après la démonstration, arrêter le conteneur Docker du cluster permet de conserver le déploiement intact, permettant de reprendre la démonstration ultérieurement sans répéter les étapes d’installation.

# Arrêt du conteneur en conservant l'état pour une utilisation ultérieure
docker stop okdp-sandbox-control-plane
# Redémarrage du cluster
# docker start okdp-sandbox-control-plane

Une suppression complète peut être effectuée une fois l’exploration d’OKDP terminée.

# Suppression du cluster
kind delete cluster --name okdp-sandbox
# Suppression de okdp-sandbox.conf de systemd-resolved et redémarrage
rm /etc/systemd/resolved.conf.d/okdp-sandbox.conf
sudo systemctl restart systemd-resolved

Enfin, si le certificat CA a été importé dans Firefox, supprimez-le en retournant dans about:preferences, en recherchant certificates puis manage certificates. Une fois la boîte de dialogue ouverte, cliquez sur le champ Certificate Name et saisissez OKDP pour localiser rapidement le CA. Sélectionnez-le et choisissez l’option Delete or Distrust pour le supprimer du navigateur.

Conclusion

Dans ce guide, nous avons déployé une plateforme data locale entièrement fonctionnelle avec OKDP, en couvrant l’initialisation du cluster, la configuration DNS et SSL, le déploiement des composants, et une première prise en main de l’interface sandbox. La release 1.0 est prévue le 14 septembre 2026. Le TOSIT accueille activement les contributions et l’engagement de la communauté. Si le projet vous intéresse, n’hésitez pas à nous contacter et à nous rejoindre lors de la réunion hebdomadaire.

Partagez cet article