Docker Swarm vs Kubernetes: Wann sich welche Orchestrierung lohnt

1. Warum die Frage Swarm gegen Kubernetes überhaupt gestellt wird

Sobald ein Team mehr als einen Host mit Containern betreibt, taucht früher oder später die Frage nach der richtigen Orchestrierung auf. Docker Swarm und Kubernetes lösen dasselbe Kernproblem: Container über mehrere Maschinen verteilen, ausgefallene Instanzen ersetzen und den Zugriff über ein stabiles Netzwerk organisieren. Der Unterschied liegt nicht in der grundsätzlichen Fähigkeit, sondern im Umfang, in der Lernkurve und im täglichen Betriebsaufwand, den beide Systeme von einem Team verlangen.

Viele Teams entscheiden sich für Kubernetes, weil es der De facto Standard in der Branche ist, ohne die tatsächliche Komplexität ihrer eigenen Anwendung gegen den Betriebsaufwand des Clusters abzuwägen. Docker Swarm wird dagegen oft vorschnell als veraltet abgetan, obwohl es für kleinere und mittlere Teams mit überschaubarer Service-Anzahl weiterhin eine solide, deutlich einfachere Alternative ist. Dieser Artikel arbeitet die architektonischen und praktischen Unterschiede heraus, damit die Entscheidung auf echten Kriterien basiert statt auf Trends.

2. Docker Swarm im Kern: Architektur und Konzepte

Docker Swarm ist direkt in die Docker Engine integriert und benötigt keine zusätzliche Installation. Ein Cluster besteht aus Manager-Nodes, die den gewünschten Zustand verwalten und Entscheidungen über die Platzierung von Containern treffen, sowie Worker-Nodes, die ausschließlich Container ausführen. Die Manager verwenden intern den Raft-Konsens-Algorithmus, um auch bei Ausfall einzelner Manager-Instanzen eine konsistente Sicht auf den Cluster-Zustand zu behalten. Für Hochverfügbarkeit reichen drei oder fünf Manager-Nodes, mehr verbessert die Fehlertoleranz kaum noch messbar.

Das zentrale Objekt in Docker Swarm ist der Service. Ein Service beschreibt, welches Image in wie vielen Replikaten laufen soll, welche Ports veröffentlicht werden und welche Ressourcenlimits gelten. Der Swarm-Scheduler verteilt die Replikate automatisch auf verfügbare Worker-Nodes und startet sie bei einem Node-Ausfall auf einem anderen Node neu. Diese Grundkonzepte lassen sich mit dem gewohnten Docker-Kommandozeilen-Werkzeug direkt anwenden, ohne eine neue Werkzeugkette zu lernen.

# Initialize a Docker Swarm cluster on the first manager node
docker swarm init --advertise-addr 10.0.0.10

# Output includes a join token for worker nodes, e.g.:
# docker swarm join --token SWMTKN-1-xxxx 10.0.0.10:2377

# Add additional manager nodes for high availability (odd number recommended)
docker swarm join-token manager
docker swarm join --token SWMTKN-1-manager-token 10.0.0.10:2377

# Inspect current cluster state
docker node ls
docker node inspect self --pretty

3. Kubernetes im Kern: Architektur und Konzepte

Kubernetes verfolgt einen deutlich granulareren Ansatz als Docker Swarm. Statt eines einzelnen Service-Objekts arbeitet Kubernetes mit einer Schicht aus Pods, ReplicaSets, Deployments und Services, die jeweils eine eigene Verantwortung tragen. Ein Pod ist die kleinste deploybare Einheit und kann einen oder mehrere eng gekoppelte Container enthalten. Ein Deployment beschreibt den gewünschten Zustand einer Pod-Gruppe und steuert Rolling Updates, während ein Service die stabile Netzwerkadresse für eine Gruppe von Pods bereitstellt.

Die Kontrollebene von Kubernetes besteht aus mehreren spezialisierten Komponenten: dem API-Server als zentraler Schnittstelle, etcd als verteiltem Key-Value-Store für den Cluster-Zustand, dem Scheduler für die Platzierungsentscheidungen und dem Controller-Manager, der kontinuierlich den Ist-Zustand mit dem Soll-Zustand abgleicht. Diese Aufteilung macht Kubernetes hochgradig erweiterbar über Custom Resource Definitions und Operatoren, verlangt im Gegenzug aber deutlich mehr Verständnis für die interne Funktionsweise, bevor ein Team produktiv damit arbeiten kann.

# deployment.yaml — Kubernetes equivalent of a Docker Swarm service
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop-api
  labels:
    app: shop-api
