Lightdash en production : déploiement Kubernetes

La configuration Docker Compose fonctionne bien pour l’évaluation et les petites équipes. Quand vous êtes prêt pour la production — accès multi-utilisateurs, planification fiable, scaling horizontal et infrastructure managée — Kubernetes avec le Helm chart communautaire est la voie à suivre.

Le Helm chart est maintenu par la communauté (pas officiellement par Lightdash). C’est important à savoir : il peut prendre du retard sur les releases Lightdash, et les problèmes sont résolus par les contributeurs plutôt que directement par l’équipe Lightdash. En pratique, le chart est activement maintenu et largement utilisé.

Installation via Helm

# Add the Lightdash Helm repository
helm repo add lightdash https://lightdash.github.io/helm-charts
helm repo update

# Install with a custom values file
helm install lightdash lightdash/lightdash \
  --namespace lightdash \
  --create-namespace \
  -f values.yaml

Commencez avec le fichier values par défaut du dépôt du chart et surchargez ce dont vous avez besoin dans votre propre values.yaml. Ne surchargez pas les valeurs en ligne avec --set pour plus d’une ou deux options — cela devient rapidement difficile à maintenir.

Un values.yaml minimal pour un déploiement en production :

image:
  tag: "latest"  # pin to a specific version in production

replicaCount: 2  # for availability, not load balancing — stateless replicas

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "2Gi"
    cpu: "1000m"

config:
  lightdashSecret: ""  # override via secret, not here
  siteUrl: "https://lightdash.yourdomain.com"
  auth:
    google:
      clientId: ""      # from secret
      clientSecret: ""  # from secret

postgresql:
  enabled: false  # use external PostgreSQL

externalDatabase:
  host: "your-managed-postgres-host"
  port: 5432
  user: "lightdash"
  database: "lightdash"
  existingSecret: "lightdash-db-secret"
  existingSecretPasswordKey: "password"

browserless:
  enabled: true

scheduler:
  enabled: true

Les valeurs sensibles (LIGHTDASH_SECRET, identifiants de base de données, identifiants OAuth) doivent vivre dans des Secrets Kubernetes, pas dans values.yaml. Référencez-les via existingSecret là où le chart le supporte, ou montez-les comme variables d’environnement depuis des ressources secret.

Checklist de production

PostgreSQL externe

Ne lancez pas PostgreSQL comme conteneur dans un déploiement Kubernetes en production. Utilisez un service de base de données managé : Cloud SQL (GCP), RDS (AWS), Azure Database for PostgreSQL. Les bases de données managées vous donnent :

Des sauvegardes automatisées
Une récupération point-in-time
Un basculement sans intervention manuelle
Aucun risque de perdre l’état de l’application lors du redémarrage d’un pod

Activez l’extension uuid-ossp dans votre base de données managée avant le premier démarrage de Lightdash. Sur Cloud SQL, cela nécessite une connexion superutilisateur ou un utilisateur Cloud SQL Admin.

Stockage objet compatible S3

Lightdash en production nécessite un stockage objet pour :

Les exports CSV (Cloud Pro uniquement, mais le bucket est configuré au niveau infrastructure)
Les exports ZIP de dashboards
Les images de graphiques utilisées dans les livraisons Slack et email

Configurez avec n’importe quel service compatible S3 : AWS S3, Google Cloud Storage (avec l’API de compatibilité S3 activée), MinIO pour les déploiements on-premises.

Dans values.yaml :

config:
  s3:
    endpoint: ""  # leave empty for AWS, set for GCS or MinIO
    accessKey: ""  # from secret
    secretKey: ""  # from secret
    bucket: "lightdash-prod"
    region: "eu-west-1"

Pour GCS, activez l’API d’interopérabilité compatible S3 dans votre projet GCP et utilisez des clés HMAC (pas des clés de compte de service) pour la paire clé d’accès/clé secrète.

HTTPS

Lightdash doit être servi en HTTPS en production. Deux approches courantes dans Kubernetes :

Load balancer avec TLS managé : Le load balancer de votre fournisseur cloud (GCP HTTPS Load Balancer, AWS ALB) termine le TLS. Lightdash reçoit du HTTP simple depuis le load balancer. Définissez TRUST_PROXY=true pour que Lightdash fasse confiance au header X-Forwarded-Proto.

Ingress controller avec cert-manager : Un nginx Ingress controller avec cert-manager gère la terminaison TLS dans le cluster. cert-manager automatise le provisionnement et le renouvellement des certificats Let’s Encrypt.

