Optimisation des Déploiements avec Kubernetes et Helm
Introduction
Helm est le gestionnaire de packages de facto pour Kubernetes. Je l'utilise sur tous mes projets Kubernetes sans exception, de WizOps.fr (un chart simple) aux architectures multi-services de Bloomflow (20 charts). Mais entre un chart Helm basique et un chart Helm de production, il y a un monde. Voici les patterns avancés que j'ai développés en mission.
La structure d'un chart Helm de production
Un chart Helm de production contient bien plus que des Deployments et des Services. Sur WizOps.fr, le chart dans wizops_charts/wizops/ inclut : le Deployment avec probes, resources, et securityContext, le Service, l'Ingress NGINX avec TLS cert-manager, les ExternalSecrets pour les credentials Vault, et les annotations de monitoring. Chez Bloomflow, chaque chart incluait en plus : le HPA (Horizontal Pod Autoscaler), le PDB (PodDisruptionBudget), les NetworkPolicies, les ServiceAccounts avec annotations Workload Identity, et un Job de migration de base de données exécuté en pre-upgrade hook. Cette exhaustivité garantit que le helm upgrade déploie un service complet et sécurisé, pas juste un pod.
Les Helm hooks pour les migrations
Les Helm hooks sont un mécanisme puissant pour exécuter des actions avant ou après un déploiement. Chez Coopengo, j'utilisais un pre-upgrade hook pour les migrations de base de données. Le hook lançait un Job Kubernetes qui exécutait python manage.py migrate (Django) et attendait la complétion avant de mettre à jour les pods applicatifs. Si la migration échouait, le déploiement était annulé et les pods restaient sur la version précédente. Chez Okeiro, le Helm chart FHIR que j'ai développé utilisait un post-install hook pour charger les terminologies médicales initiales dans la base. La clé : toujours définir un hook-delete-policy: hook-succeeded pour nettoyer les Jobs réussis et éviter l'accumulation de resources.
Les values files par environnement
La gestion des values par environnement est fondamentale. Mon pattern standard : un values.yaml avec les valeurs par défaut (1 replica, resources minimales, pas d'ingress TLS), et des overrides par environnement : values-staging.yaml (2 replicas, ingress staging), values-production.yaml (3 replicas, ingress production, resources augmentées, HPA activé). ArgoCD applique le bon values file selon l'environnement. Chez F2R2, avec 25 modules sur 4 environnements, cette approche a permis de gérer 100 configurations différentes avec des fichiers values de 20 lignes chacun. La duplication est minimale, et les différences entre environnements sont explicites et reviewables dans Git.
La migration de Helm v2 à v3
Chez Coopengo, j'ai mené la migration de Helm v2 à v3, un chantier non trivial. Helm v2 utilisait Tiller, un composant serveur installé dans le cluster avec des permissions cluster-admin (un cauchemar de sécurité). Helm v3 supprime Tiller et utilise les credentials kubectl du client. La migration a nécessité : l'export de toutes les releases Helm v2, la conversion des secrets de release au format v3 via helm-2to3, la validation que chaque chart fonctionnait avec v3 (les API deprecated dans v3 devaient être mises à jour), et la suppression de Tiller. Le tout sans interruption de service. La migration a pris 2 jours de préparation et 4 heures d'exécution. Le gain : une sécurité renforcée et une architecture simplifiée.
Les chart dependencies et le umbrella chart
Pour les architectures complexes, le pattern "umbrella chart" regroupe tous les services d'une application sous un seul chart parent. Chez Metronome, l'umbrella chart contenait le frontend, le backend API, le worker, Redis, et le stack de monitoring (Prometheus, Grafana, Loki). Chaque sous-chart était un chart Helm indépendant, réutilisable seul. L'umbrella chart définissait les dépendances et les valeurs globales (nom de domaine, registry). Un seul helm upgrade wizops-stack déployait ou mettait à jour l'ensemble. Attention cependant : l'umbrella chart couple les cycles de déploiement des services. Chez Bloomflow, j'ai finalement découplé les charts pour permettre des déploiements indépendants via ArgoCD, ce qui est plus flexible pour les équipes.
Conclusion
Helm est bien plus qu'un outil de templating YAML. Utilisé correctement, il encapsule toute la complexité d'un déploiement Kubernetes en un package versionné, configurable et reproductible. Les patterns avancés (hooks de migration, values par environnement, umbrella charts) transforment le déploiement d'une opération complexe en une commande unique. La migration vers Helm v3 et l'intégration avec ArgoCD complètent le tableau pour un GitOps fluide et sécurisé.