Docker vs. Kubernetes
Zwei Begriffe, die praktisch immer gemeinsam fallen, aber unterschiedliche Ebenen der Container-Infrastruktur betreffen - was jedes Werkzeug tatsächlich leistet.
Docker und Kubernetes werden so oft zusammen genannt, dass sie in der öffentlichen Wahrnehmung fast wie ein einziges Werkzeug oder sogar wie Konkurrenten wirken. Tatsächlich lösen sie unterschiedliche Probleme auf unterschiedlichen Ebenen - und ihr Verhältnis zueinander hat sich über die Jahre technisch sogar verschoben.
1. Was Docker macht
Docker kümmert sich um einen einzelnen Container: Es verpackt eine Anwendung samt Abhängigkeiten in ein Image und startet daraus eine isolierte, portable Laufzeitumgebung. Die Isolation basiert auf Betriebssystemfunktionen des Linux-Kernels (Namespaces und Control Groups), nicht auf einer vollständigen virtuellen Maschine - deshalb starten Container in Sekunden statt Minuten und teilen sich den Kernel des Host-Systems. Docker beantwortet die Frage “Wie baue und starte ich eine einzelne containerisierte Anwendung zuverlässig und reproduzierbar?”.
2. Was Kubernetes macht
Kubernetes setzt eine Ebene darüber an: Es orchestriert potenziell Hunderte oder Tausende Container über viele Server (Nodes) hinweg - startet ausgefallene Container automatisch neu, skaliert bei steigender Last, verteilt Last gleichmäßig über mehrere Instanzen und ermöglicht Updates ohne Ausfallzeit. Die kleinste verwaltete Einheit in Kubernetes ist dabei nicht der einzelne Container, sondern der Pod - eine Gruppe von einem oder mehreren eng zusammengehörenden Containern, die gemeinsam geplant und skaliert werden. Kubernetes beantwortet die Frage “Wie betreibe ich viele Container zuverlässig und mit möglichst wenig manuellem Eingriff im großen Maßstab?”.
3. Kubernetes’ Beziehung zu Docker hat sich verschoben
Ein Detail, das häufig für Verwirrung sorgt: Kubernetes hat lange Zeit Docker direkt als Container-Runtime verwendet, um Container tatsächlich zu starten. Seit Version 1.24 nutzt Kubernetes dafür standardmäßig nicht mehr Docker selbst, sondern Runtimes, die die offene Container Runtime Interface (CRI) implementieren, etwa containerd. Für die meisten Nutzer ändert das praktisch nichts - mit Docker gebaute Images funktionieren unverändert in Kubernetes weiter, weil das Image-Format (OCI) unabhängig von der konkreten Runtime standardisiert ist. Es zeigt aber, dass Docker als Werkzeug zum Bauen von Containern und die Runtime, die sie ausführt, zwei getrennte Dinge sind, die in der Praxis oft vermischt werden.
4. Docker Compose als Zwischenschritt
Zwischen einem einzelnen Docker-Container und einem vollständigen Kubernetes-Cluster gibt es einen häufig übersehenen Zwischenschritt: Docker Compose. Damit lassen sich mehrere zusammengehörende Container (etwa eine Anwendung, eine Datenbank und ein Cache) auf einem einzelnen Server gemeinsam definieren und starten. Compose orchestriert also im kleinen Maßstab auf einer einzelnen Maschine, ohne die Selbstheilungs-, Skalierungs- und Mehr-Server-Fähigkeiten von Kubernetes zu bieten. Für viele kleinere bis mittlere Projekte ist Compose der praktisch ausreichende Mittelweg, bevor Kubernetes überhaupt in Betracht gezogen werden muss.
5. Wann Docker (oder Docker Compose) allein ausreicht
Für kleine Projekte, einzelne Anwendungen oder lokale Entwicklungsumgebungen ist Docker allein häufig völlig ausreichend. Auch für produktive Anwendungen mit überschaubarer Last, die auf einem oder wenigen Servern laufen, deckt Docker Compose den Orchestrierungsbedarf oft ab. Der zusätzliche Betriebsaufwand und die Lernkurve von Kubernetes - eigenes Vokabular, ein Cluster aus mehreren Komponenten, laufende Wartung - lohnen sich in solchen Fällen selten.
6. Wann Kubernetes sinnvoll wird
Kubernetes wird relevant, sobald eine Anwendung aus vielen zusammenspielenden Diensten besteht, hohe Verfügbarkeit über mehrere Server hinweg erfordert oder stark schwankende Lastspitzen automatisiert abfedern muss - etwa durch automatisches Hoch- und Herunterskalieren einzelner Dienste. Verwaltete Kubernetes-Angebote großer Cloud-Anbieter nehmen einen Teil des Betriebsaufwands ab, indem sie die Kernkomponenten des Clusters (die sogenannte Control Plane) selbst betreiben - die Notwendigkeit, die Konzepte von Kubernetes zu verstehen, entfällt dadurch aber nicht. Für die meisten kleineren Websites und Anwendungen ist der Schwellenwert, ab dem sich dieser Aufwand lohnt, in der Praxis noch nicht erreicht.
7. Häufige Fehler
- Docker und Kubernetes als konkurrierende Alternativen behandeln, statt als Werkzeuge auf unterschiedlichen Ebenen, die zusammenspielen.
- Kubernetes einführen, bevor die Anwendung tatsächlich mehrere Instanzen oder Dienste umfasst, die orchestriert werden müssen - und damit Komplexität ohne entsprechenden Nutzen aufbauen.
- Annehmen, dass ein mit Docker gebautes Image automatisch “Kubernetes-Kompetenz” bedeutet - Orchestrierung, Netzwerk- und Storage-Konzepte in Kubernetes sind ein eigenständiges Themenfeld.
- Den Betriebsaufwand eines selbstverwalteten Kubernetes-Clusters unterschätzen, auch wenn ein verwaltetes Angebot genutzt wird.
8. Wie prüfst du, was du tatsächlich brauchst
Ein einfacher Realitätscheck vor der Entscheidung: Läuft die Anwendung aktuell auf einem einzelnen Server, oder wird sie es in absehbarer Zeit tun? Gibt es tatsächlich mehrere Dienste, die unabhängig voneinander skalieren oder ausfallen können sollen? Existiert bereits ein Lastspitzen-Problem, das ein Load Balancer allein nicht mehr löst? Wird die Antwort auf diese Fragen mehrheitlich “nein” oder “noch nicht”, ist Kubernetes in der Regel eine Lösung für ein Problem, das noch nicht existiert.
9. Entscheidungsrahmen
- Läuft alles auf einem einzelnen Server, ohne absehbaren Bedarf für mehrere? → Docker (ggf. mit Docker Compose) reicht aus.
- Gibt es mehrere zusammenspielende Container auf einer Maschine, aber keinen Bedarf an Mehr-Server-Betrieb? → Docker Compose statt Kubernetes.
- Muss die Anwendung über mehrere Server hinweg automatisch skalieren und sich selbst heilen? → Kubernetes wird relevant.
- Fehlt intern die Erfahrung, ein Kubernetes-Cluster zu betreiben? → Verwaltetes Kubernetes-Angebot in Betracht ziehen, statt selbst zu betreiben.
- Ist der aktuelle Bedarf unklar oder noch im Aufbau? → Mit Docker starten und erst bei tatsächlichem, gemessenem Orchestrierungsbedarf zu Kubernetes wechseln - der Umstieg ist später möglich, die vorzeitige Komplexität lässt sich nicht rückgängig machen.