DevOps 10 Min Lesezeit

Docker Compose vs. Kubernetes 2026 – Wann sich was lohnt

Docker Compose vs. Kubernetes 2026: Die kurze Antwort

Die Frage „Compose oder Kubernetes?" wird 2026 immer noch heißer diskutiert, als sie sein müsste. Denn die Antwort ist in 90 % der Fälle erstaunlich banal: Solange du mit einem oder zwei Servern auskommst, ist Docker Compose die günstigere, schnellere und wartungsärmere Wahl. Kubernetes lohnt sich erst, wenn du echte Multi-Node-Ausfallsicherheit, horizontales Auto-Scaling oder ein Plattform-Team brauchst, das dutzende Teams bedient.

Was sich seit 2024/2025 verschoben hat: Docker Compose ist deutlich erwachsener geworden (Compose Spec, docker compose watch, include:, Compose Bridge), und Kubernetes ist deutlich bequemer geworden (Gateway API ist GA, Karpenter und EKS Auto Mode nehmen dir Node-Management ab). Gleichzeitig ist die Rechnung für ein Managed-Cluster nicht kleiner geworden – die Control Plane kostet bei AWS EKS weiterhin rund 73 US-Dollar pro Monat, bevor der erste Pod überhaupt startet.

Dieser Guide liefert dir konkrete Zahlen, echte Configs und eine Entscheidungsmatrix. Ziel: Du sollst nach dem Lesen in unter zehn Minuten wissen, welches Tool zu deinem Projekt passt – und was dich der Betrieb 2026 tatsächlich kostet.

Was Docker Compose 2026 wirklich kann

Compose ist längst nicht mehr das Dev-Spielzeug von 2018. Die Compose Spec ist ein offener Standard, der von Docker Compose v2, Podman Compose und Compose-kompatiblen Tools gleichermaßen gelesen wird. In der Praxis heißt das: Deine compose.yaml ist portabel und kein Vendor-Lock-in.

Die wichtigsten Neuerungen der letzten Jahre, die den Produktivbetrieb realistisch machen:

Was Compose weiterhin nicht kann: über mehrere Hosts verteilen, Pods automatisch neu schedulen, wenn ein Node stirbt, oder Requests basierend auf CPU-Last horizontal skalieren. deploy.replicas wird im Nicht-Swarm-Modus ignoriert – das überrascht viele Einsteiger bis heute.

Ein realistisches Compose-Setup 2026 auf einem Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB NVMe, 4,35 €/Monat) stemmt problemlos 15 bis 25 Container: API, Postgres, Redis, Worker, Reverse Proxy, Monitoring. Das reicht für die meisten SaaS-Produkte bis etwa 50.000 Requests pro Tag.

Was Kubernetes 2026 wirklich kann

Kubernetes ist 2026 erwachsen, aber auch deutlich komplexer geworden. Die Version 1.33/1.34 hat einige Altlasten entfernt, und mit der Gateway API ist endlich ein stabiler, rollenbasierter Nachfolger für Ingress verfügbar. Wichtig für alle, die noch auf ingress-nginx setzen: Das Projekt wurde offiziell zur Retirement angekündigt (März 2026), Migration auf Gateway API, Envoy Gateway oder Traefik ist Pflicht.

Die Kernfähigkeiten, die Compose strukturell nicht bieten kann:

Der Preis dafür ist real: Ein Team, das Kubernetes produktiv betreibt, braucht erfahrungsgemäß 4 bis 12 Wochen Einarbeitung, bevor die ersten Deployments stabil laufen. Und danach kontinuierlich Zeit für Upgrades – ein Minor-Version-Sprung alle vier Monate, ein Major-Upgrade pro Jahr.

Der direkte Vergleich in Zahlen

KriteriumDocker ComposeKubernetes
Lernkurve1–2 Tage4–12 Wochen
Multi-Node-Betriebneinja (3+ Nodes)
Auto-ScalingneinHPA / VPA / KEDA
Self-Healingrestart: unless-stoppedProbes + Scheduler
Zero-Downtime-Deploymanuell / Reverse ProxyRollingUpdate nativ
Secrets.env, Docker SecretsSecrets + External Secrets Operator
NetzwerkBridge-NetzwerkeCNI + NetworkPolicies
StorageBind Mounts, VolumesPV/PVC + StorageClasses
Control-Plane-Kosten0 €0 – 73 $/Monat
Realistisches Limit~1 Node, ~25 Containerab 3 Nodes, 100+ Pods

