Kubernetes vs. Docker: Was die beiden wirklich unterscheidet

Kubernetes vs. Docker: Wo liegt der Unterschied?

Docker erzeugt und startet einzelne Container, also gebündelte Anwendungen samt ihrer Abhängigkeiten. Kubernetes verwaltet viele solcher Container über mehrere Server hinweg, verteilt sie, überwacht ihren Zustand und startet ausgefallene Instanzen neu. Docker beantwortet die Frage, wie eine Anwendung verpackt und ausgeführt wird, Kubernetes die Frage, wie viele davon wo laufen und was bei Störungen passiert.

Die Gegenüberstellung als Konkurrenz ist deshalb irreführend. Sinnvoller ist die Frage, ob eine Umgebung Orchestrierung überhaupt benötigt.

Was Docker leistet

Docker hat das Container-Format populär gemacht und gilt als De-facto-Standard für das Verpacken von Anwendungen. Ein Abbild wird einmal gebaut und läuft anschließend identisch auf jedem System, das Container ausführen kann. Die konzeptionellen Grundlagen dazu erklärt der Glossareintrag zur Containerisierung.

Für viele Vorhaben genügt genau das. Eine Anwendung, eine Datenbank, vielleicht ein Zwischenspeicher, gestartet über eine einzelne Beschreibungsdatei auf einem Server. Diese Konstellation deckt einen beträchtlichen Teil realer Fachanwendungen ab, ohne dass eine Orchestrierungsschicht nötig wäre.

Was Kubernetes leistet

Kubernetes setzt an, sobald Container nicht mehr auf einem einzelnen Server laufen. Es verteilt Instanzen über einen Verbund von Maschinen, prüft laufend deren Zustand, ersetzt ausgefallene Instanzen und rollt neue Versionen schrittweise aus. Die Details behandelt der Glossareintrag zu Kubernetes.

Der Nutzen ist am größten, wenn Ausfallsicherheit gefordert ist, Lasten stark schwanken oder viele Dienste gleichzeitig betrieben werden. Wo diese Bedingungen fehlen, überwiegt der Aufwand.

Kubernetes vs. Docker im Vergleich

Warum die beiden zusammengehören

In der Praxis werden Abbilder mit Docker gebaut und anschließend von Kubernetes ausgeführt. Kubernetes bringt keine eigene Bauwerkzeugkette mit, sondern erwartet fertige Container-Abbilder in einem standardisierten Format.

Missverständlich wirkt, dass Kubernetes seine ursprüngliche Docker-Laufzeitanbindung inzwischen abgelöst hat und andere Laufzeitumgebungen nutzt. Für die Praxis ändert das wenig, weil das Abbildformat standardisiert ist. Ein mit Docker gebautes Abbild läuft weiterhin unter Kubernetes.

Wann sich Kubernetes lohnt, und wann nicht

Die ehrliche Antwort lautet: seltener, als der Verbreitungsgrad des Begriffs vermuten lässt. Kubernetes rechnet sich, wenn mehrere der folgenden Punkte zutreffen.

• Die Anwendung muss auch beim Ausfall einzelner Server verfügbar bleiben.
• Die Last schwankt so stark, dass feste Kapazitäten entweder zu knapp oder zu teuer wären.
• Es werden viele Dienste betrieben, die unabhängig voneinander aktualisiert werden.
• Es gibt ein Team, das die Plattform dauerhaft betreibt und aktuell hält.

Fehlt vor allem der letzte Punkt, entsteht ein Risiko statt eines Gewinns. Eine nicht gepflegte Orchestrierungsschicht ist selbst eine Angriffsfläche und ein Betriebsrisiko. Für kleinere Installationen sind einfachere Wege oft die bessere Wahl, ein Vergleich der Orchestrierungswerkzeuge findet sich im Beitrag zu Docker Swarm und Kubernetes.

Wo Docker Compose in das Bild passt

Zwischen einem einzelnen Container und einer vollwertigen Orchestrierung liegt eine Stufe, die in der Diskussion oft fehlt. Docker Compose beschreibt mehrere zusammengehörige Container in einer Datei und startet sie gemeinsam, allerdings auf einem einzelnen Host.

Für Entwicklungsumgebungen ist das der Normalfall. Auch im Produktivbetrieb reicht es aus, solange kein Ausfall einzelner Server abgefangen werden muss. Wer diese Stufe überspringt und direkt zur Orchestrierung greift, kauft sich Komplexität ein, die im konkreten Fall vielleicht nie gebraucht wird.

