Kubernetes en production : retour d'expérience après 3 ans

Kubernetes : la promesse vs la réalité

Kubernetes est partout. Chaque conf tech en parle, chaque éditeur le supporte, chaque recruteur le cherche sur les CV. Après 3 ans à opérer des clusters K8s en production sur des projets e-commerce et SaaS, voici ce qu’on a appris. Sans filtre.

La promesse de Kubernetes est séduisante : orchestration automatique, scaling horizontal, déploiements zero-downtime, portabilité multi-cloud. La réalité est plus nuancée. K8s résout des problèmes réels, mais il en crée d’autres. La question n’est pas “faut-il utiliser Kubernetes ?” mais “est-ce que votre contexte justifie sa complexité ?”.

Ce qui fonctionne vraiment bien

Le scaling automatique

C’est le cas d’usage roi. Sur un site e-commerce avec des pics de trafic (Black Friday, ventes flash), le Horizontal Pod Autoscaler combiné au Cluster Autoscaler fait le travail. On passe de 5 pods à 50 en quelques minutes, puis on redescend. Sans intervention humaine.

Sur un de nos projets SaaS, le HPA réagit aux métriques custom (files d’attente, latence P99). Le résultat : une facture cloud qui suit la charge, pas un provisionnement statique surdimensionné.

La résilience native

Les health checks (liveness, readiness, startup probes) combinés aux PodDisruptionBudgets donnent une résilience qu’il est difficile d’atteindre autrement. Un pod crash ? Kubernetes le relance. Un noeud tombe ? Les pods migrent. Une mise à jour ? Le rolling update garantit zéro interruption.

En 3 ans, on a eu exactement zéro downtime lié à l’infrastructure K8s elle-même. Les incidents venaient toujours du code applicatif ou de dépendances externes.

Les déploiements maîtrisés

Le combo GitOps (ArgoCD ou Flux) + Kubernetes est redoutable. Chaque déploiement est versionné, auditable, rollbackable. Le kubectl rollout undo a sauvé plusieurs mises en production. Les canary deployments avec Istio ou Flagger permettent de valider en conditions réelles avant de basculer 100% du trafic.

L’écosystème

L’écosystème Kubernetes est son atout majeur. Helm pour le packaging, Kustomize pour la configuration, cert-manager pour les certificats TLS, external-dns pour le DNS automatique, sealed-secrets pour la gestion des secrets en GitOps. Chaque problème d’infrastructure a un opérateur Kubernetes.

Ce qui coûte cher (et pas que financièrement)

La courbe d’apprentissage

Kubernetes n’est pas un outil, c’est un écosystème complet. Pour être opérationnel, une équipe doit maîtriser : les concepts K8s (pods, services, ingress, namespaces, RBAC), le networking (CNI, service mesh), le stockage (PV, PVC, StorageClass), le monitoring, le CI/CD GitOps, et la sécurité.

Comptez 3 à 6 mois pour qu’un développeur expérimenté devienne autonome sur K8s. Et 12 mois pour qu’il soit capable de débuguer les problèmes réseau ou de stockage complexes.

La complexité opérationnelle

Un cluster Kubernetes en production, ce n’est pas juste kubectl apply. C’est :

• Des mises à jour régulières du cluster (4 versions mineures par an)
• La gestion des certificats et de leur rotation
• Le monitoring du cluster lui-même (pas juste des applications)
• Les backups etcd et les plans de disaster recovery
• La gestion des node pools et de leur cycle de vie
• La sécurité : network policies, pod security standards, RBAC

Chaque couche ajoute de la complexité. Et chaque couche peut casser.

Le coût humain

Un cluster K8s en production nécessite au minimum 2 personnes ayant une expertise solide. En dessous, vous avez un single point of failure humain. Quand votre expert K8s part en vacances ou quitte l’entreprise, vous avez un problème.

La question n’est pas combien coûtent les VMs du cluster, c’est combien coûtent les ingénieurs pour l’opérer.

Managed vs self-hosted : le vrai débat

Managed (GKE, EKS, AKS)

C’est le choix par défaut en 2026. Le control plane est géré par le cloud provider, les mises à jour sont simplifiées, l’intégration avec les services natifs (IAM, monitoring, networking) est fluide.

GKE reste notre recommandation. L’Autopilot mode pousse la logique encore plus loin : vous ne gérez plus les noeuds, uniquement les workloads. La facturation est au pod, pas au noeud.

EKS est solide mais demande plus de configuration. Chaque composant (CNI, CSI, load balancer controller) est un add-on séparé.

Self-hosted

On l’a fait. On ne le recommande plus sauf cas très spécifiques (contraintes réglementaires, air-gapped, edge computing). Le coût d’opération d’un cluster self-hosted est 3 à 5 fois supérieur au surcoût d’un managed.

Notre stack de monitoring

Après avoir testé plusieurs combinaisons, voici notre stack stabilisée :

• Prometheus + Grafana pour les métriques infrastructure et applicatives
• Loki pour les logs (remplace l’ELK stack, beaucoup plus léger)
• Tempo pour les traces distribuées
• Alertmanager avec des alertes basées sur les SLOs, pas sur les seuils arbitraires

Pour les projets avec un budget monitoring dédié, Datadog simplifie tout. Un seul agent, une seule interface, corrélation automatique entre métriques, logs et traces. Le prix est élevé, mais le gain de temps opérationnel est réel.

Les alertes qui fonctionnent

On a appris une leçon importante : les alertes basées sur des seuils fixes (CPU > 80%, mémoire > 90%) génèrent du bruit. Les alertes basées sur les SLOs (taux d’erreur, latence P99, disponibilité) détectent les vrais problèmes.