Die entscheidende Zeile ist „Realistisches Limit". Compose skaliert vertikal – du wirfst mehr RAM und CPU auf die Kiste. Kubernetes skaliert horizontal – du wirfst mehr Kisten in den Cluster. Beides ist legitim, aber nur eines davon übersteht den Ausfall einer einzelnen Maschine ohne Downtime.

Ein Punkt, der oft übersehen wird: Compose ist nicht „Kubernetes für Arme". Für einen Single-Node-Betrieb ist es technisch die bessere Lösung, weil du keinen Scheduler, kein etcd und keine CNI mitschleppst. Du sparst dir pro Monat grob 2 bis 6 Stunden Betriebsaufwand – bei einem Stundensatz von 80 € sind das 160 bis 480 €, die du in Features stecken kannst.

Wann sich Docker Compose 2026 lohnt

Compose ist die richtige Wahl, wenn mindestens drei der folgenden Punkte zutreffen: Du betreibst ein bis drei Server, dein Team hat weniger als fünf Entwickler, du brauchst keine 99,95-%-SLA-Garantie, und deine Last ist über den Tag halbwegs gleichmäßig.

Typische Szenarien, in denen Compose 2026 klar gewinnt:

  1. Indie-SaaS und MVPs: Ein CX22 oder CPX21 bei Hetzner (4,35 € bzw. 8,98 €/Monat) plus Caddy als Reverse Proxy deckt die ersten 12 Monate ab.
  2. Self-Hosted-Stacks: Nextcloud, Vaultwarden, Immich, Paperless – 20 Container auf einer Maschine, verwaltet mit einer einzigen YAML-Datei.
  3. Gameserver-Panels: Pterodactyl, Pelican oder AMP laufen nativ mit Compose und brauchen keine Orchestrierung.
  4. CI/CD-Runner und Build-Agents: Ephemere Compose-Stacks pro Pipeline-Run sind schneller als ein Cluster-Bootstrap.
  5. KI-/LLM-Setups: Ollama, vLLM, Open WebUI und ein Reverse Proxy – Compose mit GPU-Device-Reservation ist hier deutlich einfacher als ein GPU-Operator in Kubernetes.

Ein bewährtes Produktions-Setup sieht so aus: docker compose up -d --wait im systemd-Unit, Caddy oder Traefik davor für TLS, Watchtower oder Renovate für Image-Updates, restic für Backups der Volumes. Kostenpunkt: unter 20 €/Monat für die Infrastruktur, null € für Orchestrierung.

Wichtig: Setze restart: unless-stopped und healthcheck konsequent, und nutze deploy.resources.limits, damit ein ausgelaufener Worker nicht den ganzen Host frisst. Das sind die drei Maßnahmen, die 80 % der Compose-Produktionsprobleme verhindern.

Wann sich Kubernetes 2026 lohnt

Kubernetes lohnt sich ab dem Punkt, an dem dein Betriebsrisiko teurer ist als dein Betriebsaufwand. Konkret: Wenn eine Stunde Downtime dich mehr kostet als die 400 € monatlicher Aufwand für ein Cluster, ist die Rechnung eindeutig.

Klare Kubernetes-Indikatoren:

Für den Einstieg 2026 ist k3s auf drei Hetzner-Cloud-Servern die günstigste echte Cluster-Variante: 3 × CX22 = 13,05 €/Monat plus Load Balancer (5,39 €/Monat). Alternativ Hetzner Managed Kubernetes – dort ist die Control Plane kostenlos, du zahlst nur die Worker-Nodes ab 4,35 €/Monat. Ein 3-Node-Cluster mit Control Plane liegt damit bei etwa 13 bis 18 €/Monat, ein vergleichbares Setup bei AWS EKS bei rund 73 $ Control Plane plus 3 × t3.medium (~90 $) = über 160 $/Monat.

Wer Kubernetes einführt, sollte außerdem einplanen: GitOps mit Argo CD oder Flux, External Secrets Operator für Secrets, Prometheus + Grafana für Monitoring, und ein Upgrade-Fenster pro Quartal. Ohne diese vier Bausteine wird Kubernetes schnell zum teuren Bastelprojekt.

