Docker und Kubernetes: Was ist der Unterschied und was passt wann?

Was ist der Unterschied zwischen Docker und Kubernetes?

Der Unterschied zwischen Docker und Kubernetes liegt in der Ebene: Docker ist ein Werkzeugkasten, der Ihre Anwendung als Container Image verpackt und auf einem Rechner ausführt. Kubernetes ist dagegen eine Plattform zur Orchestrierung, die diese Container auf viele Server verteilt, skaliert, ausgefallene Container ersetzt und Updates steuert. Die beiden ergänzen sich also.

In der Praxis stellen uns vor allem zwei Gruppen diese Frage. Zum einen Website und Shopbetreiber, deren Entwickler den Umstieg auf Kubernetes vorschlagen. Zum anderen Entwickler, die Docker gelernt haben und den nächsten Schritt suchen. Beide Gruppen beschäftigt dieselbe Frage: Was bringt uns die zusätzliche Komplexität, und was kostet sie?

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hostinganbieter. Deshalb stützen wir diesen Artikel auf die offizielle Dokumentation von Kubernetes und Docker und nennen zu jeder technischen Aussage eine Quelle. Die Grundlagen finden Sie in unserem Leitfaden zu Docker und Containern, die Installation in unserer Anleitung zu Minikube und k3s. Hier wiederholen wir das nicht, sondern konzentrieren uns auf die Unterschiede, die Ihre Entscheidung erleichtern.

Was genau leistet Docker?

Mit Docker verpacken Sie eine Anwendung samt Abhängigkeiten in ein einziges Image und starten dieses Image danach in jeder Umgebung auf dieselbe Weise. Code, der auf dem Laptop eines Entwicklers läuft, verhält sich auf dem Testserver und im Livebetrieb genauso. Kurz gesagt beseitigt Docker den Großteil des Problems „bei mir lief es doch“.

Wenn von Docker die Rede ist, meinen viele mehrere Bausteine:

• Bau von Images: Docker liest die Schritte im Dockerfile und erzeugt ein Image aus Schichten.
• Ausführung: Die Docker Engine startet, stoppt und entfernt Container.
• Verteilung: Docker schiebt Images in eine Registry und holt sie von dort.
• Lokale Dienste: Docker Compose startet mehrere Container aus einer einzigen Datei.

Der Fokus von Docker liegt auf einem einzelnen Rechner. Natürlich laufen dort zudem Dutzende Container. Fällt der Server allerdings aus, verschiebt Docker die Arbeitslast nicht von selbst auf einen anderen Server. Für kleine und mittlere Projekte ist das trotzdem selten ein Problem, denn ein gut überwachter Server mit sauberen Backups reicht lange aus.

Zudem verkleinert Docker den Abstand zwischen Entwicklung und Livebetrieb. Ein neuer Entwickler startet das gesamte Projekt mit wenigen Befehlen lokal. Dadurch schrumpfen die Stunden, die sonst in Installationsanleitungen fließen. Außerdem landen in Test und Livebetrieb dieselben Images, also sinkt das Risiko unerwarteter Fehler.

Was genau leistet Kubernetes?

Die offizielle Dokumentation beschreibt Kubernetes als portable, erweiterbare Open Source Plattform zur Verwaltung containerisierter Arbeitslasten und Dienste. Sie unterstützt deklarative Konfiguration und Automatisierung. Quelle: Kubernetes Überblick.

Das Wort „deklarativ“ ist hier also entscheidend. Sie sagen Kubernetes: „Von dieser Anwendung sollen drei Kopien laufen.“ Kubernetes beobachtet dann laufend den Istzustand und nähert ihn diesem Ziel an. Stirbt zum Beispiel eine Kopie, startet Kubernetes eine neue. Fällt ein Server aus, verschiebt es die Arbeit auf gesunde Server.

Dieselbe Seite nennt unter anderem diese Fähigkeiten:

• Service Discovery und Lastverteilung.
• Orchestrierung von Speicher.
• Automatische Rollouts und Rollbacks.
• Automatische Platzierung nach Ressourcenbedarf.
• Selbstheilung.
• Verwaltung von Secrets und Konfiguration.
• Horizontale Skalierung.

