Docker Swarm vs Kubernetes 2026: Wann Swarm reicht

TL;DR

Docker Swarm vs Kubernetes ist 2026 keine Glaubensfrage mehr. Swarm reicht, wenn Sie wenige Dienste aus Compose-Dateien auf einer Handvoll Servern betreiben und keinen Autoscaler, keine Operatoren und kein Managed-Angebot brauchen. Kubernetes passt, sobald Teams, Mandanten oder Compliance wachsen, weil es in Deutschland gemanagt bei STACKIT, IONOS und weiteren Anbietern verfügbar ist.

Was unterscheidet Docker Swarm und Kubernetes grundsätzlich?

Docker Swarm ist der in Docker Engine eingebaute Orchestrator: Sie schalten ihn mit einem Befehl ein und deployen Compose-Dateien als Stacks. Kubernetes ist eine eigenständige Plattform mit eigener API, eigenem Ökosystem und einem Release-Zyklus der Upstream-Community. Swarm optimiert auf Einfachheit, Kubernetes auf Erweiterbarkeit und Standardisierung über Anbieter hinweg, und den Grundunterschied zwischen Docker auf einem Host und einem Cluster erklärt unser Vergleich Kubernetes vs Docker.

Die Docker-Dokumentation beschreibt Swarm mode am 2. Oktober 2026 mit diesen Kernfunktionen: Clusterverwaltung direkt in Docker Engine, deklaratives Service-Modell, Skalierung über die Replica-Zahl, Abgleich des Soll-Zustands, Overlay-Netze über mehrere Hosts, DNS-basierte Service Discovery mit Load Balancing, gegenseitige TLS-Authentifizierung zwischen den Nodes und Rolling Updates mit Rollback. Wichtig für die Begriffe: Gemeint ist immer Swarm mode. Das ältere “Docker Classic Swarm” entwickelt Docker nicht mehr aktiv weiter.

Kubernetes bringt dieselben Grundbausteine mit (Deployments, Services, Rolling Updates), ergänzt aber Dinge, die Swarm nicht hat: Custom Resource Definitions und Operatoren, einen eingebauten Horizontal Pod Autoscaler, dessen Kontrollschleife standardmäßig alle 15 Sekunden läuft, Namespaces mit RBAC für Mandantentrennung und ein Netzwerk-Policy-Modell. Die folgende Tabelle fasst die Unterschiede zusammen, die bei der Entscheidung zählen.

Kriterium	Docker Swarm (Swarm mode)	Kubernetes
Installation	in Docker Engine enthalten, `docker swarm init`	eigene Distribution oder Managed-Angebot
Deployment-Format	Compose-Datei, `docker stack deploy`	YAML-Manifeste, Helm, Kustomize
Konsens der Control Plane	Raft in den Manager-Nodes	etcd
Autoscaling	keines eingebaut, Replicas manuell	HPA eingebaut, Kontrollschleife alle 15 s
Erweiterbarkeit	keine eigenen Ressourcentypen	CRDs und Operatoren
Mandantentrennung	keine Namespaces	Namespaces, RBAC, NetworkPolicies
Managed-Angebote in DE	keines gefunden	u. a. STACKIT SKE, IONOS, Hyperscaler
Herstellersupport	Mirantis MKE 3 bis mindestens 2030	viele Anbieter und Distributionen

Ist Docker Swarm 2026 noch eine sichere Wahl?

Ja, für passende Größenordnungen. Swarm mode wird mit Docker Engine weiterentwickelt, und Mirantis hat kommerziellen Support bis mindestens 2030 zugesagt. Das Risiko liegt nicht im Abschalten, sondern im kleinen Ökosystem: Es gibt weniger Werkzeuge, weniger Fachkräfte mit Swarm-Erfahrung und in Deutschland kein Managed-Angebot, das Ihnen den Betrieb abnimmt.

Die belegbaren Signale vom 2. Oktober 2026:

Die Docker Engine Release Notes führen Version 29.8.2 vom 30. September 2026. Schon das Major-Release 29.0.0 hat nach Docker-Angaben die Zuverlässigkeit von Overlay-Netz und Routing Mesh “greatly improved”, also genau den Teil, an dem Swarm-Cluster in der Praxis am häufigsten hakten.
Mirantis schrieb am 1. Juli 2025: “Swarm will be fully supported through at least 2030 as part of Mirantis Kubernetes Engine 3.” Dazu kam Unterstützung für das Container Storage Interface (CSI) in MKE 3, damit Swarm zustandsbehaftete Workloads mit Enterprise-Storage betreiben kann.

