Optimisation DevOps avec Terraform et Kubernetes
Introduction
Terraform et Kubernetes sont les deux faces de la meme pièce : Terraform provisionne l'infrastructure, Kubernetes déploie les applications dessus. Chez F2R2, cette combinaison gère une architecture AWS Multi-Compte complète avec 25 modules Terraform et EKS Fargate. Voici comment optimiser cette synergie.
Terraform : Infrastructure as Code multi-cloud
Terraform est mon outil de référence pour le provisionning cloud depuis 5 ans. Chez F2R2, les 25 modules couvrent tout : VPC (subnets publics/privés, NAT Gateway), EKS Fargate (cluster, node groups, IRSA), Aurora PostgreSQL (instances, parameter groups, backups), sécurité (WAF, GuardDuty, IAM policies). Chez Bloomflow, les memes patterns Terraform fonctionnaient sur AWS et Outscale SecNumCloud avec des modifications minimales du provider. La portabilité multi-cloud de Terraform est réelle : le code HCL reste le meme, seuls les providers et quelques spécificités changent. Le state sur S3 avec DynamoDB locking garantit la cohérence meme avec plusieurs ingénieurs.
Kubernetes : l'orchestrateur universel
Kubernetes est déployé par Terraform et gère les applications. Chez F2R2, EKS Fargate élimine la gestion des nodes — on ne paie que les pods. Chez KNDS sur OVH Cloud, les clusters Kubernetes sont provisionnés par Terraform et sécurisés avec NetworkPolicies et RBAC. Chez Okeiro, GKE Autopilot sur le cloud souverain S3NS offre le meme confort serverless. L'avantage de laisser Terraform gérer le cluster : reproductibilité totale. Un terraform apply et le cluster est recréé a l'identique. Les add-ons (Ingress NGINX, cert-manager, ArgoCD, Prometheus) sont aussi déployés par Terraform ou par ArgoCD en bootstrapping.
L'intégration Terraform + Kubernetes en pipeline
Chez F2R2, le pipeline GitHub Actions séparait deux phases : d'abord Terraform pour les changements d'infrastructure, puis ArgoCD pour les déploiements applicatifs. Le terraform plan dans la PR montrait les changements d'infra, l'équipe validait, et le merge déclenchait l'apply. Coté applicatif, GitHub Actions buildait les images Docker et mettait a jour les tags dans les Helm values — ArgoCD détectait le changement et déployait. Chez Bloomflow, cette séparation permettait a l'équipe infra de travailler sur Terraform sans impacter les développeurs qui poussaient des changements applicatifs en continu.
CI/CD et automatisation complète
L'automatisation va au-dela du simple déploiement. Chez F2R2, les GitHub Actions incluaient terraform validate, tflint, checkov (scan de sécurité) dans chaque PR Terraform. Coté Kubernetes, helm lint et helm template validaient les charts avant déploiement. Chez Coopengo, les Jenkins Spot instances réduisaient les couts CI de 30%. Sur WizOps.fr, le pipeline complet (tests + build Docker + push GHCR + déploiement Scaleway) tourne en moins de 6 minutes. L'audit AWS chez F2R2 a montré que l'automatisation Terraform éliminait les configurations manuelles via console — source de 35% des incidents chez ce client avant mon intervention.
Surveillance et performance continue
La surveillance est le dernier maillon de la chaine. Chez Metronome, Terraform provisionnait les ressources de monitoring (instances Prometheus, stockage Loki) et Kubernetes déployait les applications de surveillance. Les dashboards Grafana montraient les métriques de l'infrastructure Terraform (nombre d'instances, couts) et des applications Kubernetes (CPU, mémoire, latence). Chez F2R2, GuardDuty (provisionné par Terraform) surveillait les menaces au niveau AWS, tandis que Prometheus (déployé sur Kubernetes) surveillait les applications. Cette vision unifiée infrastructure + applicatif est essentielle pour une opération saine.
Conclusion
Terraform et Kubernetes forment le socle de l'infrastructure cloud moderne. Terraform pour le "quoi" (quelles ressources existent), Kubernetes pour le "comment" (comment les applications tournent). Cette combinaison, je l'ai éprouvée sur AWS (F2R2, TEKYN, Earny SA), GCP (Okeiro), OVH (KNDS, Metronome), Outscale (Bloomflow) et Scaleway (WizOps.fr). Le pattern est universel, seul le contexte change.