Die Abgrenzung lautet damit nicht Kubernetes vs. Docker, sondern eher: ein Host oder mehrere. Erst wenn die Antwort mehrere lautet und Ausfallsicherheit gefordert ist, beginnt der Bereich, für den Kubernetes gebaut wurde.

Häufige Missverständnisse

Rund um Kubernetes vs. Docker halten sich einige Annahmen, die zu falschen Entscheidungen führen.

• Kubernetes ersetzt Docker nicht. Die Abbilder werden weiterhin im selben Format gebaut, Kubernetes führt sie lediglich aus und verwaltet sie.
• Kubernetes macht Anwendungen nicht automatisch ausfallsicher. Es startet ausgefallene Instanzen neu. Ob die Anwendung selbst mehrfach parallel laufen kann, entscheidet ihre Architektur, nicht die Plattform.
• Der Aufwand endet nicht mit der Einführung. Eine Orchestrierung ist Software mit eigenem Lebenszyklus, eigenen Sicherheitsaktualisierungen und eigenen Ausfallszenarien.
• Größer ist nicht sicherer. Jede zusätzliche Schicht vergrößert die Angriffsfläche. Eine gepflegte kleine Installation ist einer ungepflegten großen deutlich überlegen.

Was das für die Auswahl bedeutet

Sinnvoll ist ein Vorgehen in Stufen. Zuerst wird die Anwendung containerisiert, was allein schon Reproduzierbarkeit und Portabilität bringt. Ob eine Orchestrierung folgt, entscheidet sich danach anhand konkreter Anforderungen an Verfügbarkeit und Änderungsfrequenz.

Diese Reihenfolge hat einen praktischen Vorteil. Containerisierte Anwendungen lassen sich später ohne größere Umbauten unter eine Orchestrierung stellen. Umgekehrt lässt sich eine vorschnell eingeführte Plattform nur schwer wieder zurücknehmen. Ob Container im konkreten Fall überhaupt der richtige Weg sind, behandelt der Beitrag zu Container und virtuellen Maschinen.

Wie sich der Einsatz von Containern im Unternehmen rechnet und worauf beim sicheren Betrieb zu achten ist, vertieft die Kompetenzseite zu Docker Containern.

Was der Umstieg organisatorisch bedeutet

Wer von einzelnen Containern zu einer Orchestrierung wechselt, verändert nicht nur die Technik, sondern die Zuständigkeiten. Aus einem Server, der von der Systemadministration betreut wird, wird eine Plattform mit eigenem Lebenszyklus.

Drei Punkte werden dabei regelmäßig unterschätzt.

• Aktualisierungszyklen. Kubernetes wird häufig weiterentwickelt, ältere Versionen erhalten nur begrenzt Sicherheitsaktualisierungen. Wer die Plattform betreibt, muss regelmäßig aktualisieren, auch ohne fachlichen Anlass.
• Netzwerk und Speicher. Beides funktioniert innerhalb einer Orchestrierung anders als auf einem einzelnen Server. Dauerhafter Speicher für Datenbanken erfordert eine bewusste Entscheidung, er ergibt sich nicht von selbst.
• Fehlersuche. Wenn eine Anwendung über mehrere Instanzen verteilt läuft, reicht der Blick in eine einzelne Protokolldatei nicht mehr aus. Zentrale Protokollierung und Überwachung gehören zur Grundausstattung, nicht zur Kür.

Diese Punkte sprechen nicht gegen eine Orchestrierung. Sie zeigen aber, dass die Entscheidung eine Personalentscheidung ist und nicht allein eine technische.

Fazit

Kubernetes vs. Docker ist keine Entweder-oder-Frage, sondern eine Frage der Betriebsebene. Docker verpackt und startet Anwendungen, Kubernetes hält viele davon über mehrere Server hinweg am Laufen. Wer beides gleichsetzt, entscheidet an der falschen Stelle. Die eigentliche Frage lautet, ob Verfügbarkeit, Last und Änderungsfrequenz eine Orchestrierung rechtfertigen und wer sie dauerhaft betreibt. Bei dieser Einordnung und beim laufenden Betrieb unterstützt TenMedia im Rahmen von Softwarebetrieb und Wartung.