Beachten Sie allerdings: Kubernetes baut keine Images und kompiliert keinen Quellcode. Die Dokumentation sagt das deutlich, denn Kubernetes ist kein Werkzeug für CI/CD. Das Image erstellen Sie daher weiterhin mit Docker oder einem ähnlichen Werkzeug.

Außerdem betont die Seite, dass Kubernetes kein klassisches PaaS ist. Das heißt, Kubernetes liefert keine Datenbank, keinen Cache und keine Nachrichtenwarteschlange; diese Bausteine wählen Sie selbst aus. Kubernetes gibt Ihnen also ein starkes Fundament, das restliche Haus baut Ihr Team.

Auf welcher Ebene arbeiten die beiden Werkzeuge?

Am leichtesten merken Sie sich den Unterschied, wenn Sie die Arbeit in Ebenen teilen. Der Beitrag „Don't Panic: Kubernetes and Docker“ im Kubernetes Blog beschreibt Docker nicht als einzelnes Teil, sondern als kompletten Technologiestapel. Laut demselben Beitrag nutzt Docker intern containerd, um Container auszuführen. Quelle: offizieller Kubernetes Blog.

Mit diesem Wissen sieht der Stapel so aus:

1. Ebene der Images: Sie verpacken Ihre Anwendung. Hier arbeiten Docker und das Dockerfile.
2. Ebene der Runtime: Sie führen das Image als echten Container aus. Hier arbeitet eine Container Runtime wie containerd oder CRI-O.
3. Orchestrierungsebene: Sie verwalten viele Container auf vielen Servern. Diese Aufgabe übernimmt Kubernetes.

Ein Bild hilft: Docker ist der Kran, der Waren in einen genormten Schiffscontainer lädt. Kubernetes ist dagegen die Hafenverwaltung, die entscheidet, welcher Container auf welches Schiff kommt und wohin die Ladung geht, wenn ein Schiff ausfällt. Deshalb ist die Frage „Docker oder Kubernetes?“ meist falsch gestellt. Die eigentliche Frage lautet, ob Sie die Orchestrierungsebene heute schon brauchen.

Wie sehen Docker und Kubernetes im direkten Vergleich aus?

Die folgende Tabelle fasst Docker und Kubernetes in den Punkten zusammen, die bei der Entscheidung am meisten zählen. Lesen Sie die Spalte Docker als Docker Engine plus Compose auf einem Server.

Die Zeilen zu Docker decken den Swarm Modus nicht ab; dazu weiter unten mehr. Zudem ist die Tabelle keine Rangliste der Qualität. Zum Beispiel erklärt die Zeile zum Wartungsaufwand, warum Kubernetes für kleine Teams oft zu viel ist.

Führt Kubernetes Container mit Docker aus?

In aktuellen Kubernetes Versionen nicht. Kubernetes spricht mit der Container Runtime über eine Schnittstelle namens Container Runtime Interface (CRI). Die Docker Engine unterstützt diese Schnittstelle allerdings nicht direkt. Deshalb setzte Kubernetes früher eine Brücke namens dockershim dazwischen.

Das Kubernetes Projekt hat diese Brücke entfernt. Laut der offiziellen Dockershim FAQ kam die Ankündigung mit Version v1.20, die tatsächliche Entfernung dann mit Version v1.24. Quelle: Kubernetes Dockershim FAQ.

Heute finden Sie auf Kubernetes Knoten meist eine dieser Runtimes:

• containerd: dieselbe Runtime, die auch Docker intern nutzt.
• CRI-O: eine CRI Runtime, die speziell für Kubernetes entstanden ist.
• Docker Engine mit cri-dockerd: ein separater Adapter für Teams, die bei der Docker Engine bleiben möchten.

Daraus folgt: Kubernetes hängt nicht von Docker ab. Gleichzeitig führt Kubernetes Images, die Sie mit Docker bauen, problemlos aus. Genau diese Unterscheidung ist die Quelle des Missverständnisses im nächsten Abschnitt.

Warum betrifft Sie das? Weil die Aussage eines Anbieters „unsere Kubernetes Knoten nutzen containerd“ nicht bedeutet, dass Ihre Docker Images scheitern. Die richtige Frage lautet, ob Ihre Images dem OCI Standard folgen; mit Docker gebaute Images tun das bereits.