Kostenvergleich: Was ein Cluster 2026 wirklich kostet

VarianteControl Plane3 WorkerGesamt/Monat
Docker Compose, 1× Hetzner CX22––ca. 5 €
Docker Compose, 1× Hetzner CCX13 (dedicated)––ca. 14 €
k3s self-hosted, 3× CX22 + LB0 €13,05 €ca. 18 €
Hetzner Managed Kubernetes, 3× CX220 €13,05 €ca. 13 €
DigitalOcean DOKS, 3× 2 vCPU/4 GB0 $72 $ca. 72 $
Google GKE Regional, 3× e2-medium73 $ca. 75 $ca. 148 $
AWS EKS, 3× t3.medium73 $ca. 90 $ca. 163 $

Die Spanne ist gewaltig: Für denselben funktionalen 3-Node-Cluster zahlst du bei Hetzner rund 13 €, bei AWS rund 163 $. Das ist ein Faktor von 12. Wer Kubernetes „wegen der Cloud-Native-Standards" einführt, aber keinen Multi-Region- oder Compliance-Bedarf hat, verbrennt hier Geld ohne Gegenwert.

Dazu kommen versteckte Posten: Egress-Traffic (bei AWS 0,09 $/GB nach dem ersten GB), Load Balancer (AWS ALB ab ~18 $/Monat, Hetzner LB 5,39 €/Monat), NAT Gateway (AWS ab ~32 $/Monat) und Managed-Datenbanken. In der Praxis kostet ein „kleines" EKS-Setup selten unter 250 $/Monat.

Praxisbeispiel: Dieselbe App in Compose und Kubernetes

Nehmen wir eine API mit Postgres. In Compose sind das 30 Zeilen:

services:
  api:
    image: ghcr.io/acme/api:1.8.3
    ports: ["8080:8080"]
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on:
      db:
        condition: service_healthy
    deploy:
      resources:
        limits: { cpus: "1.0", memory: 512M }
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:8080/healthz"]
      interval: 10s
      retries: 5
    restart: unless-stopped

  db:
    image: postgres:17-alpine
    volumes: ["pgdata:/var/lib/postgresql/data"]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 5s

volumes:
  pgdata:

Start mit docker compose up -d --wait, Logs mit docker compose logs -f api. Für die Entwicklung läuft parallel docker compose watch und synchronisiert Codeänderungen in den Container.

In Kubernetes brauchst du für dieselbe Funktionalität mindestens vier Objekte – Deployment, Service, Ingress/Gateway-Route, PVC – plus HPA und Secret. Das Deployment allein:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  strategy:
    rollingUpdate: { maxSurge: 1, maxUnavailable: 0 }
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
      - name: api
        image: ghcr.io/acme/api:1.8.3
        ports: [{ containerPort: 8080 }]
        envFrom:
        - secretRef: { name: api-secrets }
        resources:
          requests: { cpu: 250m, memory: 256Mi }
          limits:   { cpu: "1",  memory: 512Mi }
        readinessProbe:
          httpGet: { path: /healthz, port: 8080 }
          initialDelaySeconds: 5
        livenessProbe:
          httpGet: { path: /healthz, port: 8080 }
          periodSeconds: 20

Der Unterschied ist nicht die Zeilenzahl, sondern die Betriebslogik: Im Compose-Setup gibt es genau einen API-Container. Fällt der Host aus, ist die API offline. Im Kubernetes-Setup laufen drei Replicas auf verschiedenen Nodes, der Scheduler verschiebt Pods bei Node-Ausfall automatisch, und kubectl rollout status deployment/api bestätigt dir den Deploy-Erfolg.

Migration von Compose zu Kubernetes ohne Drama

Der einfachste Weg führt über Compose Bridge oder Kompose. Beide lesen deine compose.yaml und erzeugen Kubernetes-Manifeste:

docker compose bridge convert -f compose.yaml -o k8s/
# oder klassisch:
kompose convert -f compose.yaml -o k8s/
kubectl apply -f k8s/