Die Grenze dieser Zusage: Sie gilt für MKE 3, ein kommerzielles Produkt mit Kubernetes und Swarm als Doppel-Orchestrator. Wer Swarm kostenlos auf eigener Docker Engine betreibt, hat keinen Support-Vertrag, sondern die Community. Zum Vergleich: Das Kubernetes-Projekt pflegt immer die drei jüngsten Minor-Versionen, derzeit 1.37, 1.36 und 1.35, mit rund einem Jahr Patch-Support je Version. 1.37 erreicht sein Lebensende am 28. Oktober 2027. Dieser Takt bedeutet Upgrade-Aufwand, aber auch einen verlässlichen Plan.

Wann reicht Docker Swarm?

Swarm reicht, wenn die Anwendung aus wenigen, stabilen Diensten besteht, das Team bereits mit Compose arbeitet und eine feste Zahl an Replicas genügt. Typisch sind interne Tools, Standort-Server in der Fertigung oder ein Webshop mit fünf bis zehn Containern. Sobald Sie Autoscaling, Operatoren für Datenbanken oder mehrere Teams auf einem Cluster brauchen, stoßen Sie an Grenzen.

Kriterien, bei denen Swarm nach unserer Einschätzung genügt:

Compose ist schon da. Ihre Dienste laufen mit Docker Compose, und Sie wollen dieselbe Datei auf mehreren Hosts ausrollen.
Feste Last. Die Replica-Zahl ändert sich selten. Swarm skaliert nur, wenn Sie docker service scale aufrufen.
Ein Team, ein Cluster. Es gibt keine Mandanten, die per Namespace und RBAC getrennt werden müssen.
Kein Bedarf an Operatoren. Datenbanken laufen außerhalb des Clusters oder als einfache Container mit Volume.
Eigener Betrieb ist akzeptiert. Niemand erwartet ein Managed-Angebot mit SLA für die Orchestrierungsschicht.

Für die Ausfallsicherheit gilt die Raft-Regel aus der Swarm-Admin-Doku: Ein Swarm toleriert bis zu (N-1)/2 dauerhafte Manager-Ausfälle. Drei Manager verkraften einen Ausfall, fünf Manager zwei, sieben Manager drei. Docker empfiehlt eine ungerade Zahl und weist darauf hin, dass jeder weitere Manager die Schreibleistung senkt, weil mehr Nodes jede Änderung bestätigen müssen.

So entsteht ein Swarm mit drei Managern und einem Stack:

# Node 1: Swarm initialisieren
docker swarm init --advertise-addr 10.0.0.2

# Token für weitere Manager ausgeben und auf Node 2 und 3 ausführen
docker swarm join-token manager

# Stack aus einer Compose-Datei ausrollen
docker stack deploy --compose-file compose.yaml shop
docker service ls

Eine Falle bei docker stack deploy: Laut Docker-Doku ignoriert der Befehl die Option build und nutzt das ältere Compose-Dateiformat Version 3 statt der aktuellen Compose Specification. Images müssen vorher in einer Registry liegen, damit alle Nodes sie ziehen können.

Was kostet Swarm im Vergleich zu Managed Kubernetes?

Swarm auf drei kleinen Hetzner-Servern kostet nach Listenpreis 16,47 € netto im Monat ohne IPv4. Ein Managed Kubernetes mit drei vergleichbaren Nodes liegt bei IONOS bei rund 95 €, bei STACKIT SKE bei rund 165 € netto. Den Aufpreis zahlen Sie für eine betriebene Control Plane und automatisierte Upgrades.

Die Rechnung mit Listenpreisen vom 2. Oktober 2026, netto, Rechenzentren in Deutschland, jeweils drei Nodes mit 2 vCPU und 4 GB RAM, ohne Storage, Load Balancer und IP-Adressen:

Variante	Control Plane / Monat	Nodes / Monat	Summe netto / Monat
Swarm selbst auf Hetzner Cloud (3 × CX23)	0 € (Manager auf den Nodes)	3 × 5,49 € = 16,47 €	16,47 €
IONOS Managed Kubernetes (Shared vCPU)	kostenfrei	3 × 31,68 € = 95,04 €	95,04 €
STACKIT SKE EU01 (3 × c2i.2)	71,71 €	3 × 31,17 € = 93,51 €	165,22 €

Rechenweg und Quellen:

Hetzner: CX23 kostet seit 15. Juni 2026 nach der Hetzner-Preisanpassung 5,49 € pro Monat ohne IPv4 (Deutschland/Finnland), Ausstattung 2 vCPU und 4 GB RAM (Hetzner-Ankündigung). 3 × 5,49 € = 16,47 €. Die Verfügbarkeit der Cost-Optimized-Typen schwankt, prüfen Sie sie vor der Bestellung.
IONOS: Control Plane kostenfrei, Shared vCPU 0,017 € pro Stunde und RAM 0,0025 € pro GB und Stunde laut IONOS. Je Node: (2 × 0,017 € + 4 × 0,0025 €) × 720 h = 31,68 €.
STACKIT: Cluster Management 0,09959511998 € pro Stunde, c2i.2 (2 vCPU, 4 GB) in EU01 0,04328965278 € pro Stunde laut SKU-Katalog. Bei 720 h sind das 71,71 € und 31,17 € je Node.

