Kubernetes gegen Docker ist der falsche Vergleich. Dennoch ist es der erste, den fast jedes Team anstellt. Docker verpackt Ihre Anwendung in einen Container; Kubernetes betreibt Tausende dieser Container auf einer Flotte von Maschinen und entscheidet, welcher wohin kommt. Es handelt sich um zwei grundlegende Technologien der Containerisierung, die auf zwei verschiedenen Ebenen des Stacks angesiedelt sind.
Die eigentliche Frage ist also nicht, für welche Sie sich entscheiden. Sondern ob sich die zweite bereits für Sie lohnt.
Stellen Sie sich einen Seehafen vor. Docker ist der Container: standardisierte Maße, versiegelt, stapelbar – und es ist völlig egal, ob sich darin Kaffee oder Autoteile befinden. Kubernetes ist die Hafenbehörde: die Kräne, die Planung, das Manifest, das festlegt, welcher Container auf welches Schiff kommt, und die Crew, die den Container neu verlädt, falls ein Kran ihn fallen lässt. Einen kleinen Kai können Sie mit ein paar Containern und einem Klemmbrett betreiben. Rotterdam braucht die Hafenbehörde.
Dieser Artikel erklärt, was Containerisierung ist, welche Aufgaben Docker und Kubernetes jeweils übernehmen, wo der eigentliche Vergleich liegt und wie Sie entscheiden, wann sich Orchestrierung für Sie auszahlt.
Kurz gefasst:
Docker ist eine Plattform zur Containerisierung. Sie nimmt Ihre Anwendung samt Abhängigkeiten und verpackt sie in ein Image, das überall identisch ausgeführt werden kann. Kubernetes ist ein Container-Orchestrator: Er nimmt diese Images und entscheidet, auf welcher Maschine sie laufen, wie viele Kopien existieren, was passiert, wenn eine ausfällt, und wie der Datenverkehr sie findet.
Kann man Docker ohne Kubernetes verwenden? Ja, und die meisten Teams fangen genau dort an. Umgekehrt ist das nicht wirklich der Fall. Kubernetes benötigt eine Möglichkeit, Container-Images zu erstellen, und für die meisten Unternehmen ist diese Möglichkeit nach wie vor Docker.
| Docker | Kubernetes | |
|---|---|---|
| Zweck | Erstellt und führt einzelne Container aus | Führt Container über ein Cluster hinweg aus und verwaltet sie |
| Umfang | Eine Maschine, eine Anwendung gleichzeitig | Viele Maschinen, viele Dienste, eine Control Plane |
| Skalierung | Manuell oder über Docker Compose und Docker Swarm | Automatisch, deklarativ, basierend auf Last und Richtlinien |
| Fehlerbehandlung | Der Container stoppt | Selbstheilung: Fehlgeschlagene Workloads werden neu geplant |
| Lernkurve | Tage, um produktiv zu sein | Wochen bis Monate, und das ist noch nicht alles |
| Betriebskosten | Vernachlässigbar über den Entwickler-Rechner hinaus | Eine finanzierte Plattform-Kapazität: Cluster, Upgrades, Rufbereitschaft |
| Zuständigkeit | Jeder Entwickler | Ein Plattform- oder DevOps-Team |
Zwei Namen in dieser Tabelle bedürfen vorab einer Definition. Docker Compose ist das Tool zum Definieren und Ausführen eines Multi-Container-Setups auf einer einzelnen Maschine. Docker Swarm ist der hauseigene Orchestrator von Docker, auf den wir weiter unten noch zurückkommen.
Gehen wir die Ebenen durch.
Containerisierung ermöglicht es Entwicklern, Softwarecode zusammen mit allen für die Ausführung erforderlichen Komponenten (Frameworks, Bibliotheken und weitere Abhängigkeiten) in einem einzigen, isolierten Container zu bündeln. Einmal verpackt, ist die Anwendung portabel. Sie lässt sich auf eine andere Infrastruktur übertragen und dort ausführen, unabhängig vom zugrunde liegenden Betriebssystem oder der Umgebung.
Diese Portabilität ist der entscheidende Vorteil, der zudem für Sicherheit sorgt, da sich derselbe Build auf jedem System identisch verhält. Allerdings gehört nicht alles in einen Container. Grafikintensive Desktop-Anwendungen werden in der Regel auf der Hypervisor-Ebene virtualisiert – also der Schicht, die vollständige virtuelle Maschinen mit eigenem Betriebssystem ausführt, etwa mit Tools wie Vagrant –, da sie Hardwarezugriffe benötigen, die ein Container nicht bietet.
Vor der Einführung von Containern schrieben Entwickler Code in einer bestimmten Rechenumgebung und stießen beim Transfer auf Probleme. Der Wechsel von Linux zu Windows machte den Code anfällig für Bugs und umgebungsspezifische Fehler. Container lösen dieses Problem, indem sie die Software vom Host-Betriebssystem abstrahieren, sodass der Boden unter den Füßen stabil bleibt.
Anwendungen laufen in unabhängigen, gekapselten Umgebungen. Skalierbarkeit, schnellere Bereitstellung und eine höhere Konsistenz zwischen verschiedenen Umgebungen sind die Hauptvorteile, was sich auch in der Verbreitung widerspiegelt. Die Nutzung von Containern unter Backend-Entwicklern lag bereits 2020 bei über 60 % (SlashData, State of Cloud Native Development) und hat seitdem weiter zugenommen: Die aktuelle Annual Cloud Native Survey, veröffentlicht im Januar 2026, ergab, dass mittlerweile 82 % der Unternehmen, die Container einsetzen, Kubernetes in der Produktion nutzen – ein Anstieg gegenüber 66 % zwei Jahre zuvor.
Das Konzept ist übrigens älter als Docker. Linux Containers (LXC) boten bereits vor 2013 Container-Technologie an. Was Docker mit der Open-Source-Veröffentlichung in jenem Jahr veränderte, war die Developer Experience, wodurch es zum Standard-Containerformat wurde. Das ist es bis heute: Im Stack Overflow Developer Survey zählt Docker weiterhin zu den am häufigsten verwendeten Entwicklertools und liegt mit großem Abstand vor allen anderen Containerisierungs-Tools.
Docker ist eine Container-Plattform, mit der Anwendungen als portable, in sich geschlossene Container entwickelt, bereitgestellt und ausgeführt werden können. Ob Laptop, Cloud-Umgebung oder Rechenzentrum: Es läuft praktisch überall.
Im Laufe der Jahre hat Docker eine umfassende Plattform um diesen Kern herum aufgebaut. Das macht jedoch nicht jedes Docker-Tool automatisch zur besten Wahl. Der Markt ist wettbewerbsintensiv und für viele der einzelnen Komponenten gibt es starke Alternativen.
Ein Docker-Container ist eine laufende Instanz eines Docker-Images: Ihre Anwendung inklusive aller benötigten Komponenten, isoliert vom Host und von allen anderen Containern. Er nutzt den Kernel des Host-Betriebssystems, anstatt ein eigenes mitzubringen. Deshalb startet ein Container in Sekunden, während eine virtuelle Maschine Minuten benötigt.
Drei Komponenten machen dies möglich:
Sie benötigen nicht immer ein Dockerfile. Entwickler können fertige Images aus einer Registry wie Docker Hub oder Azure Container Registry beziehen und sich so die Arbeit sparen – das Angebot ist groß. Um einen Docker-Container auszuführen, laden Sie also entweder ein Image aus einer öffentlichen Registry herunter oder erstellen Ihr eigenes mit einem Dockerfile.
Beim Erstellen eigener Images zeigt sich die Professionalität. Ein schnell erstelltes Dockerfile unterscheidet sich grundlegend von einem für die Produktion. Hier ist unser Standard – ein Multi-Stage-Build, der Entwicklungsabhängigkeiten aus dem finalen Image heraushält, als Non-Root-User ausgeführt wird und ein kleines, reproduzierbares Artefakt erzeugt:
# syntax=docker/dockerfile:1
# IC house-standard Node/TypeScript service image.
# Multi-stage: deterministic prod dependencies, minimal non-root runtime.
ARG NODE_VERSION=22.11.0 # IC: pin by digest in production
ARG APP_PORT=3000
# ---- Stage 1: install everything and build ----
FROM node:${NODE_VERSION}-bookworm-slim AS build
WORKDIR /app
ENV NODE_ENV=development
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci
COPY . .
RUN npm run build # IC: expects a build script emitting to ./dist
# ---- Stage 2: production dependencies only ----
FROM node:${NODE_VERSION}-bookworm-slim AS prod-deps
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev
# ---- Stage 3: runtime ----
FROM node:${NODE_VERSION}-bookworm-slim AS runtime
ARG APP_PORT
# tini gives us correct signal handling and zombie reaping as PID 1.
RUN apt-get update \
&& apt-get install -y --no-install-recommends tini \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
ENV NODE_ENV=production PORT=${APP_PORT}
# Copy only what runtime needs, owned by the image's built-in non-root user.
COPY --chown=node:node --from=prod-deps /app/node_modules ./node_modules
COPY --chown=node:node --from=build /app/dist ./dist
COPY --chown=node:node package.json ./
# OCI provenance labels (IC: wire GIT_SHA / BUILD_DATE from CI).
ARG GIT_SHA=unknown
ARG BUILD_DATE=unknown
LABEL org.opencontainers.image.vendor="Imaginary Cloud" \
org.opencontainers.image.revision="${GIT_SHA}" \
org.opencontainers.image.created="${BUILD_DATE}"
USER node
EXPOSE ${APP_PORT}
# Docker-level healthcheck. In Kubernetes, prefer liveness/readiness probes.
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
CMD node -e "fetch('http://localhost:'+process.env.PORT+'/health').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"
ENTRYPOINT ["tini", "--"]
CMD ["node", "dist/main.js"]Die HEALTHCHECK-Zeile ist ein kleines Beispiel für die Kernaussage dieses Artikels: Es funktioniert zwar, aber sobald Sie dieses Image unter Kubernetes ausführen, übergeben Sie diese Aufgabe stattdessen an einen Liveness-Probe. Der Build bleibt gleich, die Umgebung drumherum ändert sich.
Docker wird eingesetzt, damit sich Software überall gleich verhält. In der Praxis deckt dies vier Bereiche ab:
Dann vermehren sich die Container. Mit der Anzahl der Container wächst auch die Komplexität ihrer Verwaltung, und es treten die bekannten Probleme auf, die alle unter den Begriff Orchestrierung fallen:
Die Antwort von Docker war Docker Swarm, eine eigene Technologie zur Container-Orchestrierung. Und das ist das Detail, das in den meisten Vergleichen übersehen wird: Nicht die Docker-Plattform als Ganzes, sondern Swarm ist die Komponente, die tatsächlich mit Kubernetes vergleichbar ist.
Kubernetes ist eine Technologie zur Container-Orchestrierung, vergleichbar mit OpenShift oder Amazon ECS. Google stellte sie 2014 vor, ein Jahr nach der Veröffentlichung von Docker. Heute wird sie von der CNCF, der Cloud Native Computing Foundation, verwaltet.
Es wurde entwickelt, um containerisierte Anwendungen zu planen, zu verwalten, deren Bereitstellung zu automatisieren und sie zu skalieren. Mit anderen Worten: Es bewältigt die Komplexität, eine große Anzahl von Containern auf vielen Servern auszuführen, ohne dass jemand manuell entscheiden muss, wo welcher Container platziert wird.
Dies geschieht über eine Open-Source-API, die regelt, wie und wo Container ausgeführt werden. Container werden in Podsgruppiert, der grundlegenden Betriebseinheit in Kubernetes. Pods laufen auf Nodes, den Maschinen im Cluster, und die Control Plane ist die Gesamtheit der Komponenten, die entscheidet, was wo laufen soll, und den Cluster automatisch korrigiert, sobald die Realität von diesem Soll-Zustand abweicht. Sobald sie gruppiert sind, können Pods skaliert und ihr Lebenszyklus deklarativ gesteuert werden.
Kubernetes orchestriert also Maschinen und plant Container basierend auf den verfügbaren Rechenressourcen und den Anforderungen der jeweiligen Container. Ihr Team definiert den gewünschten Zustand eines Clusters; die Plattform kümmert sich um die Planung, das Verbindungsmanagement und die Wiederherstellung. Das Projekt entwickelt sich schnell – Kubernetes erreichte 2026 Version 1.36 –, aber dieser deklarative Kern ist seit Jahren stabil.
Kubernetes unterstützt eine Vielzahl von Container-Tools, darunter Docker-Images, was uns zurück zu unserem anfänglichen Vergleich führt.
Wenn wir Docker und Kubernetes richtig vergleichen wollen, ist der faire Vergleich Docker Swarm gegen Kubernetes, da beides Technologien zur Container-Orchestrierung sind. Docker ist Marktführer bei der Containerisierung. Bei der Orchestrierung hat Docker jedoch nicht gewonnen. Das hat Kubernetes, und zwar eindeutig: Das Kubernetes-Repository verzeichnete Stand 2026 rund 115.000 GitHub-Sterne, gegenüber wenigen Tausend für die Bibliothek hinter Docker Swarm, die seit Jahren praktisch inaktiv ist. Die Lücke bei der kommerziellen Unterstützung ist noch größer, da jeder große Cloud-Anbieter einen verwalteten Kubernetes-Dienst anbietet.
Docker und Kubernetes sind komplementäre Technologien. Ihre Rollen überschneiden sich in der allgemeinen Vorstellung, in der Praxis jedoch kaum. Docker produziert die Boxen. Kubernetes betreibt den Hafen.
Kubernetes bietet zudem eine Reihe von Funktionen, die wichtig werden, sobald man mehr als eine Handvoll Dienste betreibt: Lastverteilung, Netzwerkrichtlinien, Geheimnisverwaltung, Isolierung zwischen Workloads, Selbstheilung und die Fähigkeit, über jeden Knoten im Cluster hinweg zu skalieren.
Um das Beste aus Docker und Kubernetes zusammen herauszuholen, muss man ehrlich einschätzen, wie nützlich die einzelnen Komponenten für einen selbst sind. Nicht jedes Unternehmen, das Container einsetzt, benötigt einen Orchestrator. Teams mit kleinen Anwendungen und einer geringen, kontrollierbaren Anzahl an Containern brauchen ihn in der Regel nicht, und die Einführung kostet sie mehr, als sie einbringt.
Wenn die Softwareanforderungen wachsen, müssen auch die dahinterliegenden Anwendungen skalieren. Um von einer Microservices-Architektur zu profitieren, müssen die entsprechenden Rahmenbedingungen vorhanden sein. Andernfalls wird die Containerisierung im Tech-Stack eher zu einer Belastung als zu einem Vorteil.
Kubernetes oder ein ähnliches Tool ist daher nicht zwingend erforderlich. Es wird jedoch dringend für Infrastrukturen empfohlen, die skalieren müssen und eine hohe Anzahl von Containern in verteilten Systemen verwalten. Bei echter Skalierung ist Orchestrierung heute eher die Norm als die Ausnahme: die CNCF-Umfrage 2026 zeigt, dass 82 % der befragten Unternehmen Kubernetes produktiv einsetzen, während ein weiterer Teil es testet oder evaluiert – der Trend geht eindeutig in Richtung verwaltetes Kubernetes und nicht weg von der Orchestrierung.
Die Vorteile, von denen diese Unternehmen berichten, sind konsistent:
Dies sorgte für echte Unruhe, als mit Kubernetes 1.20 angekündigt wurde, dass die Docker-Unterstützung im Kubelet als veraltet markiert und in einer zukünftigen Version entfernt werden würde. Viele Entwickler interpretierten dies als das Ende von Docker und damit als das Ende der Kombination aus Docker und Kubernetes. Kubernetes veröffentlichte am 2. Dezember 2020 eine Klarstellung, Keine Panik: Kubernetes und Docker, mit der Erklärung, dass es bei weitem nicht so dramatisch war, wie es klang.
Hier ist, was tatsächlich geschah. Innerhalb eines Kubernetes-Clusters zieht und startet eine Komponente namens Container-Runtime Container-Images, und der Kubelet ist der Agent auf jedem Knoten, der mit ihr kommuniziert. Docker war die beliebteste Runtime für diese Aufgabe, wurde jedoch nie dafür entwickelt, in Kubernetes eingebettet zu werden. Es ist darauf ausgelegt, von Menschen über eine Befehlszeile gesteuert zu werden, nicht von einer anderen Software. Daher benötigte Kubernetes ein Zwischenstück, Dockershim, um zwischen dem Kubelet und Docker zu vermitteln – und unter Docker griff es eigentlich auf containerd zu, die Low-Level-Runtime, die Docker selbst verwendet. Eine zusätzliche Ebene, die gewartet werden musste, ohne funktionalen Mehrwert.
Die Entfernung wurde vollzogen. Dockershim wurde mit der im Mai 2022 veröffentlichten Kubernetes-Version 1.24 aus dem Kubelet entfernt, und containerd ist nun die Standard-Runtime auf den meisten verwalteten Clustern, wobei CRI-O – eine leichtgewichtige, speziell für Kubernetes entwickelte Runtime – die wichtigste Alternative darstellt. Was nicht passierte, war ein Bruch der Kompatibilität. Images, die mit Docker erstellt wurden, folgen dem Open Container Initiative -Standard und laufen auf Kubernetes exakt wie zuvor: Die FAQ zur Entfernung von Dockershim enthalten die Details. Ist das also das Ende von Docker? Nein. Kubernetes hat aufgehört, Docker als Runtime zu verwenden. Es hat nie aufgehört, Docker-Images auszuführen. Und auch vier Jahre später laufen sie immer noch ohne Änderungen.
Jeder Artikel zu diesem Thema vergleicht Funktionen. Nur wenige beleuchten die Kosten, die ein CTO tatsächlich absegnen muss.
Kubernetes ist kein Tool, das man einfach einführt. Es ist eine Plattformfähigkeit, die man finanziert. Der Cluster selbst ist der günstige Teil. Die Kosten entstehen durch das Personal, das ihn aktuell hält, den Upgrade-Rhythmus, die Rufbereitschaft, die Arbeit an Sicherheits- und Netzwerkrichtlinien sowie die Monate, in denen die Bereitstellung verlangsamt wird, während das Team lernt. Managed Services der großen Cloud-Anbieter nehmen einem einen Großteil der operativen Last ab. Aber nicht die Verantwortung.
Wir nutzen bei Kunden einen einfachen Test, den wir die Orchestrierungsschwellenennen. Kubernetes amortisiert sich, wenn mindestens drei der folgenden fünf Aussagen zutreffen:
Weniger als drei? Dann lautet die ehrliche Empfehlung meist Docker mit einem Managed Container Service wie ECS, Cloud Run oder App Service – und eine Notiz im Kalender, um die Frage in einem Jahr erneut zu prüfen.
Wir lassen unseren Worten Taten folgen. Bei einer kürzlich entwickelten Plattform für maritime Kommunikation (Sedna), haben wir uns gegen eine Orchestrierung entschieden: Anstatt einen Cluster aufzusetzen, haben wir die Integrations-Workflows des Kunden auf maßgeschneiderte AWS-Dienste migriert – mit Terraform definierte Infrastruktur, CI/CD-Pipelines und Lambda-Funktionen – und so die Kosten für ihre Workflow-Tools um 80 % gesenkt. Unterhalb dieser Schwelle ist das meist der lohnendere Weg.
In unserer Arbeit bestätigt sich dieses Muster immer wieder: Teams, die Kubernetes unterhalb dieser Schwelle einführen, verbringen in den ersten zwei Quartalen mehr Zeit mit der Plattform als mit dem eigentlichen Produkt. Teams, die es oberhalb dieser Schwelle einsetzen, behandeln das Deployment hingegen schon nach etwa demselben Zeitraum als Routineaufgabe.
Dann gibt es noch das Risiko, für das niemand ein Budget einplant: den herrenlosen Cluster. Eine Kubernetes-Installation, für deren Wartung niemand zuständig ist, veraltet, sammelt ungepatchte Komponenten an und wird mit der Zeit immer schwieriger abzulösen. Wie ein Schiff, für dessen Entladung niemand bezahlt wird. Das ist ein Governance-Problem, lange bevor es zu einem technischen wird.
Containerisierung ist nicht für jeden Workload der richtige Ansatz, doch die Vorteile sprechen für sich: höhere Anwendungsqualität, gesteigerte Produktivität, weniger Ausfallzeiten und eine schnellere Reaktion auf Veränderungen.
Wie arbeiten Docker und Kubernetes also zusammen, um dies zu erreichen?
Der Container und der Hafen. Sie ergänzen sich gegenseitig, und in Kombination mit DevOps-Praktiken bilden sie eine Microservices-Basis, die eine schnelle Bereitstellung und skalierbare Cloud-native Anwendungen unterstützt. Die Frage war also nie, für welches der beiden man sich entscheiden soll. Es geht vielmehr darum, ob Ihr Unternehmen bereits die Schwelle zur Orchestrierung überschritten hat. Und falls nicht, wann dies der Fall sein wird.
Nicht die Docker-Runtime, aber mit an Sicherheit grenzender Wahrscheinlichkeit die Docker-Tools. Kubernetes führt Container über containerd oder CRI-O aus, nicht über Docker. Sie benötigen jedoch weiterhin ein Tool zum Erstellen von Container-Images, und Docker bleibt hierfür die gängigste Wahl sowie der Standard für Entwickler, um Container lokal auszuführen.
Nein. Kubernetes hat Docker als Container-Runtime innerhalb seiner Nodes mit Version 1.24 im Mai 2022 abgelöst. Es hat Docker jedoch nicht als Image-Format oder Build-Tool ersetzt, und mit Docker erstellte Images laufen ohne Änderungen auf Kubernetes.
Ein Docker-Container ist eine laufende Instanz eines Docker-Images: eine Anwendung, die zusammen mit ihren Abhängigkeiten verpackt und vom Host-System isoliert ist. Da er sich den Kernel des Host-Betriebssystems teilt, startet er in Sekunden und verbraucht nur einen Bruchteil der Ressourcen einer virtuellen Maschine.
Docker wird verwendet, um Anwendungen so zu verpacken, dass sie überall identisch laufen: auf dem Laptop eines Entwicklers, in einer Continuous-Integration-Pipeline und in der Produktion. Es bildet die Grundlage für Microservices-Architekturen, beseitigt umgebungsspezifische Fehler und stellt Deployment-Pipelines ein einheitliches Artefakt zur Verfügung.
Docker Swarm eignet sich für kleine Cluster mit unkomplizierten Workloads, insbesondere wenn ein Team bereits mit Docker Compose vertraut ist und Scheduling nutzen möchte, ohne ein neues Betriebsmodell erlernen zu müssen. Es ist einfacher und schneller zu erlernen als Kubernetes. Der Nachteil ist ein deutlich kleineres Ökosystem, eingeschränktes Managed Hosting und ein schrumpfender Pool an Ingenieuren, die damit gearbeitet haben.
Ja, und das sollten viele Unternehmen auch tun. Ein Managed-Container-Service wie AWS ECS, Google Cloud Run oder Azure Container Apps führt Container in der Produktion mit weitaus geringerem operativen Aufwand aus als Kubernetes. Der Nachteil ist weniger Kontrolle und eine stärkere Bindung an einen Cloud-Anbieter.
Sie überlegen, ob sich Kubernetes für Ihr Unternehmen lohnt? Von Kommunikationsplattformen im maritimen Maßstab bis hin zu Serverless-Migrationen auf AWS – wir konzipieren und betreiben Cloud-native Plattformen, die Teams auch tatsächlich warten können – und wir sagen Ihnen ebenso ehrlich, wenn Sie keine benötigen. Sprechen Sie mit unserem Team darüber, wohin sich Ihre Infrastruktur entwickelt.
Marketing-Praktikant mit besonderem Interesse an Technologie und Forschung. In meiner Freizeit spiele ich Volleyball und verwöhne meinen Hund so gut es geht.
Experte für Sicherheit und Cloud-Betrieb. Hintergrund in den Bereichen öffentlicher Verkehr, Finanzen und Regierung. Normalerweise handelt es sich um den Handel mit Münzen an dezentralen Börsen:)
People who read this post, also found these interesting:
.webp)
