Adoptez Kubernetes : Un guide complet pour votre entreprise
Introduction
Kubernetes est au cœur de mon quotidien depuis plus de 8 ans. J'ai déployé et géré des clusters sur tous les cloud providers majeurs : OVH (KNDS, Metronome), GKE (Okeiro, Earny SA), EKS (F2R2, TEKYN, Coopengo), Azure AKS (Cardiologs), et même du bare-metal. Si vous hésitez encore à franchir le pas, voici un guide pragmatique basé sur mon expérience terrain.
Quand Kubernetes est-il pertinent ?
Kubernetes n'est pas la réponse à tout. Pour un monolithe avec 3 développeurs, un simple docker-compose sur une VM suffit. Kubernetes devient pertinent quand vous avez au moins 5 services, que vous devez scaler indépendamment, ou que vous avez besoin de haute disponibilité. Chez Coopengo, la migration vers Kubernetes était justifiée par 15 microservices avec des besoins de scaling très différents : le service de facturation avait des pics à la fin du mois, le service d'import de données était CPU-intensif la nuit. Kubernetes permettait de scaler chaque service indépendamment, optimisant les ressources et réduisant la facture AWS de 25% par rapport à l'approche "tout surdimensionner".
Managed Kubernetes vs self-managed : le choix pragmatique
En 2024, gérer soi-même le control plane Kubernetes n'a plus de sens sauf cas très spécifiques (air-gap, souveraineté absolue). J'utilise systématiquement des offres managed : EKS, GKE, OVH Managed Kubernetes. Chez Okeiro dans le secteur e-santé HDS, nous avons choisi GKE Autopilot sur le cloud souverain S3NS. Le control plane est géré par Google, les nodes sont provisionnés automatiquement selon la charge, et la factification se fait au pod plutôt qu'au node. Cette approche a réduit de 40% le coût d'infrastructure par rapport à un cluster GKE standard avec des nodes fixes. Chez KNDS, le choix d'OVH Managed Kubernetes répondait à une exigence de souveraineté française pour le secteur défense.
L'architecture réseau et la sécurité
La sécurité réseau sur Kubernetes est souvent le parent pauvre des déploiements initiaux. Chez KNDS, j'ai implémenté des NetworkPolicies strictes : chaque namespace ne pouvait communiquer qu'avec les namespaces explicitement autorisés. Les pods avaient des profils seccomp restrictifs et le RBAC était configuré finement par équipe. Cette approche "deny by default" a satisfait les exigences de sécurité du secteur défense. Sur un projet moins contraint comme Metronome, j'ai commencé par des NetworkPolicies plus permissives avant de les resserrer progressivement, en monitorant les flux avec Cilium Hubble pour identifier les communications réelles entre services.
Le stockage et les bases de données
Un conseil que je donne systématiquement : ne mettez pas vos bases de données dans Kubernetes, sauf si vous savez exactement ce que vous faites. Chez F2R2, les bases Aurora PostgreSQL étaient gérées en dehors du cluster EKS, provisionnées par Terraform. Les applications dans Kubernetes se connectaient via des endpoints de service. Chez Cardiologs, les performances de PostgreSQL étaient critiques pour le traitement des électrocardiogrammes. Nous avons opté pour des instances RDS dédiées avec des IOPS provisionnés, monitorés par Datadog. Le stockage dans Kubernetes (PersistentVolumes) est adapté pour les caches, les files d'attente, mais les bases de données de production méritent un service managé avec des backups et de la réplication gérés par le cloud provider.
L'observabilité dès le jour 1
Ne déployez jamais un cluster Kubernetes sans observabilité. Chez Metronome, j'ai installé le stack Grafana/Prometheus/Loki dès le premier jour, avant même de déployer la première application. Les métriques Kubernetes (utilisation CPU/mémoire des pods, état des deployments, latence des requêtes) étaient visibles immédiatement. Chez Bloomflow, avec OpenTelemetry, nous avions des traces distribuées qui suivaient une requête du frontend jusqu'à la base de données en passant par 5 microservices. Cette observabilité native de Kubernetes a permis de diagnostiquer un memory leak en 20 minutes au lieu des heures habituelles. L'investissement en observabilité se rembourse dès le premier incident.
Conclusion
Kubernetes est un outil puissant qui requiert un investissement initial en compétences et en infrastructure. Mais une fois maîtrisé, il offre une flexibilité et une fiabilité inégalées. Mon conseil : commencez par un managed Kubernetes, déployez l'observabilité en premier, sécurisez le réseau dès le départ, et gardez vos bases de données hors du cluster. Ces principes, validés sur des dizaines de clusters en production, vous éviteront les écueils classiques.