Kubernetes vs. Docker: Was Sie wirklich brauchen

Zwei Werkzeuge, zwei Ebenen 

Docker verpackt und startet einzelne Container. Kubernetes orchestriert viele Container über mehrere Server hinweg. 

Anders formuliert: Docker beantwortet die Frage „Wie bringe ich meine Anwendung reproduzierbar zum Laufen?". Kubernetes beantwortet die Frage „Wie betreibe ich hunderte dieser Anwendungen zuverlässig, skalierbar und ohne manuelles Eingreifen?". 

Ein Vergleich aus der Logistik: Docker ist der Standardcontainer, der Ware transportfähig macht. Kubernetes ist das Terminal samt Kränen, Disposition und Schichtplan, das entscheidet, welcher Container wann auf welchem Schiff steht und was passiert, wenn ein Kran ausfällt. 

Was Docker leistet 

Docker hat Container im Mainstream etabliert. Der Kern des Angebots umfasst drei Dinge: 

• Ein Image-Format: Ihre Anwendung wird samt Abhängigkeiten, Bibliotheken und Konfiguration in ein unveränderliches Abbild gepackt. Damit läuft der Code auf dem Laptop des Entwicklers identisch wie auf dem Produktivsystem.  
• Eine Container-Runtime: Docker startet, stoppt und isoliert Container auf einem einzelnen Host.  
• Werkzeuge für den Alltag: Dockerfile für den Build, Docker Compose für das Zusammenspiel mehrerer Container auf einem Server und Registries für die Verteilung der Images.  

Die Stärke von Docker liegt in der Einfachheit. Ein Entwickler kann eine Shopware-Instanz, eine Datenbank, einen Redis-Cache und einen Elasticsearch-Container mit einer einzigen Compose-Datei starten. Für lokale Entwicklung, Staging-Umgebungen und kleinere Produktivsetups ist das oft völlig ausreichend.

Wo Docker an seine Grenzen kommt 

Die Grenze von Docker ist ebenso klar: Docker denkt in einem einzelnen Server. Fällt dieser Host aus, ist die Anwendung offline. 

Sobald Anwendungen über mehrere Server verteilt, automatisch skaliert oder ohne Downtime aktualisiert werden sollen, reicht Docker allein nicht mehr aus. Funktionen wie das automatische Verschieben von Workloads oder die Orchestrierung über mehrere Maschinen gehören nicht zu seinem eigentlichen Funktionsumfang. 

Das wäre auch ein guter Übergang zu Kubernetes, falls der nächste Abschnitt darum geht. 

Was Kubernetes leistet

Kubernetes setzt genau dort an, wo Docker aufhört. Es verwaltet einen Verbund aus mehreren Servern die Cluster und verteilt Container darauf nach definierten Regeln. Die wichtigsten Funktionen im Überblick: 

• Scheduling: Kubernetes entscheidet selbst, auf welchem Node ein Container läuft abhängig von verfügbarem CPU- und Arbeitsspeicher, Affinitätsregeln und Ausfallzonen.  
• Self-Healing: Stürzt ein Container ab oder fällt ein kompletter Node aus, startet Kubernetes den Workload automatisch neu beziehungsweise auf einer anderen Maschine.  
• Horizontale Skalierung: Über den Horizontal Pod Autoscaler wächst die Zahl der Instanzen automatisch mit der Last und schrumpft danach wieder.  
• Rollouts und Rollbacks: Neue Versionen werden schrittweise ausgerollt. Läuft etwas schief, kann auf eine vorherige Version zurückgewechselt werden.  
• Service Discovery und Load Balancing: Container finden einander über interne DNS-Namen, ohne dass IP-Adressen fest verdrahtet werden müssen.  
• Deklarative Konfiguration: Sie beschreiben den gewünschten Zielzustand in YAML. Kubernetes stellt diesen Zustand her und hält ihn dauerhaft aufrecht.  

Wo Kubernetes an seine Grenzen kommt 

Diese Möglichkeiten bringen allerdings zusätzliche Komplexität mit sich. Kubernetes hat eine eigene Begriffswelt etwa Pods, Deployments, Services, Ingress, Persistent Volumes, ConfigMaps und Namespaces. 

Hinzu kommt der laufende Betriebsaufwand: Cluster müssen eingerichtet, überwacht, aktualisiert und abgesichert werden. Gerade für Teams ohne eigene Kubernetes-Expertise kann dieser Aufwand schnell zu einer Herausforderung werden. 

Das ist für euren Artikel besonders praktisch, weil ihr von hier sehr natürlich zu Managed Kubernetes überleiten könnt: Kubernetes bietet die technischen Möglichkeiten, während ein Managed-Angebot einen Teil des damit verbundenen Betriebsaufwands übernimmt. 

