Optimiser le déploiement avec Kubernetes et Terraform
Introduction
Kubernetes et Terraform sont mes deux outils quotidiens depuis des années. Le premier orchestre les applications conteneurisées, le second provisionne l'infrastructure cloud qui les héberge. Ensemble, ils forment un tandem que j'ai déployé chez F2R2, Bloomflow, KNDS, Earny SA, Okeiro et sur mes propres produits (WizOps, WizStatus, MongoAdmin). Voici comment j'optimise leur utilisation conjointe pour réduire les coûts, accélérer les déploiements et garantir la reproductibilité.
La séparation nette : Terraform provisionne, Kubernetes consomme
Le pattern que j'applique systématiquement depuis 5 ans : Terraform crée le cluster Kubernetes et toutes ses dépendances cloud (réseau, DNS, registre d'images, base de données managée, stockage, CDN), puis Kubernetes prend le relais pour les workloads applicatifs via Helm et ArgoCD. Les deux ne se marchent pas sur les pieds.
Chez F2R2, Terraform provisionne l'intégralité de l'infrastructure AWS en 25 modules : VPC avec subnets multi-AZ, cluster EKS Fargate, bases Aurora PostgreSQL, buckets S3 avec lifecycle policies, distributions CloudFront avec WAF, et les IAM roles/policies. Un terraform apply crée un environnement complet en 45 minutes. Chez Bloomflow, le même pattern sur AWS et Outscale (SecNumCloud). Chez Okeiro, sur GCP avec GKE Autopilot et le cloud souverain S3NS. La séparation des responsabilités est toujours la même : Terraform ne gère jamais les Deployments ou les pods, Kubernetes ne crée jamais de VPC ou de base de données managée.
Environnements éphémères : le levier d'économie méconnu
L'optimisation la plus rentable que j'ai implémentée : les environnements éphémères. Chez F2R2, les environnements dev et staging étaient détruits chaque soir à 20h par un cron Terraform (terraform destroy) et recréés le matin à 7h (terraform apply). L'infrastructure ne coûtait rien pendant 11 heures par nuit et le week-end. Economie : environ 40% sur la facture AWS des environnements non-production, soit plusieurs milliers d'euros par an.
Chez Bloomflow, le concept était poussé plus loin avec les environnements de PR. Quand un développeur ouvrait une PR, un pipeline GitHub Actions déclenchait un terraform apply qui créait un namespace Kubernetes dédié avec sa propre base de données PostgreSQL (instance RDS micro). ArgoCD déployait automatiquement l'application dans ce namespace. Le développeur et le product owner testaient la fonctionnalité sur une URL dédiée (pr-42.staging.bloomflow.io). Au merge ou à la fermeture de la PR, terraform destroy nettoyait tout. Le coût marginal d'un environnement de test tendait vers zéro, et chaque PR avait son environnement isolé.
Organisation du state alignée avec les namespaces
Un point d'optimisation rarement documenté : l'alignement entre l'organisation du state Terraform et les namespaces Kubernetes. Mon approche : un state par environnement, un bucket S3 par environnement, une table DynamoDB de locking par environnement. Chez F2R2 : terraform/environments/dev/, terraform/environments/staging/, terraform/environments/prod/, chacun avec son propre backend S3 dans son compte AWS dédié.
Cette organisation a un bénéfice direct : un terraform apply sur l'environnement dev ne peut physiquement pas impacter la production (comptes AWS séparés, states séparés, credentials séparées). Chez Bloomflow, j'utilisais les workspaces Terraform pour une approche similaire mais dans un même compte. L'alignement state/namespace simplifie aussi le debugging : si un pod en namespace production a un problème de connexion à la base de données, je sais exactement que le state Terraform prod contient la ressource Aurora correspondante avec ses endpoints et ses security groups.
Helm via Terraform : un seul outil pour la stack complète
Pour les composants Kubernetes qui relèvent de l'infrastructure (pas de l'applicatif), j'utilise le provider Helm de Terraform. La frontière : tout ce qui doit être présent avant que les développeurs puissent déployer est de l'infrastructure -- ingress controller, cert-manager, External Secrets Operator, stack de monitoring.
Chez KNDS, un seul terraform apply créait le cluster OVH Kubernetes puis installait via le provider Helm : nginx-ingress controller, cert-manager avec le ClusterIssuer pour les certificats TLS automatiques, External Secrets Operator avec la connexion OKMS (le KMS d'OVH Cloud), et la stack complète Prometheus + Grafana + Loki pour l'observabilité. Le résultat : un cluster opérationnel de A à Z en 20 minutes. Chez WizOps.fr, le même pattern sur Scaleway : le Helm Chart déploie le frontend Nuxt et le backend Django, cert-manager gère les certificats, et External Secrets gère les credentials du registre Docker GHCR.
Les chiffres qui prouvent l'optimisation
L'optimisation du tandem K8s + Terraform se mesure concrètement chez chaque client. Chez F2R2 : le temps de provisionnement d'un environnement est passé de 3 jours (configuration manuelle console AWS) à 45 minutes (terraform apply). Chez Bloomflow : le coût cloud a baissé de 33% grâce au rightsizing piloté par les métriques Prometheus et appliqué via les Helm values Terraform. Chez Earny SA : la migration GCP vers AWS a été validée avant exécution grâce au terraform plan qui montrait les 47 ressources à créer, reviewé en réunion technique avec le client, approuvé, puis appliqué. Zero surprise, zero downtime, migration complète en un week-end.
Le gain cumulé sur ma carrière est significatif : en combinant les environnements éphémères (40% d'économie non-prod), le rightsizing Prometheus-driven (33% d'économie compute), et l'automatisation Terraform qui remplace 3 jours de travail manuel par 45 minutes de pipeline, le tandem Kubernetes + Terraform transforme l'infrastructure d'un centre de coût en un avantage compétitif mesurable.
Conclusion
L'optimisation du déploiement avec Kubernetes et Terraform repose sur une séparation claire des responsabilités, des environnements éphémères qui éliminent le gaspillage, une organisation rigoureuse des states alignée avec les namespaces, et l'utilisation du provider Helm pour une stack complète en un seul apply. Ce tandem, que je déploie chez chaque client depuis 5 ans, est la fondation technique de l'offre WizOps.