De Docker Compose à Kubernetes — la migration qui n'a pas à être douloureuse

La plupart des guides « migrer de Compose à Kubernetes » sautent la question de savoir si vous devriez — puis ils ratent le comment. Ils vous disent de lancer kompose convert, de pousser le YAML dans un cluster et de considérer le travail fait.

La vraie migration couvre quatre préoccupations : quand migrer, quoi migrer en premier, ce qui ne traduit pas proprement, et comment échelonner le cutover.

Devez-vous migrer du tout ? Pas toujours. Une stack Compose à cinq services sur une VM costaude, déployée via SSH et un git pull, survivra à la plupart des clusters Kubernetes pour un dixième du coût opérationnel. Migrez quand vous avez besoin d'autoscaling que Compose ne peut pas fournir, d'un contrôle d'accès plus fin entre services, ou d'une flotte au-delà de ~3 nœuds.

Ce qui traduit proprement — et ce qui ne traduit pas

# Mapping Compose → Kubernetes
services      → Deployment / StatefulSet
ports         → Service (ClusterIP / LoadBalancer)
depends_on    → Init containers + readiness probes
volumes       → PVC + storageClass
healthcheck   → livenessProbe + readinessProbe

Les 20 % qui nécessitent une refonte : depends_on: service_healthy (votre app a besoin de logique de retry au démarrage), volumes partagés entre replicas (la plupart du stockage block cloud est ReadWriteOnce) et network_mode: host.

L'article complet couvre :

• Le plan de migration en quatre étapes (lift-and-shift → parité → cutover → gagner les features K8s)
• Patterns depends_on et la logique de retry app qui les corrige
• La douleur du stockage ReadWriteOnce et les trois portes de sortie
• Le travail de prep DNS/TTL la semaine avant le cutover
• Garder la stack Compose tiède comme chemin de rollback pendant 72 heures
• Les features à ne pas ajouter la première semaine (Istio, etc.)

Contactez-nous si vous êtes sur le point de vous lancer.