Ein häufiges Missverständnis: Nutzt Kubernetes noch Docker?

Diese Frage sorgt regelmäßig für Verwirrung. Seit Version 1.24 unterstützt Kubernetes Docker nicht mehr direkt als Container-Runtime – die sogenannte Dockershim-Schnittstelle wurde entfernt. Stattdessen kommen containerd oder CRI-O zum Einsatz. 

Für Ihren Alltag hat das jedoch kaum Konsequenzen: Images, die Sie mit Docker gebaut haben, entsprechen dem OCI-Standard und laufen unverändert in Kubernetes. Ihr Dockerfile bleibt Ihr Dockerfile, Ihre CI/CD-Pipeline bleibt Ihre Pipeline. Geändert hat sich lediglich, welche Software auf den Cluster-Nodes die Container tatsächlich startet eine Ebene, um die sich bei einer Managed-Lösung ohnehin der Anbieter kümmert. 

Der direkte Vergleich

Wann Docker allein ausreicht 

Sie brauchen kein Kubernetes, wenn folgende Punkte auf Sie zutreffen: 

• Ihre Anwendung besteht aus wenigen Services, die problemlos auf einen leistungsfähigen Server passen. 
• Kurze Wartungsfenster sind für Ihr Geschäft akzeptabel. 
• Ihre Last ist gut vorhersehbar und wächst gleichmäßig. 
• Ihr Team hat keine Kapazität, sich in ein zusätzliches Betriebssystem für Container einzuarbeiten. 

In diesen Fällen bringt Kubernetes vor allem Overhead. Ein sauber betriebener Managed Server oder ein Managed Cluster mit Docker liefert dieselbe Performance bei deutlich geringerer Komplexität. 

Wann Kubernetes den Unterschied macht

Kubernetes zahlt sich aus, sobald mindestens einer dieser Punkte gilt: 

• Lastspitzen sind geschäftskritisch: Black Friday, TV-Kampagnen oder saisonale Peaks im Onlineshop verlangen, dass innerhalb von Minuten zusätzliche Instanzen bereitstehen und danach wieder verschwinden. 
• Hohe Verfügbarkeit ist vertraglich zugesagt: Wenn Ausfallzeiten Umsatz und SLAs kosten, ist automatisches Failover kein Luxus. 
• Ihre Architektur besteht aus vielen Services. Shop-Frontend, API, Suche, Bildverarbeitung, PIM-Anbindung, Queue-Worker, solche Landschaften profitieren stark von Orchestrierung. 
• Sie deployen häufig: Mehrere Releases pro Woche ohne Downtime sind mit Docker Compose mühsam, mit Kubernetes Standard. 
• Sie betreiben mehrere Umgebungen oder Mandanten: Agenturen und SaaS-Anbieter trennen Kunden und Stages sauber über Namespaces und eigene Cluster. 

Ein typisches Beispiel aus dem E-Commerce: Ein Shopware-Shop läuft im Normalbetrieb mit vier Anwendungsinstanzen. Am Aktionstag steigt der Traffic um das Zehnfache. Kubernetes skaliert die Pods automatisch hoch, verteilt sie auf freie Nodes und reduziert sie nach der Kampagne wieder ohne, dass jemand nachts am Terminal sitzt.

Fazit

Docker und Kubernetes ergänzen sich. Docker macht Ihre Anwendung portabel und reproduzierbar, Kubernetes macht ihren Betrieb skalierbar und ausfallsicher. Die eigentliche Entscheidung lautet deshalb nicht „Docker oder Kubernetes", sondern: Brauchen Sie Orchestrierung und wenn ja, wollen Sie sie selbst betreiben? 

Unser Ansatz: Kubernetes ONE bei profihost

Wir haben Kubernetes ONE genau für die Teams entwickelt, die die Vorteile der Orchestrierung nutzen wollen, ohne den Plattformbetrieb selbst zu tragen. Über ein zentrales Dashboard legen Sie Cluster für verschiedene Projekte, Kunden oder Umgebungen selbst an, konfigurieren, skalieren und aktualisieren sie ohne Terminal, ohne DevOps-Ticket und ohne Wartezeit.  

Betrieben wird die Plattform in Deutschland. Der Betrieb ist ISO 27001-zertifiziert und DSGVO-konform aufgestellt. Und wenn sich im Gespräch herausstellt, dass Ihr Projekt heute noch gar kein Kubernetes braucht, sagen wir Ihnen das auch dann ist ein Managed Cluster oder ein Managed Server die bessere und günstigere Lösung.