Funktioniert Docker nach dem Ende von dockershim nicht mehr?

Doch, Docker funktioniert weiterhin. Das ist dennoch einer der hartnäckigsten Irrtümer im Netz. Das Ende von dockershim hat nur geändert, welche Runtime auf einem Kubernetes Knoten die Container startet. Docker selbst, das Bauen von Images und der Einsatz auf einem einzelnen Server laufen wie bisher.

Die offiziellen Kubernetes Quellen halten drei Punkte fest:

• Mit Docker gebaute Images laufen weiter, denn sie folgen dem OCI Standard und jede CRI Runtime kann sie ausführen.
• Sie können Images weiterhin mit dem Befehl docker build erstellen.
• Die Änderung betrifft Betreiber von Clustern, nicht Entwickler; den Austausch der Runtime auf den Knoten erledigt die Infrastruktur.

Für die Praxis heißt das: Als Entwickler schreiben Sie weiter Dockerfiles, bauen Images und schieben sie in eine Registry. Betreiben Sie einen eigenen Cluster, prüfen Sie dagegen die Runtime auf Ihren Knoten. Nutzen Sie einen verwalteten Kubernetes Dienst, übernimmt der Anbieter diesen Wechsel in der Regel. Trotzdem empfehlen wir, die Release Notes Ihres Anbieters zu lesen.

Wo ordnet sich Docker Compose ein?

Mit Docker Compose beschreiben Sie eine Anwendung aus mehreren Containern in einer einzigen Datei im YAML Format. Laut der offiziellen Docker Dokumentation definieren Sie darin die Rechenbausteine als Services, die Kommunikation zwischen ihnen als Netzwerke und dauerhafte Daten als Volumes. Quelle: Docker Compose Anwendungsmodell.

Ein einfaches Beispiel beschreibt eine Webanwendung und ihre Datenbank in derselben Datei:

services:
  web:
    image: example/web:1.0
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: postgres
    volumes:
      - dbdata:/var/lib/postgresql/data
volumes:
  dbdata:

Danach starten Sie beide Dienste gemeinsam mit docker compose up -d. Details zum Betrieb von Datenbanken in Containern finden Sie in unserer Anleitung PostgreSQL und MySQL in Docker einrichten.

Für die meisten kleinen und mittleren Projekte deckt Compose den Großteil der Orchestrierung auf einem Server ab. Deshalb raten wir: Bevor Sie über Kubernetes nachdenken, schreiben Sie konkret auf, warum Compose nicht mehr reicht.

Ist Docker Swarm eine Alternative zu Kubernetes?

In gewissem Maß schon. Die Docker Dokumentation beschreibt den Swarm Modus als fortgeschrittene Funktion, mit der Sie einen Cluster aus Docker Engines direkt verwalten. Mit Swarm nutzen Sie also mehrere Server als einen Cluster, ohne zusätzliche Software für die Orchestrierung. Quelle: Dokumentation zum Docker Swarm Modus.

Laut offizieller Dokumentation bietet Swarm unter anderem:

• Einen deklarativ beschriebenen Sollzustand, den der Manager laufend herstellt.
• Eine Anzahl von Replikaten pro Dienst, die Sie hoch und herunter skalieren.
• Overlay Netzwerke über mehrere Hosts hinweg.
• Service Discovery, Lastverteilung und Rolling Updates.

Swarm ist somit eine schlankere Umsetzung der Grundideen von Kubernetes. Weil die Definitionen stark an Compose Dateien erinnern, findet sich ein Team mit Docker Wissen schnell zurecht. Kubernetes hat dagegen ein deutlich größeres Ökosystem, mehr Spielraum für Erweiterungen und viel mehr verwaltete Angebote. Schauen Sie daher bei der Entscheidung nicht nur auf heute, sondern auch darauf, welches Werkzeug Ihr Team langfristig betreuen kann.

Wie unterscheiden sich Docker und Kubernetes beim Skalieren?

Beim Skalieren unterscheiden sich Docker und Kubernetes vor allem darin, wer entscheidet. Mit Docker auf einem Server ändern Sie die Anzahl der Kopien selbst, und alle Kopien teilen sich die Ressourcen dieses Rechners. Ist der Rechner voll, wechseln Sie auf einen größeren Server; das nennen wir vertikale Skalierung.