Die reinen Infrastrukturkosten sagen nur die halbe Wahrheit. Bei Swarm betreiben Sie Manager, Zertifikatsrotation, Docker-Engine-Updates und Backups des Raft-Zustands selbst. Bei Managed Kubernetes übernimmt der Anbieter die Control Plane, Sie kümmern sich um Version-Upgrades im Takt von Upstream und um die Worker-Images. Wie stark das Node-Betriebssystem dabei mitwandert, zeigt die AKS-Ankündigung zu Ubuntu 26.04. Einen breiteren Preisvergleich über zehn Anbieter finden Sie im Managed-Kubernetes-Kostenvergleich.

Wer zwischen Swarm und vollem Kubernetes eine leichte Zwischenstufe sucht, sollte sich k3s auf eigenen Servern ansehen: gleiche Kubernetes-API, aber geringer Ressourcenbedarf und ein Installationsbefehl pro Node.

Wie migrieren Sie von Docker Swarm zu Kubernetes?

Die Migration beginnt mit den Compose-Dateien: Das offizielle Kubernetes-Projekt Kompose übersetzt sie in Deployments und Services. Danach ergänzen Sie, was Compose nicht kennt, etwa Ingress, Ressourcen-Limits, Probes und Autoscaling. Planen Sie die Umstellung dienstweise, nicht als Big Bang, und betreiben Sie Swarm parallel, bis alle Dienste umgezogen sind.

Kompose bezeichnet sich als “an official Kubernetes project” unter Apache-2.0-Lizenz, das aktuelle Release auf GitHub ist v1.38.0 vom 15. Januar 2026. Die Kompose-Anleitung nennt Details, die bei Swarm-Stacks wichtig sind: Mit dem Label kompose.controller.type wählen Sie Deployment, DaemonSet oder StatefulSet. Hat ein Dienst ein Volume, setzt Kompose die Update-Strategie auf “Recreate” statt “RollingUpdate”. Über Labels wie kompose.hpa.replicas.min und kompose.hpa.cpu erzeugt es auch einen Horizontal Pod Autoscaler.

Der Ablauf in sechs Schritten:

Inventar. Alle Stacks, Secrets, Configs, Overlay-Netze und Volumes auflisten (docker stack ls, docker secret ls, docker volume ls).
Images in die Registry. Da Swarm ohnehin eine Registry braucht, ist dieser Schritt meist erledigt. Prüfen Sie, ob der Ziel-Cluster sie erreicht.
Konvertieren. Kompose auf jede Compose-Datei anwenden und die Manifeste ins Git-Repository legen.
Nacharbeiten. Ingress statt Routing Mesh, Ressourcen-Requests (Voraussetzung für den HPA), Liveness- und Readiness-Probes, Secrets als Kubernetes-Secrets.
Persistente Daten. Volumes auf StorageClasses des Anbieters abbilden und Daten migrieren, bei Datenbanken mit Dump und Restore.
Umschalten. DNS dienstweise auf den neuen Ingress drehen, Swarm-Service erst nach einer Beobachtungsphase entfernen.

# Compose-Datei in Kubernetes-Manifeste übersetzen
kompose convert -f compose.yaml -o k8s/

# Auf den Managed-Cluster anwenden und prüfen
kubectl apply -f k8s/
kubectl get pods,svc

Bei Swarm-spezifischen Eigenheiten hilft Kompose nur begrenzt. Das Routing Mesh, das jeden veröffentlichten Port auf allen Nodes bereitstellt, gibt es in Kubernetes so nicht: Sie ersetzen es durch einen Service vom Typ LoadBalancer oder einen Ingress Controller. Plattformwahl und Distributionen ordnet unser Vergleich OpenShift vs Rancher ein.

Für wen passt was?

Swarm passt für Teams, die wenige Dienste aus Compose betreiben, Kosten minimieren und den Betrieb selbst tragen wollen. Managed Kubernetes passt für Organisationen, die Autoscaling, Mandantentrennung oder einen Anbieter mit deutschem Rechenzentrum und Vertrag brauchen. Wer heute mit Swarm startet, sollte Compose-Dateien so pflegen, dass ein späterer Umzug mit Kompose möglich bleibt.

Situation	Passt eher	Kriterium
3 bis 10 Dienste, ein Team, feste Last	Docker Swarm	geringster Betriebs- und Lernaufwand
Bestehende MKE-3-Umgebung mit Support	Docker Swarm (MKE 3)	Herstellersupport bis mindestens 2030
Schwankende Last, Autoscaling nötig	Kubernetes	HPA eingebaut
Mehrere Teams oder Mandanten	Kubernetes	Namespaces, RBAC, NetworkPolicies
Betrieb soll ausgelagert werden	Managed Kubernetes	Control Plane vom Anbieter, Swarm-Managed-Angebot fehlt
Kleines Budget, Kubernetes-API gewünscht	k3s selbst betrieben	Kubernetes-kompatibel bei geringem Ressourcenbedarf

