Docker Compose und Kubernetes sind keine direkten Ersatzprodukte
| Kriterium | Docker Compose | Kubernetes | Kommentar |
|---|---|---|---|
| Lokale Entwicklung | Sehr gut | Möglich, meist schwergewichtiger | Compose hat geringere Einstiegskosten |
| Produktion auf einem Host | Sehr gut | Oft überdimensioniert | Docker dokumentiert dieses Compose-Modell |
| Multi-Node-HA | Kein nativer Cluster-Scheduler | Sehr gut | Kubernetes hält Workloads über Cluster-Nodes |
| Self-Healing | Neustart auf Host | Sehr gut | Kubernetes ersetzt zusätzlich Pods und reagiert auf Node-Ausfälle |
| Autoscaling | Manuell | HPA | Skalierung anhand von Metriken |
| Rolling Updates | Manuell | HPA | Deployment bietet RollingUpdate und Rollback |
| Betriebskosten | Niedriger | Höher | Cluster erfordert zusätzliche Plattformkompetenz |
Docker Compose beschreibt Services, Netzwerke, Volumes, Konfigurationen und Secrets einer Containeranwendung deklarativ. Die Compose Specification ist das empfohlene Format. [1]
Kubernetes verwaltet containerisierte Workloads und Services in einem Cluster und bietet unter anderem Service Discovery, Load Balancing, Storage-Orchestrierung, Rollouts, Rollbacks und Skalierung. [8]
Die eigentliche Frage lautet daher, ob ein Projekt Cluster-Orchestrierung braucht oder ein gut betriebener Einzelhost ausreicht.
Stärken von Docker Compose
Compose hält Images, Umgebungsvariablen, Netzwerke, Volumes, Healthchecks, Abhängigkeiten, Secrets und Configs in einem Modell zusammen. [1][3]
Dieselbe Definition kann mit Overrides in Entwicklung, CI, Staging und Produktion verwendet werden. Docker dokumentiert dieses Vorgehen ausdrücklich. [2]
Das senkt die Einstiegshürde und hält den Deployment-Prozess einfach.
Compose in Produktion: Einzelserver ist dokumentiert
Docker beschreibt Compose ausdrücklich für Produktionsumgebungen und nennt einen einzelnen Server als einfachstes Deployment-Modell. [2]
Für Produktion sind getrennte Overrides, passende Ports und Umgebungsvariablen, Restart Policies sowie gegebenenfalls zusätzliche Hilfsdienste sinnvoll. [2]
Wenn alle Container auf einem Host laufen, bleibt dieser Host jedoch eine gemeinsame Fehlerdomäne. Ein Container-Restart behebt keinen Hostausfall.
Healthchecks, Abhängigkeiten und Neustarts
Mit `depends_on` und `condition: service_healthy` kann Compose auf einen erfolgreichen Healthcheck einer Abhängigkeit warten. [3][4]
Das Feld `restart` unterstützt unter anderem `no`, `always`, `on-failure` und `unless-stopped`. [3][7]
Diese Mechanismen erhöhen die Prozessresilienz, bleiben aber auf denselben Docker Host beschränkt.
Skalierung mit Compose: Replikate sind noch kein Cluster
`docker compose up --scale SERVICE=N` und `docker compose scale` können mehrere Instanzen eines Service starten. [6]
Das von Docker dokumentierte Standardmodell für Compose-Produktion bleibt ein einzelner Server. Für Scale-out über mehrere Hosts verweist Docker auf einen separaten Clustermechanismus. [2]
Die Compose Deploy Specification definiert zwar `replicas`, `placement`, `resources`, `update_config` und `rollback_config`, aber `deploy` ist optional und kann von nicht unterstützenden Implementierungen ignoriert werden. [5][3]
Was Kubernetes über einen einzelnen Host hinaus bietet
Kubernetes hält den gewünschten Zustand über Controller aufrecht. Deployment ist die typische Abstraktion für zustandslose Anwendungen und verwaltet Pods über ReplicaSets. [10]
Kubernetes kann Replikate auf Nodes verteilen, deren Anzahl erhalten, stabile Endpunkte über Services bereitstellen und auf Ausfälle reagieren. [8][10][15]
Die Control-Plane-Logik ist der zentrale Unterschied zu Compose, nicht die YAML-Syntax.
Self-Healing: Prozessausfall gegen Node-Ausfall
| Funktion | Docker Compose | Kubernetes | Unterschied |
|---|---|---|---|
| Container-Neustart | Ja | Ja | Beide können Prozesse neu starten |
| Recovery nach Node-Ausfall | Nein | Ja | Kubernetes kann Pod auf anderem Node starten |
| Replikate erhalten | Manuell | Deklarativ | Controller halten gewünschten Zustand |
| Metrikbasiertes Autoscaling | Nein | Ja | HPA passt Replikate periodisch an |
| Stabiler Endpoint | Compose-Netzwerk | Service | Service abstrahiert wechselnde Pods |
| CPU/RAM-Scheduling | Auf einem Host | Cluster-Scheduler | Scheduler berücksichtigt Requests |
Compose kann einen ausgefallenen Container auf einem funktionierenden Docker Host entsprechend der Restart Policy neu starten. [7]
Kubernetes kann zusätzlich Container neu starten, Pods ersetzen, Replikazahlen erhalten und Workloads bei Node-Ausfall auf anderen Nodes neu einplanen. [12]
Readiness Probes nehmen nicht bereite Pods aus Service-Backends, Liveness Probes können Container-Neustarts auslösen. Eine falsche Liveness-Konfiguration kann selbst Ausfälle verursachen. [16]
Netzwerk und Service Discovery
Compose erstellt Anwendungsnetzwerke und ermöglicht die Kommunikation über Servicenamen. Für viele Single-Host-Anwendungen reicht das aus. [1]
Kubernetes Service bietet eine stabile IP-Adresse oder einen Hostnamen für eine dynamische Menge von Pods. Services und EndpointSlices halten die Backends aktuell. [15]
Im Multi-Node-Cluster ist diese Abstraktion besonders wichtig, weil Pods Node und IP wechseln können.
Autoscaling und Ressourcensteuerung
Compose unterstützt manuelle Skalierung, bietet aber keinen HPA-Controller auf Basis von Cluster-Metriken. [6]
HorizontalPodAutoscaler kann Replikate eines Deployment oder StatefulSet anhand von CPU, Arbeitsspeicher oder eigenen Metriken anpassen. [13]
Kubernetes unterstützt außerdem CPU- und Memory-`requests` und `limits`; der Scheduler berücksichtigt Requests bei der Node-Auswahl. [14]
Deployments, Rolling Updates und Rollback
Ein typisches Compose-Deployment zieht oder baut ein neues Image und erstellt betroffene Container neu. Docker dokumentiert dafür unter anderem `docker compose up --no-deps -d web`. [2]
Kubernetes Deployment besitzt die eingebaute Strategie RollingUpdate sowie Revisionshistorie und `kubectl rollout undo`. [11]
Bei häufigen Releases mit mehreren Replikaten bietet Kubernetes damit einen fertigen Orchestrierungsmechanismus.
Datenbanken und zustandsbehaftete Workloads
Compose kann Datenbanken mit Volumes betreiben, wenn das Team Single-Host-Betrieb akzeptiert und Backups, Replikation und Recovery selbst gestaltet.
StatefulSet erhält stabile Pod-Identitäten und kann persistente Volumes zuordnen. Es ist für Workloads mit stabiler Netzwerkidentität oder persistenten Daten gedacht. [17]
StatefulSet macht eine Datenbank nicht automatisch hochverfügbar. Replikation, Konsistenz, Backups und Disaster Recovery bleiben Aufgaben der jeweiligen Datenbankarchitektur.
Betriebskosten von Kubernetes gehören in die Entscheidung
Die Kubernetes-Dokumentation betont, dass ein produktionsreifer Cluster Planung und Vorbereitung für Resilienz, Zugriffe, Verfügbarkeit und Ressourcen erfordert. [9]
Kubernetes ist kein vollständiges PaaS. Logging, Monitoring, Alerting und andere Plattformkomponenten bleiben optional und erweiterbar. [8]
Managed Kubernetes reduziert Control-Plane-Arbeit, aber Workload-Konfiguration, Netzwerk, Ressourcen, Rollout-Policies, Storage und Troubleshooting bleiben beim Team.
Microservices sind kein automatisches Kubernetes-Argument
Kubernetes unterstützt lose gekoppelte und dynamisch verwaltete Workloads, aber mehrere Services erzeugen allein noch keinen Clusterbedarf. [8]
Frontend, API, Worker, Redis und PostgreSQL können in Compose sinnvoll betrieben werden, wenn alles auf einen Host passt und die Verfügbarkeitsanforderungen das erlauben.
Bessere Kriterien sind Hostausfall-Toleranz, Replikate, Autoscaling, SLOs, Deployment-Frequenz und Zahl der Teams.
Wann ein Wechsel zu Kubernetes wirklich sinnvoll ist
| Frage | Compose ist sinnvoll, wenn | Kubernetes ist sinnvoll, wenn |
|---|---|---|
| Host-Ausfall | Externes Recovery oder Failover reicht | Workload soll Node-Ausfall automatisch überleben |
| Skalierung | Alles passt auf einen Host | Mehrere Nodes und Autoscaling nötig sind |
| Deployments | Einfaches Recreate oder eigener Prozess reicht | Kontrollierte Multi-Replica-Rollouts nötig sind |
| Team | Wenige Teams einen einfachen Stack betreiben | Viele Teams eine gemeinsame Plattform brauchen |
| Service-Anzahl | Anzahl allein kein Clusterproblem ist | Betrieb standardisiert und automatisiert werden muss |
| Plattform | Betriebliche Einfachheit Priorität hat | Policies, Scheduling und Clusterabstraktionen nötig sind |
Ein Wechsel ist gerechtfertigt, wenn das Single-Host-Modell zum betrieblichen Problem wird und nicht bloß, weil `compose.yaml` länger geworden ist.
Typische Trigger sind automatische Weiterarbeit nach Node-Ausfall, Multi-Node-Replikate, dynamisches Autoscaling, kontrollierte Rollouts vieler Services, eine gemeinsame Plattform für mehrere Teams oder standardisierte Ressourcen- und Netzwerkregeln. [8][9][12][13]
Ohne solche Anforderungen kann Kubernetes mehr bewegliche Teile hinzufügen als Nutzen liefern.
Praktischer Wachstumspfad
Ein vernünftiger Pfad ist häufig: Dockerfiles, Compose für lokale Entwicklung und Integration, anschließend Compose auch in Produktion, solange ein Host genügt.
Wenn Clusteranforderungen entstehen, sollte die Anwendung möglichst stateless werden, Sessions und Dateien externalisieren, saubere Health-Endpunkte liefern und Ressourcen, Secrets sowie Storage vor der Migration definieren.
Compose kann lokal bestehen bleiben, selbst wenn Produktion auf Kubernetes läuft.
- Mit SLOs und Verfügbarkeit beginnen.
- Wenn ein Host reicht, zuerst Compose prüfen.
- Wenn Hostausfall die Anwendung nicht stoppen darf, Multi-Node-Architektur einplanen.
- Bei dynamischer Last HPA und Kubernetes bewerten.
- Für kontrollierte Multi-Replica-Rollouts bietet Kubernetes fertige Controller.
- Datenbanken nicht nur deshalb in Kubernetes verschieben, weil die App dort läuft.
- Betriebskosten für Cluster, Observability, Netzwerk und Upgrades einrechnen.
- Das einfachste passende Modell wählen.