Les deux approches fonctionnent. Le chemin load balancer est plus simple si vous êtes déjà sur un service Kubernetes managé avec des load balancers cloud.

SMTP pour la planification email

La planification basée sur email nécessite un serveur SMTP :

config:
  smtp:
    host: "smtp.sendgrid.net"
    port: 587
    secure: false
    starttls: true
    auth:
      user: "apikey"
      pass: ""  # from secret
    from:
      name: "Lightdash"
      email: "lightdash@yourdomain.com"

Tout fournisseur SMTP fonctionne : SendGrid, Postmark, SES, ou un serveur mail auto-hébergé. SendGrid est le choix le plus courant pour les organisations déjà sur AWS ou GCP.

Authentification à l’échelle Kubernetes

Les options d’authentification sont identiques à Docker Compose, mais à l’échelle Kubernetes les limites de tier importent davantage :

Méthode d’auth	Tier requis
Google OAuth	Open Source (gratuit)
Okta (OIDC)	Cloud Pro (2 400 $/mois)
Azure AD	Enterprise
OIDC générique	Enterprise
SAML	Enterprise
Provisionnement SCIM 2.0	Enterprise

Si votre organisation exige le SSO via autre chose que Google, vous n’utilisez pas réellement la version auto-hébergée gratuite — vous payez pour Cloud Pro ou Enterprise, et à ce stade l’offre Lightdash Cloud hébergée vaut la peine d’être comparée au coût infrastructure de gérer votre propre cluster Kubernetes.

Pour les organisations utilisant Google Workspace et pouvant utiliser Google OAuth, le tier open-source avec Kubernetes couvre la plupart des cas d’usage de production.

Stratégie de mise à jour

Lightdash sort à un rythme soutenu — plusieurs releases par semaine. Chaque mise à jour peut inclure des migrations de base de données. Un pattern de mise à jour sûr :

Épinglez votre tag d’image dans values.yaml plutôt que d’utiliser latest. Consultez le changelog avant de changer de version.
Effectuez les mises à jour pendant les fenêtres de faible trafic. Les migrations de base de données s’exécutent au démarrage du pod et peuvent maintenir des verrous pendant quelques secondes à quelques minutes.
Surveillez les migrations de base de données. Vérifiez les logs de démarrage des pods immédiatement après la mise à jour. Une migration échouée laisse la base de données dans un état partiel.
Gardez un replica actif pendant les mises à jour progressives si vous utilisez replicaCount: 2. Kubernetes le gère par défaut avec une stratégie de rolling update, mais vérifiez votre configuration strategy :

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

maxUnavailable: 0 garantit qu’au moins un pod répond toujours aux requêtes pendant la mise à jour.

Problèmes connus spécifiques à Kubernetes

Le problème de rendu du formulaire de connexion (GitHub #10135) affecte certains déploiements Kubernetes — la page de connexion s’affiche sans les champs de saisie visibles. Cela est généralement causé par une configuration incorrecte de SITE_URL ou un paramètre TRUST_PROXY=true manquant. Vérifiez les deux dans votre configuration avant d’approfondir le débogage.

La contention de verrou lors des migrations de base de données est plus visible dans Kubernetes que dans Docker Compose car Kubernetes peut lancer un nouveau pod avant que l’ancien se termine complètement. La combinaison de deux pods tentant tous deux d’exécuter des migrations au démarrage peut provoquer des timeouts de verrou. Surveillez les logs de migration du premier pod à terminer le démarrage avant de mettre à l’échelle les replicas.

Comparaison des coûts : auto-hébergé vs Cloud Pro

Exécuter Lightdash sur Kubernetes pour une équipe de taille moyenne nécessite :

Une instance PostgreSQL managée (~50-100 $/mois)
Des nœuds de cluster GKE/EKS/AKS capables d’exécuter les pods Lightdash (~100-200 $/mois pour un petit cluster)
Stockage objet et SMTP (coût minimal)
Du temps ingénierie pour gérer les mises à jour, surveiller les déploiements et résoudre les problèmes

Le tier Lightdash Cloud Pro coûte 2 400 $/mois avec des utilisateurs illimités et inclut des fonctionnalités non disponibles en open source : planification, exports CSV, caching, fonctionnalités IA, support prioritaire. L’auto-hébergement Kubernetes est rentable quand une infrastructure Kubernetes existante est en place, que l’équipe a la capacité opérationnelle, et que les limites des fonctionnalités open-source ne bloquent pas les cas d’usage.

Voir bi-tool-self-hosting-licensing pour la comparaison complète des fonctionnalités par tier.