Das Ergebnis ist ein Startpunkt, kein fertiges Setup. Du musst in jedem Fall nacharbeiten: resources.requests ergänzen (Kompose setzt nur Limits), Readiness- und Liveness-Probes definieren, Secrets aus der Compose-Datei in Kubernetes-Secrets oder den External Secrets Operator verschieben, und persistente Volumes auf PVCs mit StorageClass umstellen.

Ein realistischer Migrationspfad in vier Schritten:

  1. Woche 1: Compose-Datei aufräumen – Healthchecks, Resource-Limits, Secrets auslagern. Das verbessert auch den Compose-Betrieb sofort.
  2. Woche 2–3: Manifeste generieren, in Git legen, Argo CD oder Flux aufsetzen. Noch kein Produktivtraffic.
  3. Woche 4–6: Staging-Traffic umleiten, Monitoring (Prometheus, Grafana, Loki) aufbauen, Alerts definieren.
  4. Ab Woche 7: Produktivverkehr schrittweise migrieren, Compose-Stack als Fallback zwei Wochen parallel laufen lassen.

Wichtig: Migriere nicht gleichzeitig auf Kubernetes und auf eine neue Datenbank oder ein neues CI-System. Ein Variablenwechsel pro Quartal reicht.

Der Mittelweg: k3s, Talos Linux, Nomad und Docker Swarm

Zwischen Compose und „richtigem" Kubernetes gibt es 2026 mehrere sinnvolle Zwischenstufen. Die wichtigste ist k3s: ein zertifiziertes Kubernetes in einer einzigen Binärdatei, ohne Cloud-Provider-Abhängigkeiten, mit SQLite statt etcd als Default. Auf drei CX22-Servern läuft ein produktionsfähiger Cluster für unter 20 €/Monat.

Talos Linux ist die konsequenteste Variante: ein unveränderliches, API-verwaltetes Betriebssystem, das nur Kubernetes spricht. Kein SSH, keine Paket-Updates, kein Konfigurationsdrift. Ideal für alle, die Cluster-Betrieb automatisieren wollen, aber eine steilere Lernkurve akzeptieren.

HashiCorp Nomad bleibt die pragmatische Alternative für gemischte Workloads: Container, Java-Jars, Binaries und Batch-Jobs in einem Scheduler. Der Betriebsaufwand liegt deutlich unter Kubernetes, aber das Ökosystem ist kleiner – kein Helm, keine Operatoren, kein Gateway API.

Docker Swarm ist 2026 faktisch im Maintenance-Modus. Für Neuprojekte gibt es keinen Grund mehr, darauf zu setzen; für Bestandsinstallationen lohnt die Migration auf k3s oder Compose mit mehreren Hosts via docker context.

Eine oft unterschätzte Option für Single-Node-Betrieb: Podman Quadlet. Container werden als systemd-Units deklariert, rootless betrieben und vom Init-System überwacht. Das gibt dir Compose-ähnliche Einfachheit mit systemd-Zuverlässigkeit – inklusive Restart=always und Journal-Logs.

Monitoring, Logging und CI/CD im Vergleich

Im Compose-Betrieb ist Monitoring bewusst schlank: cAdvisor plus Prometheus plus Grafana als drei zusätzliche Container, Logs via docker compose logs oder Loki mit dem Docker-Log-Treiber. Setup-Aufwand: ein halber Tag. RAM-Bedarf: etwa 400 MB.

In Kubernetes ist Monitoring Pflicht, nicht optional – ohne Prometheus Operator, kube-state-metrics und Node Exporter fliegst du blind. Rechne mit 1,5 bis 2 GB RAM nur für den Monitoring-Stack, plus 2 bis 4 Stunden Einrichtung und danach kontinuierlicher Pflege von Dashboards und Alert-Rules.

Bei CI/CD unterscheiden sich die Modelle grundlegend:

Faustregel: Wenn dein Deploy-Prozess aus einem einzigen Bash-Skript besteht, das du in fünf Minuten erklären kannst, brauchst du kein GitOps. Sobald mehr als zwei Personen deployen oder du Audit-Trails brauchst, wird GitOps zur Pflicht.

Entscheidungsmatrix: 10 Fragen, die alles klären

Beantworte diese Fragen ehrlich. Ab vier „Ja"-Antworten in der rechten Spalte ist Kubernetes gerechtfertigt, darunter ist Compose die bessere Wahl.