Stärken von Swarm: in Docker Engine enthalten, Compose-kompatibel, geringer Ressourcenbedarf, wenige bewegliche Teile. Grenzen: kein eingebautes Autoscaling, keine CRDs, kleines Ökosystem, kein Managed-Angebot in Deutschland gefunden, docker stack deploy hängt am älteren Compose-Format. Stärken von Kubernetes: Standard-API über alle Anbieter, Managed-Angebote mit deutschen Rechenzentren, großes Ökosystem. Grenzen: höhere Komplexität, Upgrade-Takt von etwa einem Jahr pro Minor-Version, höhere Grundkosten.

FAQ

Was ist der wichtigste Unterschied zwischen Docker Swarm und Kubernetes?

Swarm ist ein in Docker Engine eingebauter Orchestrator, der Compose-Dateien auf mehreren Hosts ausrollt. Kubernetes ist eine eigenständige, erweiterbare Plattform mit eigener API, Autoscaling, Namespaces und Operatoren. Swarm ist einfacher, Kubernetes ist Standard bei Managed-Anbietern.

Wird Docker Swarm eingestellt?

Nein. Swarm mode wird mit Docker Engine weiterentwickelt, Version 29 hat Overlay-Netz und Routing Mesh verbessert. Mirantis hat am 1. Juli 2025 vollen Support für Swarm bis mindestens 2030 als Teil von Mirantis Kubernetes Engine 3 zugesagt. Eingestellt ist nur das ältere Docker Classic Swarm.

Was kostet Docker Swarm im Vergleich zu Managed Kubernetes?

Swarm selbst kostet nichts, Sie zahlen nur Server. Drei Hetzner CX23 kosten 16,47 € netto im Monat ohne IPv4. Drei vergleichbare Nodes bei IONOS Managed Kubernetes kosten rund 95,04 €, bei STACKIT SKE inklusive Cluster Management rund 165,22 € netto im Monat (Stand 2. Oktober 2026, 720 Stunden).

Docker Swarm vs k3s: Was ist für kleine Cluster besser?

k3s bietet die Kubernetes-API bei geringem Ressourcenbedarf, Swarm bietet Compose-Kompatibilität ohne neue Konzepte. Wer später zu Managed Kubernetes wechseln will, ist mit k3s näher am Ziel. Wer nur Compose-Stacks auf drei Servern betreiben will, kommt mit Swarm schneller ans Ziel.

Gibt es Managed Docker Swarm in Deutschland?

Bei den Anbietern in unserer Vergleichsmatrix haben wir kein Managed-Swarm-Angebot gefunden. STACKIT, IONOS und die Hyperscaler bieten Managed Kubernetes an. Kommerziellen Swarm-Support gibt es über Mirantis Kubernetes Engine 3, das Sie selbst oder über einen Partner betreiben.

Wie lange dauert eine Migration von Swarm zu Kubernetes?

Das hängt von der Zahl der Dienste und den persistenten Daten ab, eine seriöse Pauschalzahl gibt es nicht. Zustandslose Dienste lassen sich mit Kompose schnell übersetzen. Den meisten Aufwand machen Datenbanken, Ingress statt Routing Mesh und das Nachrüsten von Probes und Ressourcen-Limits.

Quellen

Docker Docs: Swarm mode overview (abgerufen 2. Oktober 2026)
Docker Docs: Administer and maintain a swarm (abgerufen 2. Oktober 2026)
Docker Docs: Deploy a stack to a swarm (abgerufen 2. Oktober 2026)
Docker Engine Release Notes v29 (abgerufen 2. Oktober 2026)
Mirantis: Long-Term Support for Swarm through 2030 (abgerufen 2. Oktober 2026)
Kubernetes Releases (abgerufen 2. Oktober 2026)
Kubernetes Docs: Horizontal Pod Autoscaling (abgerufen 2. Oktober 2026)
Kompose (abgerufen 2. Oktober 2026)
Kompose User Guide (abgerufen 2. Oktober 2026)
Kompose Releases (GitHub) (abgerufen 2. Oktober 2026)
Hetzner Docs: Price Adjustment 15 June 2026 (abgerufen 2. Oktober 2026)
Hetzner: Neue Cloud-Pläne (CX23 Ausstattung) (abgerufen 2. Oktober 2026)
STACKIT SKU-Preiskatalog (PIM API) (abgerufen 2. Oktober 2026)
IONOS Cloud Managed Kubernetes (abgerufen 2. Oktober 2026)