Die Suche nach Docker vs. Kubernetes legt nahe, dass Sie sich für eines entscheiden müssen, aber diese Formulierung sorgt für große Verwirrung. Es ist ein bisschen so, als würde man einen Schiffscontainer mit dem Hafen vergleichen, der Tausende davon organisiert. Sie agieren auf unterschiedlichen Ebenen und werden häufig nebeneinander eingesetzt.

Dieser Leitfaden erklärt, was jeder tut, zeigt in beiden die gleiche kleine App und endet mit einer praktischen Entscheidungshilfe. Bei den Befehlen und Dateien hier handelt es sich um Standardbeispiele, die wir für diesen Artikel nicht ausgeführt haben. Vergleichen Sie sie daher mit den von Ihnen installierten Versionen.

Die kurze Antwort

Docker ist eine Plattform zum Packen einer Anwendung und ihrer Abhängigkeiten in ein Image und zum anschließenden Ausführen dieses Images als Container. Es beantwortet die Frage „Wie sorge ich dafür, dass diese App überall gleich läuft?“

Kubernetes, oft als K8s geschrieben, ist ein Container-Orchestrator. Es entscheidet, wo Container auf vielen Maschinen laufen, startet sie neu, wenn sie ausfallen, und skaliert sie entsprechend der Nachfrage. Es beantwortet die Frage „Wie halte ich Hunderte von Containern zuverlässig am Laufen?“

Docker vs. Kubernetes nebeneinander

Was Docker macht

Vor Containern war „es funktioniert auf meinem Rechner“ ein alltägliches Problem, da jeder Server von allem unterschiedliche Versionen hatte. Docker bündelt Ihren Code, Ihre Laufzeit und Ihre Bibliotheken in einem Image. Eine laufende Kopie dieses Images ist ein Container und teilt sich den Kernel des Hosts, sodass es schneller startet und weniger Speicher verbraucht als eine vollständige virtuelle Maschine.

Der Workflow besteht aus drei Schritten:

1. Build: a Dockerfile beschreibt, wie das Bild erstellt wird.
2. Versenden: Schieben Sie das Image in eine Registrierung, z. B. Docker Hub.
3. Ausführen: Container von diesem Image auf jedem kompatiblen Computer starten.

Beginnen Sie zum praktischen Einstieg mit unserem Docker-Tutorial für Anfänger und lesen Sie dann unsere Best Practices für Dockerfiles.

Was Kubernetes macht

Docker auf einem Server funktioniert so lange gut, bis dieser Server ausfällt, der Datenverkehr zu groß wird oder Sie Dutzende Dienste koordinieren müssen. Kubernetes übernimmt diese operativen Aufgaben:

• Planung: Platzieren von Containern auf Maschinen mit ausreichend freier Kapazität.
• Selbstheilung: Ersetzen ausgefallener Container und Verschieben der Arbeit von ausgefallenen Knoten.
• Skalierung: Hinzufügen oder Entfernen von Kopien, manuell oder basierend auf Metriken.
• Diensterkennung: einer sich ändernden Gruppe von Containern einen stabilen Namen geben.
• Rollende Updates: Veröffentlichung neuer Versionen nach und nach mit einem einfachen Rollback.
• Konfiguration: Einstellungen und Geheimnisse getrennt von Bildern verwalten.

Die Kernidee ist der gewünschte Zustand. Sie erklären, dass es drei Kopien geben sollte, und die Kontrolleure vergleichen dies ständig mit der Realität und korrigieren etwaige Unterschiede. Unser Kubernetes-Tutorial für Anfänger führt dies auf einem lokalen Cluster durch.

Wie Docker und Kubernetes zusammenarbeiten

Ein typischer Weg vom Laptop eines Entwicklers bis zur Produktion sieht so aus:

1. Ein Entwickler schreibt eine Dockerfile und testet den Container lokal.
2. Eine CI/CD-Pipeline erstellt das Image und führt die Tests aus.
3. Die Pipeline überträgt ein versioniertes Image an eine Registrierung.
4. Ein Kubernetes-Manifest wird aktualisiert, um diese Image-Version zu verwenden.
5. Kubernetes ruft das Image ab und verteilt es im gesamten Cluster.

Dockers Arbeit ist also weitgehend erledigt, bevor Kubernetes startet. Das Bild ist der Übergabepunkt zwischen ihnen.

Eine App, beide Wege

Hier ist ein kleiner Webservice. Das Image wird auf die gleiche Weise erstellt, unabhängig davon, welches Tool es ausführt:

# Dockerfile
FROM python:3.13-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

Führen Sie es mit Docker aus

docker build -t shop-api:1.0 .
docker run -d --name shop -p 8080:8000 --restart unless-stopped shop-api:1.0

Zwei Befehle und es läuft. Das ist einfach und für viele kleine Projekte geeignet. Aber es gibt eine Kopie auf einer Maschine, und wenn die Maschine ausfällt, geht auch der Dienst verloren.

Führen Sie es mit Kubernetes aus