#FrageComposeKubernetes
1Läuft alles auf einem Server?JaNein
2Downtime unter 5 Min/Monat gefordert?NeinJa
3Last schwankt um Faktor 5+?NeinJa
4Mehr als 3 Teams deployen?NeinJa
5Compliance/Audit erforderlich?NeinJa
6Budget unter 50 €/Monat?JaNein
7Team hat K8s-Erfahrung?NeinJa
8GPU-/Batch-Workloads mit Queue?NeinJa
9Multi-Region geplant?NeinJa
10Deploy dauert heute unter 2 Minuten?JaNein

Ein häufiger Fehler: Teams führen Kubernetes ein, weil es „der Standard" ist, und verbringen danach 30 % ihrer Zeit mit Cluster-Themen statt mit Produktfeatures. Wenn dein Produkt noch Product-Market-Fit sucht, ist das teuer erkauft.

Der umgekehrte Fehler ist genauso real: Ein Unternehmen mit 40 Entwicklern und drei Produkten betreibt alles auf einem Compose-Host und wundert sich, warum Deployments sich gegenseitig blockieren. Ab etwa 10 Personen im Engineering und mehr als einem Produkt ist ein Cluster fast immer die günstigere Lösung – gemessen an Personalkosten, nicht an Serverkosten.

Und die pragmatische Antwort für 2026: Starte mit Compose, halte deine Container-Konfiguration Kubernetes-kompatibel. Konkret heißt das: keine Host-Path-Bind-Mounts für Daten, Healthchecks statt Sleeps, Konfiguration über Umgebungsvariablen, ein Prozess pro Container, Logs nach stdout. Wer diese fünf Regeln einhält, kann später mit kompose convert in einem Tag auf Kubernetes wechseln.

FAQ

Ist Docker Compose 2026 für den Produktivbetrieb geeignet?

Ja, für Single-Node-Setups uneingeschränkt. Docker selbst positioniert Compose primär für Entwicklung, aber mit restart: unless-stopped, Healthchecks, Resource-Limits und einem Reverse Proxy davor läuft es in der Praxis stabil. Achte auf automatische Image-Updates (Renovate, Watchtower) und getestete Backups der Volumes – das sind die beiden kritischen Punkte, nicht die Orchestrierung.

Was kostet ein Kubernetes-Cluster 2026 minimal?

Ein k3s-Cluster auf drei Hetzner-CX22-Servern kostet rund 13 €/Monat plus 5,39 € für einen Load Balancer, also etwa 18 €. Hetzner Managed Kubernetes startet bei rund 13 €/Monat für drei Worker-Nodes, da die Control Plane kostenlos ist. Bei AWS EKS kommen allein 73 $/Monat für die Control Plane plus Nodes, NAT Gateway und Load Balancer hinzu – realistisch 250 $/Monat aufwärts.

Kann ich meine docker-compose.yml direkt in Kubernetes nutzen?

Nicht direkt, aber fast. Mit docker compose bridge convert oder kompose convert erzeugst du aus der Compose-Datei Kubernetes-Manifeste. Diese musst du anschließend nacharbeiten: requests ergänzen, Readiness-/Liveness-Probes definieren, Secrets auslagern und Volumes auf PVCs umstellen. Rechne mit ein bis drei Tagen Nacharbeit für einen mittelgroßen Stack.

Wann sollte ich von Compose auf Kubernetes migrieren?

Wenn mindestens drei dieser Kriterien zutreffen: Ausfall eines Servers darf nicht zu Downtime führen, Last schwankt um mehr als Faktor 5, mehr als drei Teams deployen, Compliance-Audits sind Pflicht, oder du brauchst Multi-Region. Ein weiteres starkes Signal: Deine Deployments blockieren sich gegenseitig, weil mehrere Services auf demselben Host um Ressourcen konkurrieren.

Ist Docker Swarm 2026 noch eine Option?

Für Neuprojekte nein. Swarm befindet sich seit Jahren im Maintenance-Modus und bekommt keine nennenswerten Features mehr. Wenn du Multi-Node-Betrieb mit geringem Aufwand brauchst, sind k3s oder Nomad die besseren Alternativen. Für Single-Node-Setups ist Compose ohnehin die einfachere und besser gepflegte Wahl.

📖 Ähnliche Artikel