Von Docker Compose zu Kubernetes — die Migration, die nicht schmerzhaft sein muss

Die meisten „Migrate from Compose to Kubernetes"-Guides überspringen die Frage, ob Sie es sollten — und versemmeln dann das Wie. Sie sagen Ihnen, kompose convert zu starten, das YAML in den Cluster zu pushen und es als erledigt zu betrachten.

Die echte Migration deckt vier Bereiche ab: Wann migrieren, was zuerst migrieren, was nicht sauber übersetzt, und wie der Cutover gestaffelt wird.

Sollten Sie überhaupt migrieren? Nicht immer. Ein Compose-Stack mit fünf Services auf einer leistungsstarken VM, deployed via SSH und einem git pull, wird die meisten Kubernetes-Cluster bei einem Zehntel der operativen Kosten überleben. Migrieren Sie, wenn Sie Autoscaling brauchen, das Compose nicht bieten kann, feingranulareren Zugriffskontroll-Bedarf zwischen Services haben, oder eine Flotte jenseits von ~3 Knoten.

Was sauber übersetzt — und was nicht

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

Die 20 %, die ein Umdenken erfordern: depends_on: service_healthy (Ihre App braucht Retry-on-Startup-Logik), geteilte Volumes über Replicas hinweg (die meisten Cloud-Block-Storage sind ReadWriteOnce) und network_mode: host.

Der vollständige Beitrag behandelt:

• Den vierstufigen Migrationsplan (Lift-and-Shift → Parität → Cutover → K8s-Features einfahren)
• depends_on-Patterns und die App-Retry-Logik, die sie behebt
• Der Schmerz von ReadWriteOnce-Storage und die drei Ausweichrouten
• Die DNS/TTL-Vorbereitung in der Woche vor dem Cutover
• Den Compose-Stack als Rollback-Pfad 72 Stunden lang warm halten
• Features, die in der ersten Woche nicht hinzuzufügen sind (Istio etc.)

Melden Sie sich, wenn Sie kurz davor stehen.