Kubernetes stellt dagegen die horizontale Skalierung in den Mittelpunkt. Laut Dokumentation skalieren Sie Ihre Anwendung per Befehl, über eine Oberfläche oder automatisch nach CPU Auslastung. Zum Beispiel ändern Sie die Anzahl der Kopien eines Deployments mit diesem Befehl:

kubectl scale deployment/web --replicas=3

Kubernetes verteilt die neuen Kopien dann auf passende Knoten im Cluster. Dabei berücksichtigt es den CPU und Speicherbedarf, den jeder Container anfordert. Folglich stoßen Lastspitzen nicht an die Grenze eines einzelnen Servers; Sie erweitern die Kapazität, indem Sie dem Cluster Knoten hinzufügen.

Allerdings müssen wir hier ehrlich sein. Automatische Skalierung funktioniert nur, wenn Ihre Anwendung als mehrere Kopien laufen kann. Eine Anwendung, die Sitzungen im Arbeitsspeicher hält und Dateien auf die lokale Platte schreibt, skaliert in Kubernetes nicht; zunächst müssen Sie die Architektur anpassen. Die Seite des Cachings behandeln wir in unserem Beitrag Caching mit Redis und Memcached.

Wie funktioniert die Selbstheilung in beiden Werkzeugen?

Docker bietet auf einem Server eine einfache Form der Wiederherstellung: die Restart Policy. Beendet sich ein Container unerwartet, startet Docker ihn auf demselben Rechner neu. Für einfache Abstürze reicht das oft aus. Fällt jedoch der Server selbst aus, stehen auch alle Container darauf still.

Die Selbstheilung von Kubernetes geht weiter. Laut offizieller Dokumentation erledigt Kubernetes Folgendes:

• Es startet fehlgeschlagene Container neu.
• Bei Bedarf ersetzt es Container durch neue.
• Es beendet Container, die nicht auf Ihre Gesundheitsprüfung antworten.
• Erst wenn Container bereit sind, leitet es Verkehr zu ihnen.

Ist ein Knoten nicht mehr erreichbar, erstellt Kubernetes dessen Arbeitslast auf gesunden Knoten neu. Somit bedeutet der Ausfall eines einzelnen Servers nicht, dass Ihre gesamte Website offline geht.

Dieser Schutz ist allerdings nicht gratis. Sie brauchen mindestens zwei Knoten, besser mehr, dazu saubere Gesundheitsprüfungen und einen durchdachten Umgang mit dauerhaften Daten. Ob Ihre Website von außen erreichbar ist, prüfen Sie schnell mit unserem Werkzeug Ist die Seite down.

Wie unterscheiden sich Rolling Updates und Rollbacks?

Auf einem einzelnen Server läuft ein Update mit Docker meist so ab: Sie holen das neue Image, stoppen den alten Container und starten den neuen. Mit Compose schrumpft das auf einen Befehl. Allerdings kann zwischen dem Stopp des alten und der Bereitschaft des neuen Containers eine kurze Unterbrechung entstehen. Um diese ganz zu vermeiden, brauchen Sie zusätzliche Bausteine, zum Beispiel einen Reverse Proxy und zwei Kopien.

In Kubernetes ist das Rolling Update dagegen die Standardmethode. Die Dokumentation beschreibt es als Annäherung des Istzustands an den Sollzustand mit kontrollierter Geschwindigkeit. Kubernetes startet zunächst neue Kopien und beendet die alten erst, wenn die neuen bereit sind. Macht die neue Version Probleme, kehren Sie zur vorherigen zurück:

kubectl rollout undo deployment/web

Das lohnt sich vor allem für Teams, die mehrmals täglich neue Versionen ausliefern. Andererseits genügt einer Unternehmenswebsite mit wöchentlichen Updates und wenig Nachtverkehr oft ein kurzes Wartungsfenster. Kurz gesagt hängt der Wert von Deployments ohne Ausfallzeit von Ihrem Verkehrsmuster ab.

Für ein sauberes Release Management braucht es außerdem Ordnung im Code. Dazu empfehlen wir unsere Anleitung zu Git und GitHub.