spec:
  replicas: 4
  selector:
    matchLabels:
      app: shop-api
  template:
    metadata:
      labels:
        app: shop-api
    spec:
      containers:
        - name: shop-api
          image: registry.example.com/shop-api:1.4.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: shop-api
spec:
  selector:
    app: shop-api
  ports:
    - port: 80
      targetPort: 8080

4. Einstiegshürde und Betriebsaufwand im Vergleich

Der wohl deutlichste Unterschied zwischen Docker Swarm und Kubernetes liegt im Betriebsaufwand. Ein Docker Swarm Cluster ist mit einem einzigen Kommando initialisiert, benötigt keine separate Installation und nutzt dieselbe CLI, die Entwickler bereits von lokaler Docker-Entwicklung kennen. Ein Team ohne dediziertes Platform-Engineering kann einen kleinen Swarm-Cluster innerhalb eines Nachmittags produktiv betreiben, inklusive Reverse Proxy und TLS-Zertifikaten.

Kubernetes verlangt dagegen eine bewusste Entscheidung für eine Distribution (managed wie EKS, GKE, AKS, oder selbstverwaltet wie kubeadm oder k3s), eigenes Wissen über Namespaces, RBAC, Ingress-Controller, Storage-Classes und Netzwerk-Plugins. Diese Komplexität zahlt sich bei großen Teams mit vielen Microservices und dediziertem Ops-Personal aus, wird bei kleinen Teams aber schnell zur Belastung, weil ständig neue Kubernetes-Konzepte gelernt werden müssen, statt an der eigentlichen Anwendung zu arbeiten. Die realistische Frage lautet nicht, welches System mächtiger ist, sondern welchen Betriebsaufwand ein Team dauerhaft tragen kann und will.

5. Skalierung und Self Healing in beiden Systemen

Beide Systeme bieten automatisches Neustarten fehlgeschlagener Container und horizontale Skalierung, aber mit unterschiedlicher Feinsteuerung. Docker Swarm skaliert einen Service mit einem einzigen Kommando und verteilt die neuen Replikate automatisch über verfügbare Nodes, orientiert sich dabei aber nur an einfachen Constraints wie Labels oder Ressourcenreservierungen. Für die meisten Anwendungen mit vorhersehbarer Last reicht dieses Modell vollkommen aus.

Kubernetes bietet mit dem Horizontal Pod Autoscaler und dem Vertical Pod Autoscaler deutlich feinere Steuerungsmöglichkeiten, die Skalierung anhand von CPU-Auslastung, Speicherverbrauch oder sogar benutzerdefinierten Metriken wie Warteschlangenlänge automatisieren. Für Anwendungen mit stark schwankender Last, etwa saisonale Shop-Spitzen oder Batch-Verarbeitung, ist dieses Maß an Automatisierung ein echter Vorteil. Für gleichmäßige Lasten mit bekannten Spitzenzeiten ist der Mehrwert gegenüber der einfachen Swarm-Skalierung dagegen oft gering.

# Scale a Docker Swarm service up or down
docker service scale shop_api=6

# Kubernetes equivalent, manual scaling
kubectl scale deployment/shop-api --replicas=6

# Kubernetes Horizontal Pod Autoscaler based on CPU usage
kubectl autoscale deployment/shop-api --cpu-percent=70 --min=3 --max=10

6. Networking und Service Discovery im Vergleich

In Docker Swarm läuft Service Discovery über einen eingebauten DNS-Server, der innerhalb des Overlay-Netzwerks automatisch für jeden Service einen Namenseintrag anlegt. Ein Container erreicht einen anderen Service einfach über dessen Servicenamen, ohne dass Adressen manuell konfiguriert werden müssen. Der eingebaute Routing-Mesh leitet eingehende Anfragen an einem beliebigen Node automatisch an eine gesunde Instanz weiter, unabhängig davon, auf welchem Node diese läuft.

Kubernetes verwendet ebenfalls internes DNS über CoreDNS, kombiniert es aber mit einem deutlich flexibleren Service-Modell: ClusterIP für interne Kommunikation, NodePort für einfache externe Erreichbarkeit, LoadBalancer für Cloud-Provider-Integration und Ingress-Controller für HTTP-Routing mit Host- und Pfad-basierten Regeln. Diese Flexibilität erlaubt komplexe Routing-Szenarien mit mehreren Domains und TLS-Terminierung, verlangt im Gegenzug aber, dass ein Team versteht, welche der vier Service-Varianten für welchen Anwendungsfall die richtige ist.

7. Deployment Workflows: docker stack deploy gegen kubectl apply

