Kubernetes : quand ça vaut le coup (et quand non)

Kubernetes, je l’installe chez des clients depuis 2019. J’ai vu des équipes de 3 devs galérer avec la complexité. J’ai vu des boîtes de 200 personnes gagner des mois de travail grâce à lui. La différence entre les deux ? Pas le niveau technique. Le contexte.

Un orchestrateur de conteneurs, c’est un chef d’orchestre pour tes applications. Tu lui dis “je veux 3 instances de mon API avec 512 Mo de RAM chacune” et il se débrouille. Il trouve de la place sur tes serveurs. Il démarre les conteneurs. Il vérifie qu’ils tournent. Si un conteneur plante, il en relance un autre. Si un serveur tombe, il redistribue la charge ailleurs.

L’approche est déclarative. Tu décris l’état souhaité, Kubernetes fait le nécessaire pour y arriver. C’est le contraire des scripts shell qu’on exécute en croisant les doigts.

Concrètement, ce que ça apporte :

• Tout est versionné dans Git. Tes déploiements, ta config, tes secrets. Un problème en prod ? git revert et c’est réglé en 30 secondes.
• Haute dispo native. Tu demandes 3 réplicas, tu as 3 réplicas. Un pod meurt, Kubernetes en recrée un. Pas besoin de superviser manuellement.
• Scaling automatique. Le HPA (Horizontal Pod Autoscaler) ajoute des pods quand le CPU monte. Le cluster autoscaler ajoute des serveurs quand les pods n’ont plus de place. Tout ça sans intervention humaine.
• Déploiements sans interruption. Rolling updates par défaut. Les nouvelles versions arrivent progressivement pendant que les anciennes continuent de servir le trafic.

Ça a l’air magique. Ça ne l’est pas.

Kubernetes, c’est une bête complexe. Un cluster de prod, c’est minimum 3 nœuds pour le control plane, plus les workers. Ça demande des compétences réseau, stockage, sécurité. La courbe d’apprentissage est raide. Compte 6 mois avant qu’une équipe soit vraiment autonome.

Alors, quand est-ce que ça vaut le coup ?

J’utilise une grille de lecture simple. Si tu coches au moins 3 de ces cases, Kubernetes commence à faire sens :

• Plus de 10 services à gérer
• Besoin de scaler automatiquement selon la charge
• Plusieurs environnements (dev, staging, prod) à maintenir
• Équipe de plus de 5 devs qui déploient en parallèle
• Exigence de haute disponibilité (99.9%+)
• Multi-cloud ou hybrid cloud dans la roadmap

Si tu as 3 applications sur un seul serveur, Kubernetes est probablement surdimensionné. Docker Compose fait très bien le job. Si tu as une équipe de 2 personnes, le temps passé à maintenir le cluster sera difficile à rentabiliser.

Un cas récent. Un client SaaS avec 8 microservices, 15 devs, 3 environnements. Avant Kubernetes : déploiements manuels, 2 heures par release, incidents réguliers le vendredi soir. Après : pipeline GitOps avec ArgoCD, déploiement en 4 minutes, rollback en 30 secondes. L’investissement initial (3 semaines de setup) a été amorti en 2 mois.

Un autre cas. Une startup early-stage, 2 devs, un monolithe Python. Après discussion, on a opté ensemble pour un simple VPS avec Docker Compose. C’était le bon choix pour leur contexte : coût mensuel de 50€ au lieu de 400€ pour un cluster managé, et surtout moins de charge cognitive pour une petite équipe déjà bien occupée. Quand ils auront 10 services et 10 devs, la question se reposera naturellement.

Le managed Kubernetes (EKS, GKE, AKS) simplifie la partie control plane. Tu ne gères plus les masters. Mais tu gères toujours le reste : ingress, certificats, monitoring, logs, RBAC, network policies. C’est pas gratuit en temps ni en compétences.

Mon conseil : commence par les conteneurs. Maîtrise Docker. Mets en place du CI/CD basique. Quand la complexité de ton infra dépasse ce que tu peux gérer sereinement, Kubernetes devient une option naturelle. Pas avant.