Wie unterscheiden sich Service Discovery und Lastverteilung?

Besteht eine Anwendung aus mehreren Diensten, müssen diese einander finden. Docker Compose löst das auf einem Server einfach: Dienste im selben Compose Netzwerk erreichen sich über ihren Dienstnamen. Zum Beispiel verbindet sich der Webdienst über den Namen „db“ mit der Datenbank.

In Kubernetes wandern Container dagegen ständig. Eine Kopie stoppt auf einem Knoten und startet dann auf einem anderen mit neuer IP Adresse. Deshalb nutzt Kubernetes das Service Objekt als stabilen Einstiegspunkt. Laut Dokumentation macht Kubernetes Container über einen DNS Namen oder eine eigene IP Adresse erreichbar und verteilt bei hoher Last den Verkehr auf die Kopien.

Daraus ergibt sich in der Praxis:

• Ein Server und wenige Dienste: Das Compose Netzwerk reicht, zusätzliche Bausteine brauchen Sie nicht.
• Viele Server und häufig wechselnde Kopien: Das Service Modell von Kubernetes erleichtert die Arbeit deutlich.
• Verkehr von außen: In Kubernetes richten Sie zusätzlich einen Load Balancer oder eine Ingress Schicht ein.

Planen Sie Microservices, spielt auch die Wahl der Sprache eine Rolle. Das behandeln wir in unserem Vergleich von Python und Go für Microservices.

Wie unterschiedlich sind Lernkurve und Wartungsaufwand?

Für den Einstieg in Docker genügen wenige Begriffe: Image, Container, Volume, Netzwerk und die Compose Datei. Damit baut ein Entwickler folglich in kurzer Zeit eine funktionierende Umgebung. Wünschen Sie eine grafische Oberfläche zur Verwaltung, hilft Ihnen unsere Anleitung zur Installation von Portainer.

Bei Kubernetes wird die Liste deutlich länger. Pod, Deployment, ReplicaSet, Service, Ingress, ConfigMap, Secret, PersistentVolume, Namespaces und RBAC sind nur einige davon. Zudem braucht der Cluster selbst Pflege:

• Upgrades der Kubernetes Version und Prüfung der Kompatibilität.
• Backups und Verfügbarkeit der Control Plane.
• Sicherheitsupdates für die Knoten.
• Monitoring, Sammeln von Logs und Alarmierung.
• Verwaltung von Netzwerkplugin und Speichertreiber.

Die offizielle Dokumentation weist außerdem darauf hin, dass Kubernetes keine feste Lösung für Logging, Monitoring oder Alarmierung vorgibt. Das heißt, diese Bausteine wählen, installieren und pflegen Sie selbst. Betrachten Sie Kubernetes daher nicht als „einmal einrichten, danach läuft es von allein“. Hat niemand im Team Zeit für diese Arbeit, ist ein verwalteter Dienst oder eine schlankere Lösung die klügere Wahl.

Ist Kubernetes im Betrieb teurer?

In den meisten Fällen ja, zumindest am Anfang. Wir empfehlen, die Kosten in zwei Posten zu denken: Infrastruktur und Arbeitszeit. Der zweite Posten wiegt dabei meist schwerer, denn Zeit ist knapp.

Auf der Seite der Infrastruktur ergibt Kubernetes erst mit mehreren Knoten Sinn. Einen Cluster mit nur einem Knoten können Sie zwar betreiben, dann verlieren Sie allerdings den wertvollsten Teil der Selbstheilung, nämlich die Robustheit gegen Serverausfälle. Zudem verbrauchen Monitoring, Log Sammlung und Load Balancer ebenfalls Ressourcen.

Auf der Seite der Arbeitszeit kosten Pflege des Clusters, Upgrades und Fehlersuche regelmäßig Zeit. Ein Entwickler, der einen Server mit Docker und Compose betreut, erledigt das oft neben der täglichen Arbeit. Mit Kubernetes steigt dieser Aufwand dagegen spürbar.

