Kubernetes : overkill ou pas ?

Orchestrateur de conteneurs pensé pour faire tourner, scaler et auto-réparer des dizaines/centaines de services sur plusieurs machines. Redoutable à l’échelle, cher en complexité en dessous.

👉 Overkill si…

  • Ton appli tient sur un seul serveur (ou tiendrait très bien dessus)
  • Tu es seul ou en toute petite équipe, sans dédié DevOps/SRE
  • C’est un monolithe (ou 2-3 services max), pas 15 microservices
  • Ton trafic n’a pas besoin d’auto-scaling — tu connais tes pics à l’avance ou ils sont modestes
  • Tu passes plus de temps à administrer le cluster qu’à écrire ton produit
  • Tu n’as pas de besoin réel de multi-région / haute dispo à ce niveau

✅ Justifié si…

  • Tu as réellement plusieurs microservices avec des cycles de déploiement indépendants
  • Tu as besoin d’auto-scaling et d’auto-healing sur beaucoup de noeuds
  • Une équipe dédiée (SRE/ops) existe pour maintenir le cluster
  • Tu déploies sur plusieurs régions/datacenters avec bascule automatique
  • Le coût d’ingénierie de K8s est largement inférieur au coût d’une panne ou d’un scaling manuel raté

Alternatives plus légères

  • Un seul VPS + Docker Compose : 90% des projets solo/petite équipe n’ont besoin de rien de plus
  • Docker Swarm : orchestration multi-noeuds façon K8s, mais une fraction de la complexité
  • PaaS managé (Fly.io, Railway, Render, Scalingo) : tu déploies, ils orchestrent – zéro cluster à administrer
  • systemd + quelques scripts : oui, ça existe encore, et ça tourne très bien pour un service stable

Règle simple

Si tu ne peux pas nommer le problème concret que K8s résout pour toi (pas « au cas où ça scale un jour »), c’est que tu n’en as pas besoin maintenant. Tu pourras migrer plus tard, c’est rarement le mur qu’on imagine.