Kubernetes vs Docker: Entscheidungshilfe 2026

Robin Werner, Kubernetes-Consultant bei Pexon Consulting | 12 Min. Lesezeit | 29.08.2026

TL;DR

Kubernetes vs Docker ist kein Duell: Docker packt und startet Container, Kubernetes orchestriert sie über Cluster. Pexon Consulting (80 MA, DACH, Azure/AWS/GCP) sieht bei Mittelstandsteams oft zu frühe K8s-Einführung. Stand August 2026: Kubernetes v1.37.0, Docker Engine 29.7.2. Faustregel: unter 10 Services auf 1-3 Hosts bleibt Compose meist die bessere Wahl.

Das Problem: zwei Tools, eine falsche Frage

„Sollen wir auf Kubernetes oder bei Docker bleiben?“ hören wir in Erstgesprächen fast wöchentlich. Die Frage setzt Konkurrenz voraus, die es so nicht gibt.

Docker beantwortet: Wie verpacken wir die App so, dass sie überall gleich läuft? Kubernetes beantwortet: Wie halten wir dutzende Instanzen über mehrere Server am Laufen, wenn Nodes sterben und Releases rollen?

Wer beides gleichsetzt, trifft die Betriebsentscheidung an der falschen Stelle. Dann landet ein 4-Personen-Team mit drei Microservices auf einem Cluster, der mehr Pflege braucht als die eigentliche Software.

In der Praxis steckt dahinter oft ein anderer Schmerz: Deployments dauern zu lange, Umgebungen driften, oder ein Audit fragt nach Hochverfügbarkeit. Kubernetes wirkt dann wie die Standardantwort aus jeder Konferenz-Keynote. Manchmal stimmt das. Häufig reicht erst einmal Disziplin bei Images, Compose-Dateien und einem sauberen CI-Build.

Was Docker und Kubernetes 2026 jeweils sind

Docker ist die Container-Plattform: Dockerfile, Image-Build, Engine, CLI, Compose. Für lokale Entwicklung und kleine Produktiv-Setups reicht das. Docker Engine steht bei v29.7.2 (Release 05.08.2026), Compose kommt über Desktop-Bundles mit. Offizielle Engine-Notes finden Sie bei Docker Docs.

Kubernetes ist der Orchestrierer: Scheduling, Self-Healing, Horizontal Pod Autoscaling, Rolling Updates, RBAC, Secrets. Es baut keine Images. Es startet OCI-Images über eine CRI-Runtime (meist containerd oder CRI-O). Seit Kubernetes 1.24 ist dockershim entfernt; Docker Engine braucht im Cluster den Adapter cri-dockerd, wenn überhaupt. Release-Linie und Support-Fenster dokumentiert das Projekt unter kubernetes.io/releases.

Aktuell: Kubernetes v1.37.0 „Garhwal“ (26.08.2026), 67 Enhancements im Release-Zyklus. Das Upstream-Repo liegt bei 125.568 GitHub-Stars (Abruf 29.08.2026), Moby/Docker Engine bei 72.014 Stars.

Kurz: Docker liefert das Paket. Kubernetes betreibt die Flotte.

# Image lokal bauen (Docker)
docker build -t shop-api:1.4 .
docker compose up -d

# denselben Image-Tag im Cluster ausrollen (Kubernetes)
kubectl set image deployment/shop-api shop-api=registry.example.com/shop-api:1.4
kubectl rollout status deployment/shop-api

Beide Befehle können im selben Unternehmen nebeneinander stehen. Das ist kein Widerspruch, sondern der Normalzustand. Entwickler bleiben bei Docker Desktop oder CI-Buildern. Der Cluster spricht containerd. Das Image-Format (OCI) verbindet beide Welten.

Kubernetes vs Docker: Vergleich auf einen Blick

Die CNCF-Jahresumfrage 2025 nennt rund 82 % der befragten Organisationen mit Kubernetes in Produktion. Das heißt nicht, dass 82 % Ihres Mittelstandsportfolios denselben Stack brauchen. Viele der Befragten sind Cloud-Native-Firmen, nicht Maschinenbauer mit 40 IT-Köpfen.

Unsere klare Position: Wer Compose-Workloads mit Kubernetes „absichert“, kauft Komplexität ein, ohne Verfügbarkeit zu gewinnen. Kubernetes heilt abgestürzte Pods. Es macht eine monolithische, stateful App nicht plötzlich HA-fähig.

