Optimisation des Déploiements avec Kubernetes et Terraform

Introduction

Terraform et Kubernetes sont les deux piliers de mon quotidien. L'un provisionne l'infrastructure (reseau, cluster, bases de donnees), l'autre gere les applications. Leur combinaison forme un tandem puissant mais qui demande une architecture claire pour eviter les pieges. Apres l'avoir deploye chez F2R2, Bloomflow, TEKYN, Earny SA et sur wizops.fr, voici les patterns qui fonctionnent et ceux qui ne fonctionnent pas.

Terraform : du code au cluster en 15 minutes

Le module EKS que j'ai concu chez F2R2 illustre la puissance de Terraform pour le provisionning. Un terraform apply cree un cluster EKS Fargate complet : Fargate profiles par namespace (system, monitoring, applications), IAM roles IRSA (IAM Roles for Service Accounts) pour chaque service, security groups avec des regles strictes, et les addons managés (CoreDNS, kube-proxy, VPC CNI). Le tout en 15 minutes.

Chez Earny SA, lors de la migration GCP vers AWS, Terraform a ete l'outil qui a rendu la migration realiste. J'ai recree l'infrastructure GCP en Terraform AWS en 3 jours : VPC, EKS, RDS PostgreSQL, ElastiCache Redis, et les IAM roles. Sans Terraform, cette recreation manuelle aurait pris 2 a 3 semaines, avec le risque d'oublier un parametre de securite ou de configuration.

Pour WizOps, Terraform provisionne l'infrastructure Scaleway (cluster Kubernetes managé, DNS, registre d'images), et les Helm Charts dans le repo wizops_charts deploient frontend et backend avec un Ingress NGINX et cert-manager.

Helm : l'abstraction applicative

Une fois le cluster provisionne par Terraform, Helm deploie les applications. La separation est nette : Terraform gere ce qui est "en dessous" du cluster, Helm gere ce qui est "a l'interieur".

Chez Bloomflow, le Helm Chart "maison" etait un template generique parametrable pour chaque microservice. Chaque service avait son fichier values-<service>.yaml qui definissait : nombre de replicas, requests et limits de ressources, endpoints de probes, routes d'Ingress, et variables d'environnement. Deployer un nouveau microservice se reduisait a creer un fichier values et a l'enregistrer dans ArgoCD. Temps : 10 minutes, sans toucher au code du chart.

Chez Okeiro, j'ai developpe un Helm Chart specifique pour le serveur FHIR (standard e-sante). La particularite : l'integration de Workload Identity GCP. Le chart annotait le ServiceAccount Kubernetes avec l'adresse du service account GCP, permettant aux pods d'acceder aux ressources GCP (Cloud Storage, BigQuery) sans credentials statiques. Le pod recevait un token ephemere via l'API GKE, renouvele automatiquement. Zero secret a gerer, zero rotation de cles.

La separation des repos : une regle non negociable

Le pattern que j'applique systematiquement : separer le repo Terraform (infrastructure) du repo Helm/ArgoCD (applications). Chez F2R2, le repo infra contenait les modules Terraform, et le repo apps contenait les Helm Charts et les manifestes ArgoCD.

Pourquoi cette separation est critique :

• Cycles de vie differents : l'infrastructure change quelques fois par mois, les applications changent plusieurs fois par jour. Les pipelines CI/CD sont distincts.
• Permissions differentes : les equipes infra ont acces au repo Terraform, les equipes dev au repo Helm. Pas de risque qu'un developpeur modifie accidentellement un module VPC.
• Reviews independantes : un changement Terraform (qui peut supprimer des ressources) est revue par un SRE senior. Un changement de values Helm (qui modifie un deploiement) est revue par le lead tech.
• ArgoCD ne surveille que le repo apps : pas de risque de conflit entre la reconciliation ArgoCD et le state Terraform.

State Terraform : le talon d'Achille a proteger

Le state Terraform est le fichier le plus critique de votre infrastructure. Il contient la correspondance entre les ressources declarees dans le code et les ressources reelles dans le cloud. Une corruption du state, c'est potentiellement un terraform destroy involontaire.

Chez Bloomflow, le state etait stocke dans un bucket S3 avec DynamoDB pour le locking. Configuration critique :

• Versionning S3 active : chaque modification du state cree une nouvelle version, permettant un rollback en cas de corruption
• Chiffrement SSE-S3 : le state contient des informations sensibles (ARN de ressources, endpoints de bases de donnees)
• DynamoDB lock : empeche deux terraform apply simultanees qui corrompraient le state
• State lock timeout de 10 minutes : chez F2R2, j'ai ajoute un timeout pour eviter les locks orphelins (quand un terraform apply est interrompu brutalement)

Le terraform plan etait automatiquement affiche dans les pull requests GitHub via un job GitHub Actions. Le reviewer voyait exactement quelles ressources seraient creees, modifiees ou detruites avant d'approuver le merge. Cette review visuelle a evite au moins deux suppressions accidentelles de bases de donnees chez Bloomflow.

Les pieges du tandem K8s + Terraform

Piege 1 : gerer les ressources K8s avec le provider Terraform Kubernetes. C'est tentant (tout dans un seul outil) mais problematique. Les cycles de vie sont differents : Terraform veut gerer l'etat complet de la ressource, ArgoCD aussi. Les deux entrent en conflit. Et un terraform destroy peut supprimer des Deployments applicatifs. Ma regle : Terraform gere l'infra (VPC, cluster, bases de donnees), Helm/ArgoCD gere les workloads.

Piege 2 : le drift. Si quelqu'un modifie une ressource dans la console AWS (par urgence, par paresse), le state Terraform diverge de la realite. Au prochain terraform apply, Terraform essaie de reconcilier, ce qui peut casser des choses. Chez Bloomflow, j'avais configure un terraform plan quotidien dans la CI qui alertait sur Discord en cas de drift detecte. Cette detection precoce a evite plusieurs incidents lies a des modifications manuelles non documentees.

Conclusion

Kubernetes et Terraform sont complementaires, pas concurrents. Terraform cree le terrain de jeu, Kubernetes y fait tourner les applications. Cette separation claire des responsabilites, materialisee par des repos distincts et des pipelines independants, produit des deploiements fiables et reproductibles. Le state Terraform est le point nevralgique a proteger avec un backend distant, du locking et du versionning. C'est l'architecture que je recommande systematiquement a chaque client.