Der Deployment-Workflow in Docker Swarm basiert auf demselben Compose-Format, das viele Teams bereits aus der lokalen Entwicklung kennen. Mit docker stack deploy -c docker-compose.yml shop wird ein kompletter Stack aus mehreren Services in einem Schritt ausgerollt, inklusive Netzwerken, Volumes und Secrets. Diese Kontinuität zwischen lokaler Entwicklung und Produktionsumgebung reduziert Reibung erheblich, weil dieselbe Datei mit kleinen Anpassungen in beiden Umgebungen funktioniert.

Kubernetes trennt diese beiden Welten stärker. Lokale Entwicklung läuft meist über Docker Compose oder ein lokales Kubernetes wie kind oder minikube, während die Produktionsdeployments über kubectl apply -f oder ein Paketmanager wie Helm erfolgen. Diese Trennung bringt zusätzliche Werkzeuge und Übersetzungsschritte mit sich, ermöglicht aber auch deutlich ausgefeiltere Deployment-Strategien wie Canary-Releases oder Blue-Green-Deployments über spezialisierte Controller, die es in Docker Swarm ohne zusätzliche Werkzeuge nicht gibt.

# Docker Swarm: deploy an entire stack from a compose file
docker stack deploy -c docker-compose.prod.yml shop

# List running stacks and their services
docker stack ls
docker stack services shop

# Kubernetes: apply a manifest and check rollout status
kubectl apply -f deployment.yaml
kubectl rollout status deployment/shop-api

# Kubernetes via Helm chart
helm upgrade --install shop-api ./charts/shop-api --namespace shop

8. Ökosystem, Tooling und Team-Realität

Das Ökosystem rund um Kubernetes ist inzwischen wesentlich größer als das von Docker Swarm. Service Meshes wie Istio oder Linkerd, GitOps-Werkzeuge wie ArgoCD oder Flux, und eine riesige Anzahl an Operatoren für Datenbanken, Message Queues und Monitoring-Systeme sind primär für Kubernetes gebaut. Wer in einem Umfeld arbeitet, das diese Werkzeuge bereits einsetzt oder mittelfristig einsetzen will, profitiert direkt von der Kubernetes-Kompatibilität.

Docker Swarm hat dieses Ökosystem nicht in vergleichbarer Breite, bietet dafür aber eine deutlich kleinere Angriffsfläche für Fehlkonfiguration und weniger bewegliche Teile, die gewartet werden müssen. Für ein Team, das primär eine Handvoll Services stabil betreiben will, ohne einen eigenen Platform-Engineering-Bereich aufzubauen, ist die geringere Werkzeugvielfalt kein Nachteil, sondern reduziert die kognitive Last im Alltag spürbar.

9. Docker Swarm und Kubernetes im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten Entscheidungskriterien zusammen, die in der Praxis tatsächlich den Ausschlag geben, wenn ein Team zwischen Docker Swarm und Kubernetes wählt.

Diese Gegenüberstellung zeigt, dass es kein universell besseres System gibt. Docker Swarm gewinnt, wenn Einfachheit und geringer Betriebsaufwand im Vordergrund stehen, Kubernetes gewinnt, wenn ein Team die zusätzliche Komplexität durch die Vorteile im Ökosystem und in der Feinsteuerung tatsächlich ausschöpft.

10. Zusammenfassung

Docker Swarm vs Kubernetes ist keine Frage von gut gegen schlecht, sondern von passendem Werkzeug gegen unpassenden Overhead. Docker Swarm integriert sich nahtlos in die Docker Engine, nutzt dasselbe Compose-Format wie die lokale Entwicklung und ist innerhalb kurzer Zeit produktiv einsatzbereit. Kubernetes bietet dagegen ein deutlich größeres Ökosystem, feinere Skalierungsmechanismen und mehr Kontrolle über komplexe Deployment-Strategien, verlangt im Gegenzug aber erhebliches Zusatzwissen und mehr laufende Komponenten.

Die richtige Entscheidung ergibt sich aus der ehrlichen Einschätzung der eigenen Team-Größe, der Anzahl der Services und des verfügbaren Ops-Wissens. Ein kleines Team mit wenigen Services fährt mit Docker Swarm oft produktiver, ein großes Team mit vielen Microservices und dediziertem Platform-Engineering profitiert von den zusätzlichen Möglichkeiten in Kubernetes. Beide Systeme lösen Container-Orchestrierung solide, der Unterschied liegt im passenden Maß an Komplexität für die jeweilige Situation.

11. FAQ: Docker Swarm vs Kubernetes