Ein zweites Missverständnis: „Wir brauchen Kubernetes, weil wir Container nutzen.“ Container ≠ Orchestrierung. Sie können jahrelang produktive Compose-Stacks fahren und trotzdem modern deployen, solange Host-Anzahl, Release-Frequenz und Ausfalltoleranz im Rahmen bleiben.

Wann Docker Compose reicht (und Kubernetes Geldverschwendung ist)

Bleiben Sie bei Docker, wenn die meisten Punkte zutreffen:

1. Weniger als ca. 10 Container bzw. Services
2. Ein bis drei Server, kein Multi-AZ-Zwang
3. Releases wöchentlich oder seltener, manuelles Rollback akzeptabel
4. Kein dediziertes Platform-Team, Betrieb bei denselben Entwicklern
5. Compliance verlangt keine Cluster-Isolation, RBAC-Matrix oder Multi-Tenant-Namespaces

In diesem Fenster ist Compose schneller, günstiger und weniger fehleranfällig. Wir haben Teams gesehen, die nach sechs Monaten Kubernetes zurück auf Compose und systemd-Units gewechselt sind, weil der Cluster mehr Tickets erzeugt hat als die Apps.

Woran Sie den Fehleinstieg merken: Jeder kleine Config-Change braucht ein Ticket beim „Cluster-Owner“, Entwickler warten auf Namespace-Freigaben, und niemand traut sich an Upgrades von 1.35 auf 1.36. Dann ist Kubernetes nicht zu mächtig für Ihr Produkt, sondern Ihr Betriebsmodell ist zu dünn für die Plattform.

Docker Swarm existiert noch, bekommt aber kaum Entwicklungsschub. Für neue Orchestrierungs-Entscheidungen 2026 raten wir von Swarm ab. Entweder Compose (einfach) oder Kubernetes (Standard), dazwischen liegt wenig Zukunft.

Wann Kubernetes die richtige nächste Stufe ist

Kubernetes lohnt sich, wenn Betrieb und Architektur das fordern:

• Mehrere Hosts müssen denselben Service redundant tragen
• Rolling Updates ohne Wartungsfenster sind Pflicht
• Last schwankt stark (Batch, Shop-Peaks, KI-Inferenz)
• Mehrere Teams teilen sich Cluster-Ressourcen (Namespaces, Quotas, NetworkPolicies)
• Regulatorik oder Kundenverträge verlangen nachweisbares Patch-/HA-Modell

Dann ist der Sprung von „läuft auf meinem Rechner“ zu „läuft im Unternehmen“ der eigentliche Aufwand: Observability, Secrets, Ingress, Backup, Upgrade-Pfad. Genau dort setzen wir Platform-Engineering-Beratung an, nicht beim Image-Build.

Ein realistischer Einstieg im Mittelstand: eine Pilot-Workload containerisieren, auf Managed Kubernetes (AKS/EKS/GKE) ausrollen, drei Monate Betriebsroutine sammeln, erst dann den Rest nachziehen. Big-Bang-Migrationen scheitern bei uns seltener an Technik als an fehlenden Owners für Netzwerk und Secrets.

Kosten und Betriebsmodell: wo der Vergleich oft kippt

Softwarelizenz ist bei beiden Open Source (bzw. Docker CE) quasi null. Der Unterschied sitzt im Personal und in der Plattform.

Kurzfassung aus Projekten: Die Managed-Gebühr ist selten der Kostentreiber. Es sind Worker-Nodes, Observability-Stack und die Menschen, die Upgrades und Incidents tragen. Eine 180k-EUR-Jahresrechnung ohne klaren HA-Nutzen ist kein „Modernisierungsprojekt“, sondern Budgetverbrennung.

Wer kein internes Platform-Team aufbauen will, sollte Managed Kubernetes ernsthaft gegen Self-Hosted abwägen, bevor das erste kubeadm-Cluster steht. Self-Hosted spart die Control-Plane-Gebühr und kostet Sie dafür Patch-Verantwortung rund um etcd, CNI und Zertifikate.

# Minimaler Deploy-Ausschnitt: gewünschter Zustand statt Imperativ
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop-api
  template:
    metadata:
      labels:
        app: shop-api
    spec:
      containers:
        - name: shop-api
          image: registry.example.com/shop-api:1.4
          ports:
            - containerPort: 8080