Mit wachsender Größe kann sich das Verhältnis allerdings verschieben. Ab einem gewissen Punkt macht der Aufwand, viele Dienste von Hand zu betreuen, die Automatisierung von Kubernetes günstiger. Die richtige Frage lautet daher nicht „Was ist billiger?“, sondern „Was kostet in unserer Größe insgesamt weniger Arbeit?“. Schätzen Sie dafür die Stunden Ihres Teams ehrlich ein.

Welches Projekt braucht welches Werkzeug?

Wir empfehlen, nach dem echten Bedarf Ihres Unternehmens zu entscheiden, nicht nach der Beliebtheit einer Technologie. Die folgende Liste ist ein Startrahmen aus der Praxis, keine feste Regel:

• Unternehmenswebsite, Blog, kleiner Onlineshop: Shared Hosting oder ein einzelner VPS reicht oft; Container sind nicht einmal zwingend.
• Webanwendung mit wenigen Diensten auf einem Server: Docker und Compose sind die ausgewogenste Wahl.
• Projekt über mehrere Server, aber mit kleinem Team: Prüfen Sie zunächst Swarm oder eine verwaltete Plattform.
• Viele Dienste, viele Server, Hochverfügbarkeit und häufige Releases: Hier schafft Kubernetes echten Mehrwert.

Sind Sie beim Servertyp unsicher, ist unser Beitrag VPS oder Cloud Server ein guter Startpunkt. Allgemeine Kriterien für Hosting haben wir in Webhosting auswählen gesammelt.

Denken Sie außerdem daran: Ein Projekt, das mit Docker startet, kann später zu Kubernetes wechseln. Ihre Images laufen in beiden Umgebungen, also bedeutet der Wechsel keinen Neubau.

Wann sollten Sie Kubernetes nicht selbst einrichten?

Die Stärken von Kubernetes haben wir beschrieben; jetzt kommt der ehrliche Teil. In diesen Fällen raten wir davon ab, Kubernetes selbst zu betreiben:

• Ein einzelner Server trägt Ihren gesamten Traffic problemlos.
• Niemand im Team kann regelmäßig Zeit für die Pflege des Clusters einplanen.
• Ihre Anwendung hält Sitzungen im Speicher und schreibt auf die lokale Platte, kann also noch nicht als mehrere Kopien laufen.
• Ihr eigentliches Problem ist eine langsame Datenbankabfrage oder eine überladene Seite.

Vor allem der letzte Punkt ist wichtig. Eine langsame Website ist oft wegen der Anwendung langsam, nicht wegen der Infrastruktur. In diesem Fall löst Kubernetes nichts; stattdessen haben Sie dasselbe Problem in einer teureren und komplexeren Umgebung.

Zudem ist ein Kubernetes Cluster im Internet eine ernste Verantwortung für die Sicherheit. Das Risiko steigt, wenn Zugriff auf den API Server, Umgang mit Secrets oder rollenbasierte Rechte nicht stimmen. Fehlt dieses Wissen im Team, ist es sicherer, die Aufgabe Ihrem Hostinganbieter oder einem verwalteten Kubernetes Dienst zu überlassen.

Wie verwalten Sie dauerhafte Daten in beiden Umgebungen?

Container sind von Natur aus flüchtig; Sie können sie jederzeit löschen und neu erstellen. Deshalb ist die Frage, wo dauerhafte Daten wie Datenbank und hochgeladene Dateien liegen, bei beiden Werkzeugen die wichtigste Entscheidung.

In Docker speichern Sie dauerhafte Daten in Volumes. Ein Volume bleibt auf der Platte des Servers, auch wenn Sie den Container löschen. Auf einem einzelnen Server ist das einfach und übersichtlich. Allerdings liegen die Backups komplett bei Ihnen; fällt die Platte aus, ist auch das Volume weg.

In Kubernetes kommt dann die Fähigkeit ins Spiel, die die Dokumentation „Orchestrierung von Speicher“ nennt. Sie binden lokale Platten, Speicher eines Cloud Anbieters oder Netzwerkspeicher automatisch an Container an. Diese Flexibilität ist also stark. Wandert ein Pod jedoch auf einen anderen Knoten, müssen auch seine Daten dort erreichbar sein. Wählen Sie Ihren Speicheransatz daher vor dem Aufbau des Clusters.