Notre règle : chaque alerte doit être actionnable. Si personne ne sait quoi faire quand elle se déclenche, elle n’a pas sa place.

Patterns de sécurité essentiels

Le principe du moindre privilège

• RBAC granulaire : chaque namespace a ses propres ServiceAccounts avec des droits minimaux
• Network Policies : par défaut, aucun pod ne communique avec un autre. On ouvre explicitement
• Pod Security Standards : le mode restricted est le défaut, baseline quand nécessaire

La supply chain

• Scan des images avec Trivy dans le CI/CD
• Registre privé avec signature d’images (Cosign)
• Admission controllers (Kyverno ou OPA Gatekeeper) pour refuser les images non signées ou avec des CVE critiques

Les secrets

Les Kubernetes Secrets en base64, ce n’est pas de la sécurité. On utilise External Secrets Operator connecté à Google Secret Manager ou AWS Secrets Manager. Les secrets ne sont jamais dans Git, même chiffrés.

Optimisation des coûts

Right-sizing des pods

80% des pods qu’on audite sont surdimensionnés. Un pod qui demande 1 CPU et 2 Go de RAM mais qui utilise 0.1 CPU et 200 Mo, c’est de l’argent jeté par la fenêtre.

L’outil VPA (Vertical Pod Autoscaler) en mode recommandation donne des suggestions précises. On l’utilise systématiquement sur les nouveaux projets.

Spot instances / Preemptible VMs

Pour les workloads tolérants aux interruptions (jobs batch, workers asynchrones, environnements de dev), les spot instances réduisent la facture de 60 à 80%. Le trick : combiner plusieurs types d’instances et zones de disponibilité pour limiter les interruptions.

Namespaces de dev éphémères

Chaque feature branch crée un namespace avec un TTL de 48h. Plus de clusters de dev permanents qui tournent le weekend. L’économie est significative.

Quand Kubernetes est overkill

Soyons honnêtes. K8s est overkill quand :

• Votre application est un monolithe avec peu de trafic
• Votre équipe a moins de 5 développeurs
• Vous n’avez pas de besoin de scaling dynamique
• Votre budget ne permet pas 2 profils DevOps/SRE

Dans ces cas, un PaaS (Cloud Run, App Engine, Railway, Fly.io) ou même un simple serveur avec Docker Compose fait le travail. Moins sexy, plus pragmatique.

Ce qu’on ferait différemment

Si on recommencait de zéro :

1. GitOps dès le jour 1 — On a commencé avec des kubectl apply manuels. Erreur. ArgoCD ou Flux dès le premier cluster.
2. Moins de YAML, plus d’abstraction — Helm est verbeux. On migre progressivement vers cdk8s (TypeScript) pour générer les manifests.
3. Platform engineering — Construire une Internal Developer Platform avec Backstage ou Port pour que les devs ne touchent jamais à K8s directement.
4. FinOps intégré — Kubecost ou OpenCost installé dès le premier jour pour suivre les coûts par équipe et par service.

Le mot de la fin

Kubernetes est un outil puissant. Mais c’est un outil complexe qui demande de l’investissement. La question à se poser n’est pas technique, elle est organisationnelle : avez-vous les compétences, le budget et le besoin réel pour justifier cette complexité ?

Si la réponse est oui, K8s en managed avec une approche GitOps et un investissement sérieux en observabilité vous donnera une plateforme solide pour les années à venir.

Si la réponse est non, un PaaS fera le travail. Et il n’y a aucune honte à cela.

FAQ

Kubernetes est-il adapté aux petites équipes ?

Pas en self-hosted. Une petite équipe (moins de 5 développeurs) qui veut utiliser K8s devrait se tourner vers un managed Kubernetes en mode simplifié (GKE Autopilot, par exemple) ou mieux, vers un PaaS comme Cloud Run ou Fly.io. L’overhead opérationnel d’un cluster K8s est réel et peut absorber une part significative de la bande passante d’une petite équipe. Le critère clé : avez-vous au moins 2 personnes capables de débuguer un problème K8s à 3h du matin ?

Quel est le coût réel de Kubernetes en production ?

Le coût infrastructure (VMs, load balancers, stockage) représente seulement 30 à 40% du coût total. Le reste, ce sont les coûts humains (formation, recrutement, temps d’opération) et les outils périphériques (monitoring, sécurité, GitOps). Pour un cluster de production avec 10 à 20 services, comptez entre 2 000 et 5 000 euros par mois en infrastructure managed, plus 1 à 2 ETP pour l’opérer. Les économies viennent du scaling automatique et de la densité de workloads par noeud.

GKE, EKS ou AKS : lequel choisir ?

GKE (Google) offre la meilleure expérience développeur et le mode Autopilot qui simplifie drastiquement les opérations. EKS (AWS) est le choix logique si votre écosystème est déjà sur AWS, mais demande plus de configuration manuelle. AKS (Azure) a beaucoup progressé et s’intègre bien avec l’écosystème Microsoft. Notre recommandation par défaut est GKE pour les nouveaux projets, et le cloud provider existant pour les migrations. Le lock-in au niveau K8s est minimal, c’est au niveau des services managés périphériques qu’il se crée.

Comment migrer vers Kubernetes sans interruption de service ?

La migration se fait en phases. Phase 1 : conteneuriser les applications et valider en staging. Phase 2 : déployer en parallèle (ancien et nouveau) avec un routage progressif du trafic via un load balancer. Phase 3 : basculer 100% du trafic et décommissionner l’ancienne infrastructure. Chaque phase doit inclure des tests de charge et un plan de rollback. Comptez 2 à 4 mois pour une migration complète selon la complexité de votre stack. Le piège classique : vouloir tout migrer d’un coup. Commencez par un service non critique pour valider le pipeline.