Kubernetes vs Docker ist kein Wettkampf, auch wenn die Suchanfrage so klingt. Docker baut Container-Images und startet Container auf einem Rechner. Kubernetes nimmt fertige Images und betreibt sie als Anwendung über viele Rechner hinweg: Es verteilt die Container, startet sie bei Ausfall neu, skaliert sie und leitet den Netzwerkverkehr dorthin. In den meisten Projekten arbeiten beide zusammen: Docker in der Entwicklung und in der Build-Pipeline, Kubernetes im Betrieb.
Der Vergleich, der dich wahrscheinlich wirklich interessiert, heißt nicht Kubernetes gegen Docker, sondern Kubernetes gegen Docker Compose oder gegen Docker Swarm. Das sind die Werkzeuge, mit denen Docker selbst mehrere Container zusammen betreibt. Genau da zeigt sich der Unterschied, und genau da fällt die Entscheidung, welches Werkzeug dein Projekt braucht.
Ich arbeite seit 2017 mit Containern in Kubernetes und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024). Heute berate ich mittelständische Unternehmen und betreibe Cluster in Produktion. Alle meine Kubernetes-Themen findest du gesammelt auf der Seite Kubernetes, die Grundbegriffe im Beitrag Kubernetes einfach erklärt.
Kubernetes vs Docker: wer macht was
Docker ist zuerst ein Werkzeug für einen Rechner. Es besteht aus einem Daemon, der Container startet und stoppt, einer Kommandozeile, mit der du ihn steuerst, und einem Format für Images samt Registry, in die du sie hochlädst. Mit einem Dockerfile beschreibst du, wie ein Image gebaut wird, mit docker run startest du daraus einen Container. Das ist der Teil, den fast jeder Entwickler kennt, und der Grund, warum Docker oft als Synonym für Container gilt, so wie Tempo für Taschentücher.
Kubernetes interessiert sich nicht dafür, wie ein Image entsteht. Es bekommt eine Beschreibung des gewünschten Zustands: welches Image, wie viele Kopien, wie viel Speicher, welcher Port nach außen. Dann sorgt es dafür, dass dieser Zustand auf einem Cluster aus mehreren Servern eintritt und erhalten bleibt. Fällt ein Server aus, starten die Container auf einem anderen. Kommt mehr Last, laufen mehr Kopien. Kommt eine neue Version, tauscht Kubernetes die Container nacheinander aus, ohne dass Nutzer davon etwas merken.
Der Unterschied liegt also in der Ebene. Docker beantwortet die Frage „Wie läuft meine Anwendung in einem Container?". Kubernetes beantwortet die Frage „Wie laufen hundert Container auf zehn Servern, ohne dass jemand nachts aufsteht?". Ein Vergleich auf Augenhöhe ist das nicht, eher Werkbank gegen Fabrikhalle.
Was Docker für Kubernetes heute noch ist
Eine Frage kommt in fast jedem Kurs: „Brauche ich Docker, wenn ich Kubernetes habe?" Die ehrliche Antwort hat zwei Hälften.
Zum Betrieb der Container braucht Kubernetes Docker nicht mehr. Kubernetes spricht über eine Schnittstelle namens Container Runtime Interface (CRI) mit einer Container-Laufzeit, und die heißt in aktuellen Clustern meist containerd oder CRI-O. containerd ist übrigens der Kern, den Docker selbst intern verwendet, und wurde aus Docker heraus als eigenständiges Projekt ausgegliedert. Der Docker-Daemon selbst passte nie sauber in diese Schnittstelle. Kubernetes hatte deshalb lange eine Brücke namens dockershim mitgeliefert, die seit Frühjahr 2022 nicht mehr Teil von Kubernetes ist. Die Hintergründe erklärt das Projekt in seinen Fragen und Antworten zum Ende von dockershim, die Einrichtung der Laufzeiten steht in der Kubernetes-Dokumentation zu Container-Laufzeiten.
Zum Bauen der Images brauchst du weiterhin ein Werkzeug, und das ist in den meisten Teams Docker. Ein Image, das du mit docker build baust, folgt dem OCI-Standard und läuft unverändert unter containerd in Kubernetes. Kubernetes selbst baut keine Images. Deine Pipeline baut sie, schiebt sie in eine Registry, und Kubernetes zieht sie von dort. Alternativen wie Buildah oder Kaniko gibt es, aber du musst sie nicht kennen, um mit Kubernetes zu starten.
In der Praxis bedeutet das: Docker Desktop auf dem Laptop, Docker in der CI, containerd im Cluster. Dein Dockerfile ist der Teil, der überall gleich bleibt.
Dieselbe Anwendung als Compose-Datei und als Kubernetes-Manifest
Am deutlichsten wird der Unterschied, wenn du dieselbe Anwendung in beiden Welten beschreibst. Nehmen wir einen Webserver mit nginx, der unter Port 8080 erreichbar sein soll. Mit Docker Compose sieht das so aus:
services:
web:
image: nginx:stable
ports:
- "8080:80"
Ein docker compose up -d startet den Container auf deinem Rechner. Fertig. Die Datei beschreibt einen Container auf einer Maschine, und mehr will Compose auch nicht.
Dieselbe Anwendung in Kubernetes braucht zwei Objekte. Ein Deployment beschreibt, welches Image in wie vielen Kopien laufen soll:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: nginx:stable
ports:
- containerPort: 80
Ein Service gibt diesen Kopien eine stabile Adresse im Cluster, weil die einzelnen Container jederzeit ersetzt werden können und dabei ihre IP-Adresse wechseln:
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 8080
targetPort: 80
Diese Adresse gilt zunächst nur innerhalb des Clusters; nach außen bringst du die Anwendung später über einen Ingress oder einen Service vom Typ LoadBalancer. Mit kubectl apply -f web-deployment.yaml -f web-service.yaml übergibst du beide Dateien an den Cluster. Kubernetes legt daraus zwei Pods an, verteilt sie auf die verfügbaren Nodes und hält sie am Laufen. Was ein Pod genau ist und warum Kubernetes Container darin verpackt, erkläre ich in Kubernetes Pod: was ist ein Pod?.
Zwei Dinge fallen sofort auf. Erstens: Das Kubernetes-Manifest ist deutlich länger, obwohl es dasselbe tut. Zweitens: Es enthält Angaben, die in Compose keinen Sinn ergeben, etwa replicas: 2. Diese Zeile ist der Kern des Unterschieds. Du sagst nicht „starte einen Container", sondern „ich will, dass zwei laufen, immer". Stirbt einer, ersetzt Kubernetes ihn. Genau dafür bezahlst du mit dem Mehr an YAML.
Wann Docker Compose reicht
Mein erster Rat, wenn jemand für ein kleines Projekt nach Kubernetes fragt: Compose ansehen. Ich meine das ernst. Compose ist das richtige Werkzeug, wenn deine Anwendung auf einer Maschine läuft und dort auch laufen darf.
Unterschätze dabei nicht, was ein einzelner Host trägt. Mit Reverse Proxy, TLS-Terminierung, Health-Checks, Backups und einem sauberen Update-Skript laufen darauf durchaus ernsthafte Produktionssetups, teils über Jahre. Die Grenze von Compose ist nicht die Ernsthaftigkeit der Anwendung, sondern die Zahl der Maschinen.
Das trifft auf mehr Fälle zu, als der Hype vermuten lässt. Eine Entwicklungsumgebung mit Datenbank, Backend und Frontend auf dem Laptop. Ein internes Werkzeug, das ein paar Dutzend Kollegen nutzen. Ein Prototyp, bei dem noch niemand weiß, ob er in drei Monaten noch existiert. Eine Firmenwebsite mit Kontaktformular. In all diesen Fällen bringt Kubernetes Komplexität mit, für die es noch kein Problem gibt. Ich habe in meinem Buch bewusst einen Abschnitt darüber geschrieben, für welche Unternehmen Kubernetes nicht sinnvoll ist, und der Startup-Fall mit drei Schichten auf einem Server steht dort ganz oben.
Compose hat drei Grenzen, die du kennen solltest. Es kennt nur eine Maschine. Es startet abgestürzte Container zwar neu, aber es kennt keinen Ersatz für einen ausgefallenen Server. Und ein Update bedeutet einen kurzen Ausfall, weil der alte Container gestoppt wird, bevor der neue läuft. Solange keine dieser drei Grenzen weh tut, bleibst du bei Compose und sparst dir eine Menge Betrieb.
Wann du Kubernetes brauchst
Bei meinen Kunden ist der Wechsel von Compose zu Kubernetes nie an einem einzelnen Feature festgemacht worden, sondern immer an einer von drei Schwellen.
Die erste Schwelle ist der Ausfall. Sobald ein Ausfall von einer Stunde Geld oder Vertrauen kostet, reicht ein Server nicht mehr. Kubernetes verteilt deine Anwendung über mehrere Nodes und zieht sie automatisch um, wenn einer stirbt. In meinen eigenen Clustern laufen die Control-Plane-Nodes deshalb in drei verschiedenen Rechenzentren.
Die zweite Schwelle ist die Zahl der Dienste. Bei drei Containern verwaltest du Ports, Umgebungsvariablen und Neustarts noch im Kopf. Bei fünfzehn Diensten in vier Umgebungen nicht mehr. Kubernetes gibt dir dafür Namespaces, Service-Discovery, Rollouts mit Rollback und eine einheitliche API, die auch Werkzeuge wie ArgoCD oder Helm ansprechen.
Die dritte Schwelle ist der Release-Takt. Wer mehrmals täglich ausrollt, will keinen Ausfall pro Deployment. Kubernetes tauscht Container nacheinander aus und prüft vorher, ob der neue gesund ist. Compose kann das nicht, Swarm nur in einfacher Form.
Wenn eine dieser Schwellen in Sicht ist, lohnt sich der Einstieg. Du musst dafür keinen Cluster mieten: Wie du Kubernetes auf dem eigenen Rechner startest, zeige ich in Kubernetes lokal: Cluster auf dem Rechner.
Kubernetes vs Docker Swarm: warum Swarm kaum noch eine Rolle spielt
Docker Swarm war Dockers eigene Antwort auf die Frage, wie Container über mehrere Maschinen laufen. Swarm ist in Docker eingebaut, mit docker swarm init in einer Minute aktiv und nutzt fast dieselbe Compose-Datei wie die Entwicklung. Das ist angenehm, und für ein kleines Team mit zwei bis drei Servern kann Swarm auch heute noch reichen.
Trotzdem empfehle ich Swarm für neue Projekte nicht. Nicht, weil es schlecht wäre, sondern weil das Ökosystem woanders lebt. Managed-Angebote der Cloud-Anbieter, Operatoren für Datenbanken, GitOps-Werkzeuge, Policy-Engines, Monitoring-Stacks, Zertifizierungen, Stellenanzeigen: Das alles ist auf Kubernetes ausgerichtet. Wer heute mit Swarm startet, baut auf einer Insel, und die Migration auf Kubernetes kommt später doch, nur mit mehr Altlast.
|
Docker Compose |
Docker Swarm |
Kubernetes |
| Läuft auf |
einer Maschine |
mehreren Maschinen |
mehreren Maschinen |
| Ausfall eines Servers |
Anwendung weg |
Container ziehen um |
Container ziehen um |
| Update ohne Ausfall |
nein |
ja, in einfacher Form |
ja, mit Health-Checks und Rollback |
| Automatische Skalierung nach Last |
nein |
nein |
ja |
| Konfiguration |
Compose-Datei |
Compose-Datei mit Erweiterungen |
Manifeste, Helm, Kustomize |
| Lernaufwand |
gering |
gering |
hoch |
| Ökosystem und Managed-Angebote |
nicht nötig |
klein |
sehr groß |
| Passt für |
Entwicklung, kleine Einzelserver |
kleine Cluster ohne Wachstum |
Produktion mit Anspruch an Verfügbarkeit und Skalierung |
Die Tabelle zeigt auch, was Kubernetes kostet: Lernaufwand. Dieser Preis ist real, und ich verschweige ihn in keinem Kundengespräch. Compose ist deshalb keine Notlösung, sondern für viele Projekte die richtige Antwort.
Der Weg von Compose zu Kubernetes
Wenn du eine Compose-Anwendung hast und die Schwelle erreicht ist, musst du nicht bei null anfangen. Deine Images bleiben, dein Dockerfile bleibt, deine Registry bleibt. Was sich ändert, ist die Beschreibung des Betriebs.
Für den ersten Schritt gibt es Kompose, ein Werkzeug aus dem Kubernetes-Projekt, das eine Compose-Datei in Kubernetes-Manifeste übersetzt. Das Ergebnis ist ein brauchbarer Startpunkt, aber kein fertiges Produktionsmanifest: Ressourcengrenzen, Health-Checks, Secrets und Ingress musst du selbst ergänzen. Ich nutze Kompose deshalb eher zum Lernen als für die Migration. An der Übersetzung siehst du, welches Compose-Konzept welchem Kubernetes-Objekt entspricht.
Danach empfehle ich drei Schritte, in dieser Reihenfolge. Zuerst ein lokaler Cluster, in dem du die erzeugten Manifeste ausprobierst. Dann ein Deployment und ein Service je Dienst von Hand, mit Requests, Limits und Readiness-Probe. Zuletzt wandern die Manifeste in ein Git-Repository, aus dem ein Werkzeug wie ArgoCD den Cluster versorgt. Ab da ist Docker in deinem Alltag wieder das, was es am Anfang war: der Ort, an dem Images entstehen.
Häufige Fragen
Brauche ich Docker, um Kubernetes zu nutzen?
Zum Betrieb nicht: Aktuelle Cluster nutzen containerd oder CRI-O als Laufzeit. Zum Bauen der Images brauchst du ein Werkzeug, und das ist meist Docker. Deine Images laufen unverändert in Kubernetes, weil beide dem OCI-Standard folgen.
Kann Kubernetes Docker ersetzen?
Nur den Teil, der Container betreibt. Das Bauen von Images, das lokale Entwickeln mit Compose und die Registry bleiben Docker-Aufgaben. Passender ist die Sicht: Kubernetes ersetzt Docker Compose und Docker Swarm im Betrieb, nicht Docker selbst.
Läuft eine Docker-Compose-Datei in Kubernetes?
Nicht direkt, Kubernetes liest eigene Manifeste. Mit Kompose übersetzt du eine Compose-Datei und erhältst Deployments und Services als Startpunkt. Für die Produktion ergänzt du danach Ressourcen, Probes und Secrets.
Ist Docker Swarm tot?
Nein, Swarm wird weiter mit Docker ausgeliefert und funktioniert. Aber das Ökosystem, die Managed-Angebote und die Weiterentwicklung finden bei Kubernetes statt. Für neue Projekte über eine Maschine hinaus würde ich nicht mehr auf Swarm setzen.
Was ist containerd?
containerd ist eine Container-Laufzeit, die Images zieht, entpackt und Container startet. Sie steckt im Docker-Daemon und läuft in Kubernetes eigenständig über die CRI-Schnittstelle. Für dich als Entwickler ändert sich dadurch nichts an Images oder Dockerfiles.
Wie du weitermachst
Die Entscheidung „Kubernetes vs Docker" ist in Wahrheit die Frage: Reicht eine Maschine, oder brauche ich einen Cluster? Wenn eine reicht, nimm Compose und freu dich über die Einfachheit. Wenn Ausfallsicherheit, viele Dienste oder ein hoher Release-Takt drücken, geh den Weg über einen lokalen Cluster und dann in die Produktion.
Wenn dir noch die Grundbegriffe fehlen, lies zuerst Kubernetes einfach erklärt. Wenn du den ersten Cluster starten willst, geht es mit Kubernetes lokal weiter.
Ausführlich mit allen Beispielen steht das in Kapitel 2 meines Buchs „Kubernetes: Das Praxisbuch für Entwickler und DevOps-Teams" (Rheinwerk). Mehr zum Buch.
