Docker vs Kubernetes: Compose, Swarm und K8s im Vergleich

Wer mit Docker 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. 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. 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:

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

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 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

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. 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:

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?

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 soll, gibt es mit Kompose ein offizielles Tool, das Compose-Dateien in Kubernetes-Manifeste umwandelt:

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.