--- title: 'Docker vs Kubernetes: Compose, Swarm und K8s im Vergleich' description: 'Docker, Docker Compose, Docker Swarm und Kubernetes im direkten Vergleich: Welches Tool passt zu welchem Problem und wann lohnt sich der Umstieg?' image: src: /images/blog/docker-vs-kubernetes.jpg authors: - name: Thomas Ens to: /about/thomasens avatar: src: /images/blog/authors/thomas.jpeg date: 2026-04-09 tags: published: true --- Wer mit [Docker](https://www.docker.com/) anfängt, startet meistens mit einem einfachen `docker run`. Irgendwann kommen mehr Container dazu, dann vielleicht eine Compose-Datei, und spätestens wenn das Team über Produktion redet, fällt das Wort [Kubernetes](https://kubernetes.io/). An diesem Punkt herrscht oft Verwirrung darüber, was eigentlich was kann und welches Tool für welchen Zweck gebaut wurde. Dieser Artikel stellt Docker, Docker Compose, Docker Swarm und Kubernetes direkt nebeneinander. Nicht mit dem Ziel, einen Gewinner zu küren, sondern um die Entscheidung einfacher zu machen: Welches Tool passt zu welchem Problem? ## Was Docker eigentlich ist und was nicht Docker ist eine [Containerisierungsplattform](/de/blog/how-docker-works). Es sorgt dafür, dass Anwendungen in isolierten, reproduzierbaren Umgebungen laufen – unabhängig davon, ob das der Laptop des Entwicklers oder ein Server im Rechenzentrum ist. Ein Docker-Image enthält den Anwendungscode, alle Abhängigkeiten und die Laufzeitumgebung. Aus einem Image wird ein Container, wenn es gestartet wird. Was Docker von Haus aus *nicht* ist: ein Orchestrierungssystem. Docker selbst kümmert sich nicht darum, wie Container über mehrere Hosts verteilt werden, wie sie bei Ausfall neu gestartet werden oder wie Traffic zwischen ihnen verteilt wird. Dafür braucht man entweder Docker Swarm oder Kubernetes, je nach Anforderung. ## docker run – der direkte Weg zum Container `docker run` ist der einfachste Weg, einen Container zu starten. Wer ein Image lokal testen will, kommt damit sofort ans Ziel: ```bash docker run -d -p 8080:80 --name mein-nginx nginx:latest ``` Das startet nginx im Hintergrund, mappt Port 8080 des Hosts auf Port 80 im Container und gibt dem Container einen Namen. ### Wichtige Flags im Überblick | Flag | Bedeutung | | --- | --- | | `-d` | Container im Hintergrund starten (detached) | | `-p host:container` | Port-Mapping | | `-v host:container` | Volume mounten | | `--env` oder `-e` | Umgebungsvariable setzen | | `--rm` | Container nach dem Stoppen automatisch löschen | | `--name` | Container einen Namen geben | | `--network` | Container einem Netzwerk zuweisen | `docker run` eignet sich für einzelne Container, schnelle Tests und lokale Experimente. Sobald mehrere Container zusammenarbeiten müssen, wird es unhandlich, dann kommt Compose ins Spiel. ## Docker Compose – wenn ein Container nicht reicht Docker Compose löst das Problem, [mehrere Container als zusammenhängendes System](/de/blog/docker-compose-for-beginners) zu definieren und zu starten. Statt einer langen Reihe von `docker run`-Befehlen mit Flags gibt es eine einzige YAML-Datei: ### Ein typisches Compose-File ```yaml services: app: image: meine-app:latest ports: - "3000:3000" environment: DATABASE_URL: postgres://user:pass@db:5432/mydb depends_on: - db db: image: postgres:15 volumes: - pgdata:/var/lib/postgresql/data environment: POSTGRES_PASSWORD: pass volumes: pgdata: ``` Mit `docker compose up -d` startet der gesamte Stack. Compose kümmert sich dabei um die Reihenfolge (dank `depends_on`), das gemeinsame Netzwerk zwischen den Containern und das Management von Volumes. **Wo Compose glänzt:** lokale Entwicklung, CI/CD-Pipelines, kleine Deployments auf einem einzelnen Server. Das Tool ist schnell zu lernen, die Konfiguration ist übersichtlich, und mit einer einzigen Datei hat man die komplette Umgebung beschrieben. **Wo Compose an Grenzen stößt:** Compose ist auf einen einzelnen Host ausgelegt. Kein automatisches Failover über mehrere Server, kein eingebautes Load Balancing zwischen Hosts, keine automatische Skalierung. Für alles, was über eine Maschine hinausgeht, braucht man etwas anderes. ## Docker Swarm – Cluster ohne Kubernetes-Komplexität Docker Swarm ist das [native Clustering-Feature von Docker](/de/blog/what-is-docker-swarm). Mit einem `docker swarm init` wird eine Maschine zum Manager-Node, weitere Nodes können per Token beitreten. Danach können Services definiert werden – also Container, die über den Cluster verteilt laufen: ```bash docker service create --replicas 3 -p 80:80 --name web nginx:latest ``` Swarm kümmert sich darum, dass zu jedem Zeitpunkt drei Replikas laufen. Fällt ein Node aus, werden die betroffenen Container auf anderen Nodes neu gestartet. Rolling Updates sind ebenfalls eingebaut. Das Besondere an Swarm: Wer Compose kennt, kennt auch Swarm fast schon. Compose-Dateien lassen sich mit minimalen Anpassungen als Swarm-Stacks deployen. Das macht den Einstieg sehr niedrigschwellig. **Der Haken:** Das Swarm-Ökosystem ist in den letzten Jahren deutlich kleiner geworden. Viele Tools, Integrationen und Cloud-Provider haben sich auf Kubernetes konzentriert. Swarm ist technisch solide, aber wer in Richtung Produktion denkt, muss abwägen, ob das langfristig trägt. ## Docker vs Kubernetes – der eigentliche Vergleich Kubernetes ist heute die Standardantwort auf die Frage nach Container-Orchestrierung in Produktion. Das stimmt, aber es ist kein Tool, das man mal eben nebenbei einführt. Der zentrale Unterschied zu Swarm: Kubernetes ist kein Feature von Docker, sondern ein eigenständiges System mit eigener API, eigenem CLI (`kubectl`) und einem deutlich umfangreicheren Konzeptmodell. Statt Services gibt es Pods, Deployments, ReplicaSets, StatefulSets, DaemonSets. Statt einfachen Port-Mappings gibt es Services vom Typ ClusterIP, NodePort oder LoadBalancer, plus Ingress-Ressourcen für HTTP-Routing. Das klingt erst mal nach Overhead und das ist es auch, wenn man nur einen Stack mit drei Containern betreiben will. Aber Kubernetes zahlt sich aus, sobald folgendes zutrifft: - Die Infrastruktur läuft über mehrere Nodes - Automatisches Scaling ist gefragt (Horizontal Pod Autoscaler) - Komplexes Netzwerk- und Zugriffsmanagement (RBAC, NetworkPolicies) - CI/CD-Pipelines sollen direkt mit der Infrastruktur interagieren - Monitoring, Logging und Observability müssen tief integriert sein ### [Wann reicht Swarm, wann braucht man Kubernetes?](/de/blog/kubernetes-vs-docker-swarm) | Kriterium | Docker Compose | Docker Swarm | Kubernetes | | --- | --- | --- | --- | | Anzahl Hosts | 1 | 2–10 | beliebig | | Lernkurve | niedrig | mittel | hoch | | Produktionsreife | begrenzt | gut für einfache Cases | sehr gut | | Ökosystem | groß (lokal) | kleiner werdend | sehr groß | | Automatisches Scaling | nein | manuell | ja (HPA) | | Managed-Angebote | nein | selten | überall verfügbar | Für ein kleines Team, das eine Handvoll Services betreibt und keine Lust auf Kubernetes-Komplexität hat, ist Swarm eine valide Wahl. Für alles, was in Richtung Skalierung, Multi-Team-Betrieb oder Cloud-native Architektur geht, ist Kubernetes der realistischere Weg. ## Von Compose zu Kubernetes migrieren Wenn ein Projekt mit Compose gestartet wurde und irgendwann [auf Kubernetes migriert werden](/de/blog/kubernetes-migration-guide) soll, gibt es mit Kompose ein offizielles Tool, das Compose-Dateien in Kubernetes-Manifeste umwandelt: ```bash kompose convert -f docker-compose.yml ``` Das Ergebnis sind `Deployment`- und `Service`-Manifeste, die als Ausgangspunkt dienen können. Direkt produktionsreif sind sie meistens nicht – Ressourcenlimits, Liveness Probes, ConfigMaps und Secrets müssen manuell ergänzt werden. Aber als Einstiegspunkt spart Kompose erheblich Zeit. **Typische Stolperstellen bei der Migration:** - `depends_on` gibt es in Kubernetes nicht, Readiness Probes übernehmen diese Aufgabe - Volumes müssen als PersistentVolumeClaims definiert werden - Umgebungsvariablen sollten in ConfigMaps oder Secrets ausgelagert werden, nicht direkt im Deployment-Manifest stehen - Netzwerkkommunikation zwischen Services läuft über Kubernetes-Service-Namen, nicht über Container-Namen ## Managed Kubernetes als Alternative zum Selbstbetrieb Kubernetes selbst zu betreiben ist eine eigene Disziplin. Control Plane hochziehen, etcd-Cluster absichern, Upgrades durchführen, Node-Probleme debuggen, das bindet Kapazitäten, die in vielen Teams besser in die eigentliche Produktentwicklung fließen würden. Managed Kubernetes, also Kubernetes-Cluster, die von einem Provider betrieben werden, löst dieses Problem zum Teil. GKE, EKS und AKS nehmen einem den Control Plane ab. Die eigentliche Frage ist dann: Wie viel Kubernetes-Wissen und -Betrieb will man trotzdem selbst verantworten? Wer den Betrieb noch weiter abstrahieren will, kann auf DevOps-as-a-Service-Plattformen (DaaS) setzen, die Kubernetes als Grundlage nutzen, aber eine vereinfachte Oberfläche und einen gemanagten Betrieb bieten. lowcloud zum Beispiel ist eine Kubernetes-basierte DaaS-Plattform, die speziell für Teams gebaut wurde, die von den Vorteilen von Kubernetes profitieren wollen, ohne sich um den Infrastrukturunterbau zu kümmern. Deployments, Skalierung und Networking laufen über die Plattform, das Team fokussiert sich auf den Code. ## Entscheidungshilfe: Welches Tool wann? Kurz zusammengefasst: - **docker run** – für lokale Tests, einzelne Container, schnelle Experimente - **Docker Compose** – für lokale Entwicklung und einfache Ein-Host-Deployments - **Docker Swarm** – für kleine Cluster mit geringem Komplexitätsbudget - **Kubernetes** – für Produktionsumgebungen mit Skalierungsanforderungen, Multi-Team-Betrieb und Cloud-native Architektur Kein Tool ist für alle Fälle das richtige. Die Frage ist nicht "Was ist am besten?", sondern "Was brauche ich heute – und was werde ich in sechs Monaten brauchen?". Wer mit Compose startet, schließt Kubernetes nicht aus. Aber wer von Anfang an weiß, dass Skalierung und Hochverfügbarkeit gefragt sein werden, spart sich den Umweg.