Trois microservices, une base Postgres, Redis — le CTO lit que « tout le monde est sur Kubernetes ». Six semaines plus tard, l'équipe débogue des problèmes de DNS cluster alors que le vrai goulot était une requête SQL. L'orchestrateur n'était pas le problème ; c'était la réponse prématurée.
Docker Compose décrit un graphe de conteneurs sur une ou quelques machines : docker compose up -d, volumes locaux, réseau bridge. Kubernetes orchestre des pods sur un cluster : planification, autoréparation, mises à jour progressives, ingress, secrets — avec une courbe d'apprentissage et un coût opérationnel réels.
Seuils de décision pragmatiques
| Signal | Compose suffit | Envisager Kubernetes |
|---|---|---|
| Nombre de services | ≤ 5–8 stables | > 10 ou churn élevé |
| Nœuds | 1–3 VPS | Multi-zone, autoscaling horizontal |
| Déploiements / jour | Quelques-uns | Dizaines, canary ou blue-green |
| Équipe d'exploitation | Développeur généraliste | SRE ou Kubernetes managé |
| Stateful | Volume plus backup simple | Opérateurs base, PVC complexe |
| Budget d'exploitation | Minimal | Accepte surcharge cluster |
Adopter Kubernetes pour le CV de l'équipe coûte plus cher qu'un VPS bien dimensionné pour 95 % des PME web.
Compose : forces et limites
Forces. Lisibilité du compose.yml, environnement local proche de la petite prod, démarrage rapide, logs docker compose logs -f.
Limites. Pas de planificateur multi-machine natif sans Swarm, mise à jour progressive manuelle, secrets mal gérés si tout reste dans .env.
Pattern sain : Compose sur VPS NVMe plus base managée chez l'hébergeur plus backup restic externe. Des PaaS comme Clever Cloud ou Alwaysdata conviennent si l'objectif est déployer depuis Git sans gérer un cluster.
Kubernetes : quand la complexité se rentabilise
Scaling horizontal automatique sur trafic événementiel. Multi-tenant interne avec namespaces et quotas. Déploiements canary et rollback automatique — avec prudence sur le service mesh. Opérateurs Postgres ou Kafka si vous avez les compétences pour les exploiter. Les offres managées européennes réduisent la douleur du control plane ; vous restez responsable des manifests, limits/requests et ingress TLS.
Anti-patterns à éviter
Kubernetes pour un monolithe WordPress — mutualisé ou VPS plus cache suffit. Compose en prod sans healthcheck ni politique restart. Cluster minuscule un nœud « pour être prêt » — pire des deux mondes. StatefulSet maison sans backup testé.
Le sommet : l'orchestrateur ne compense pas un mauvais découpage
Décider et avancer sans angle mort
Comptez services, déploiements par semaine et nœuds nécessaires sur douze mois. Restez sur Compose plus base managée si vous tenez sur trois nœuds ou moins avec une équipe généraliste. Pilotez Kubernetes managé sur un seul service stateless avant migration totale. Budgétisez formation et astreinte cluster — pas seulement le prix du plan. Comparez VPS et Kubernetes managé dans le comparateur ; enchaînez vers Kubernetes ou serverless si le scaling reste ponctuel.
Questions fréquentes
Kubernetes obligatoire en production ?
Non. Pertinent quand services, environnements ou nœuds rendent le déploiement manuel trop risqué.
Compose pour haute disponibilité ?
Un VPS unique non. Deux VPS plus load balancer plus compose identique peut suffire sans Kubernetes.
Coût caché Kubernetes ?
Formation, mises à jour, monitoring — souvent 0,5–1 ETP d'exploitation. Le managé réduit mais n'élimine pas tout.
Migration progressive ?
Oui : état externalisé, Compose stateless, puis Kubernetes si scaling horizontal récurrent.
Avant d'installer kubectl en prod, demandez : combien de déploiements ratés cette année venaient du manque d'orchestration — et combien d'une config ou d'un test oublié ?