In der Praxis halten viele Teams die Datenbank außerhalb von Kubernetes in einem verwalteten Datenbankdienst und betreiben im Cluster nur zustandslose Dienste. Somit vereinfacht sich die Pflege des Clusters. Egal welchen Weg Sie wählen: Testen Sie regelmäßig, ob sich Ihre Backups wirklich wiederherstellen lassen.

Wann lohnt sich verwaltetes Kubernetes?

Große Cloud Anbieter und manche Hostinganbieter bieten verwaltetes Kubernetes an. In diesem Modell betreibt der Anbieter die Control Plane, also das Gehirn des Clusters. Sie kümmern sich dann nur um Ihre Anwendungen und Ihren Node Pool.

Ein verwalteter Dienst bringt Ihnen Folgendes:

• Einrichtung, Backups und Verfügbarkeit der Control Plane liegen beim Anbieter.
• Versionsupgrades erledigen Sie meist in wenigen Schritten.
• Bausteine wie Load Balancer und dauerhafte Platten sind in die Infrastruktur des Anbieters eingebunden.

Einige Pflichten bleiben trotzdem bei Ihnen, denn der Anbieter kennt Ihre Anwendung nicht. Architektur der Anwendung, Ressourcendefinitionen, Sicherheitseinstellungen und Kostenkontrolle sind weiterhin Ihre Aufgabe. Binden Sie sich außerdem zu stark an Funktionen eines Anbieters, fällt ein späterer Wechsel schwerer.

Unser Rat ist daher einfach. Brauchen Sie Kubernetes wirklich und ist Ihr Team klein, starten Sie mit einem verwalteten Dienst statt mit einem selbst gebauten Cluster. Zum Lernen und Ausprobieren reichen die lokalen Varianten aus unserer Anleitung zu Minikube und k3s.

Wie beginnen Sie den Umstieg von Docker auf Kubernetes?

Haben Sie sich für den Umstieg entschieden, senkt eine feste Reihenfolge das Risiko. Wir schlagen diese Schritte vor:

1. Machen Sie die Anwendung zustandslos: Sitzungen und Dateien gehören außerhalb des Containers.
2. Lagern Sie die Konfiguration in Umgebungsvariablen aus; Passwörter gehören nie ins Image.
3. Ergänzen Sie für jeden Dienst einen Endpunkt für die Gesundheitsprüfung.
4. Schieben Sie Ihre Images mit Versionsnummer in eine Registry.
5. Testen Sie Kubernetes zunächst lokal oder in einem Testcluster.
6. Ziehen Sie zuerst einen unkritischen Dienst um, danach die übrigen.

Die ersten drei Schritte verbessern Ihre Anwendung auch dann, wenn Sie nie zu Kubernetes wechseln. Zum Beispiel lässt sich eine zustandslose Anwendung auch auf einem einzelnen Server leichter sichern und umziehen. Sehen Sie diese Schritte deshalb als allgemeine Gesundheitskur, nicht nur als Vorbereitung auf Kubernetes.

Möchten Sie Ihre Anwendungsarchitektur gemeinsam prüfen, plant unser Team diese Schritte im Rahmen unserer individuellen Softwareentwicklung mit Ihnen.

Wie lässt sich der Vergleich von Docker und Kubernetes zusammenfassen?

In einem Satz: Docker baut und startet Container, Kubernetes verwaltet viele Container auf vielen Servern. Docker und Kubernetes sitzen also auf verschiedenen Ebenen desselben Stapels und arbeiten oft zusammen.

Diese Punkte sollten Sie sich merken:

• Das Ende von dockershim hat Docker nicht beendet; nur die Runtime auf Kubernetes Knoten hat sich geändert.
• Für einen Server sind Docker und Compose oft ausreichend und deutlich einfacher.
• Der Wert von Kubernetes zeigt sich bei vielen Servern und hohem Bedarf an Verfügbarkeit.
• Der Wartungsaufwand von Kubernetes ist real; fehlt Ihrem Team die Kapazität, wählen Sie einen verwalteten Dienst.

Schließlich sollte das Geschäftsziel die Entscheidung über die Infrastruktur treiben, nicht ein Technologietrend. Messen Sie zunächst den echten Engpass Ihrer Website oder Anwendung und wählen Sie dann das einfachste Werkzeug, das ihn beseitigt.