# shop.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop
  template:
    metadata:
      labels:
        app: shop
    spec:
      containers:
        - name: api
          image: registry.example.com/shop-api:1.0
          ports:
            - containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
  ports:
    - port: 80
      targetPort: 8000

kubectl apply -f shop.yaml
kubectl get pods -l app=shop

Es gibt noch viel mehr zu schreiben und Sie benötigen einen Cluster, auf dem es ausgeführt werden kann. Im Gegenzug erhalten Sie drei Kopien, eine stabile interne Adresse und automatischen Ersatz. Dieser Kompromiss ist die gesamte Entscheidung im Kleinen: mehr Komplexität im Austausch für mehr Widerstandsfähigkeit.

Was passiert, wenn ein Container ausfällt?

Die Dockershim-Verwirrung

Möglicherweise haben Sie gelesen, dass „Kubernetes Docker eingestellt hat“. Das stimmt im engeren Sinne und hat vielen Menschen unnötig Angst gemacht. Kubernetes führt Container über einen Standard namens Container Runtime Interface aus. Docker Engine hat es nicht direkt implementiert, daher hat Kubernetes einen Adapter namens Dockershim hinzugefügt. Dieser Adapter wurde in Version 1.24 entfernt.

Cluster verwenden heute typischerweise Laufzeiten wie Containerd oder CRI-O. Images, die Sie mit Docker erstellen, funktionieren weiterhin, da sie dem Image-Standard der Open Container Initiative (OCI) folgen. Sie können also weiterhin mit Docker bauen und Ihr Cluster führt das Ergebnis mit einer anderen Laufzeit aus.

Docker Compose vs. Swarm vs. Kubernetes

Der aussagekräftigere Vergleich besteht zwischen Tools, die Container koordinieren:

Docker Compose startet mehrere verwandte Container aus einer Datei und eignet sich hervorragend für eine Web-App und eine Datenbank auf einem Laptop. Swarm ist in Docker integriert und viel einfacher zu erlernen als Kubernetes, verfügt aber über ein weitaus kleineres Ökosystem. Kubernetes verfügt über die größte Community und das größte Tooling, weshalb es zum Standard für große Bereitstellungen wurde.

Was brauchen Sie?

Docker allein reicht normalerweise aus, wenn:

• Sie entwickeln lokal oder führen eine kleine App auf einem Server aus.
• Sie haben ein kleines Team und kein eigenes Betriebspersonal.
• Gelegentliche kurze Ausfallzeiten sind akzeptabel.

Kubernetes macht erst dann Sinn, wenn:

• Sie betreiben viele Dienste, die verschiedene Teams selbstständig bereitstellen.
• Sie benötigen eine hohe Verfügbarkeit über mehrere Maschinen oder Zonen hinweg.
• Der Datenverkehr variiert so stark, dass die automatische Skalierung echtes Geld spart.
• Sie verfügen über die Fähigkeiten oder das Budget, um es zu betreiben.

Es gibt auch einen Mittelweg. Verwaltete Containerplattformen wie AWS Fargate, Google Cloud Run oder ein PaaS führen Ihr Docker-Image aus, ohne dass ein Cluster verwaltet werden muss. Für viele wachsende Unternehmen ist das der richtige nächste Schritt, anstatt direkt zu Kubernetes zu springen.

Möchte man aus beruflichen Gründen beides erlernen, ist die Reihenfolge klar: Erst Docker, dann Kubernetes. Sie können einen Pod nicht bequem debuggen, ohne sich zuvor mit Bildern, Ports und Containerprotokollen vertraut zu machen.

Häufige Fehler

• Kubernetes zu früh einführen. Das Kopieren der Architektur eines riesigen Unternehmens kann ein kleines Team mit operativer Arbeit belasten.
• Verwendung des Tags latest in der Produktion. Sie können nicht zuverlässig erkennen, was ausgeführt wird, oder ein Rollback durchführen. Verwenden Sie bestimmte Versions-Tags.
• Speichern von Daten in Containern. Container sind wegwerfbar, verwenden Sie daher Volumes oder eine verwaltete Datenbank.
• Überspringen von Gesundheitsprüfungen. Ohne Bereitschafts- und Liveness-Prüfungen kann Kubernetes keine guten Entscheidungen über Ihre App treffen.
• Ressourcenbeschränkungen vergessen. Ein gieriger Container kann alles andere auf einem Knoten aushungern lassen.

Fazit

Docker verpackt Ihre Software und Kubernetes führt sie im großen Maßstab aus. Anstatt zu fragen, was besser ist, fragen Sie, welches Problem Sie heute haben. Wenn die Meldung lautet: „Meine App ist schwer zu installieren“, verwenden Sie Docker. Wenn es heißt: „Meine 40 Dienste müssen Serverausfälle überstehen“, schauen Sie sich Kubernetes an. Beginnen Sie mit dem einfachsten Tool, das Ihr eigentliches Problem löst, und steigen Sie auf, wenn Sie den Bedarf erkennen.

Häufige Fragen

Lerne weiter