Drei Replicas klingen trivial. Dahinter stecken Health-Checks, PodDisruptionBudgets, Ingress und ein Upgrade-Pfad für die Nodes. Genau diese Schicht fehlt in Compose und macht den Kostenunterschied.

Entscheidungs-Checkliste für IT-Leiter

Gehen Sie die Punkte ehrlich durch, bevor Budget für ein Cluster freigegeben wird:

1. Wie viele produktiv kritische Services haben wir wirklich (nicht Wunsch-Architektur)?
2. Brauchen wir Zero-Downtime-Deploys, oder reichen Wartungsfenster?
3. Wer patched Control Plane und Nodes in 12 Monaten (Name und Backup)?
4. Haben wir Monitoring, Alerting und On-Call schon für die bestehenden Systeme?
5. Ist der nächste Engpass Skalierung, oder eher Fachkräftemangel und Legacy-VMs?

Zwei oder weniger klare „Ja“ zu HA-/Multi-Team-Fragen: Compose behalten, Container-Hygiene verbessern. Drei oder mehr: Cluster-Pilot planen, nicht den ganzen Zoo auf einmal umziehen.

Wir raten aktuell davon ab, Kubernetes nur einzuführen, weil „der neue Architekt es so will“ oder weil ein Cloud-Vertrag Credits für AKS/EKS mitbringt. Credits verfallen. Betriebsaufwand bleibt.

Häufige Missverständnisse, die Projekte teuer machen

„Kubernetes ersetzt Docker.“ Nein. Entwickler bauen weiter Images (oft mit Docker oder Buildah/BuildKit). Im Cluster läuft containerd. Das Image-Format bleibt OCI.

„Mit Kubernetes brauchen wir keine VMs mehr zu verstehen.“ Nodes sind VMs oder Bare Metal. Storage, Netzwerk und IAM bleiben Ihre Baustellen.

„Wir nehmen Kubernetes, weil alle es nehmen.“ Adoption in der CNCF-Bubble ist kein Business Case. Messen Sie an Service-Anzahl, HA-Pflicht und Teamkapazität.

„Compose in Prod ist unprofessionell.“ Unprofessionell ist ein Cluster ohne Owner. Compose mit klaren Backup-, Update- und Monitoring-Regeln schlägt ein verwaistes Cluster.

Häufig gestellte Fragen

Was ist der Unterschied bei Kubernetes vs Docker in einem Satz?

Docker erstellt und startet Container auf einem Host. Kubernetes orchestriert viele Container über ein Cluster mit Scheduling, Self-Healing und deklarativen Deployments.

Brauche ich Docker, wenn ich Kubernetes nutze?

Zum Bauen von Images oft ja (oder eine OCI-kompatible Alternative). Als Runtime im Cluster seit 1.24 nicht mehr zwingend: Standard ist containerd/CRI-O, nicht Docker Engine.

Was kostet der Wechsel von Docker Compose zu Kubernetes?

Für einen Mittelstands-Pilot mit wenigen Services liegen Festpreis-Sprints bei uns oft im hohen zweistelligen bis niedrigen dreistelligen Tausenderbereich, plus laufender Betrieb. Entscheidend ist, ob Sie Managed Service oder Eigenbetrieb wählen.

Kubernetes vs Docker Swarm: was 2026 noch relevant ist?

Swarm deckt einfache Orchestrierung ab, die Community und Roadmap liegen klar hinter Kubernetes. Für neue Setups empfehlen wir Compose oder Kubernetes, nicht Swarm.

Reicht Docker Desktop mit integriertem Kubernetes für Produktion?

Für Lernen und lokale Tests ja. Für Produktion brauchen Sie ein richtiges Cluster (AKS/EKS/GKE oder On-Prem) mit Patch-Prozess, Backup und Netzwerk-Policies. Desktop ist kein Betriebsmodell.

Nächster Schritt

Wenn Sie unsicher sind, ob Compose noch trägt oder ein Cluster fällig ist: Kurz den Ist-Stand gegen Service-Anzahl, HA-Pflicht und Teamkapazität legen. Wir machen das als kompakten Architektur-Call, ohne Pitch-Folien.

Verwandte Themen