Docker Swarm oder Kubernetes?

Wenn du mit Docker arbeitest, kennst du Kubernetes wahrscheinlich schon. Docker Engine bringt aber auch einen eigenen Cluster-Modus mit: Swarm. Beide verteilen Container auf mehrere Rechner. Wie viel Arbeit du mit dem Betrieb hast, unterscheidet sich deutlich.

Was macht Kubernetes?

Kubernetes startet Apps in Pods. Controller prüfen laufend, ob der Cluster so aussieht, wie du ihn konfiguriert hast. Ein Deployment hält zum Beispiel die gewünschte Zahl an Replikaten, ersetzt ausgefallene Pods und rollt neue Versionen aus.

Die Grafik stammt aus der Doku zur Kubernetes-Cluster-Architektur.

Ein großer Vorteil ist die Auswahl an Tools. Managed Cluster, Operatoren, Policies und Monitoring-Integrationen nehmen dir Arbeit ab, für die du sonst eigene Lösungen bauen müsstest. Das kann sich lohnen, wenn mehrere Teams dieselbe Plattform nutzen oder du spezielle Anforderungen hast.

Auch mit einer Managed Control Plane bleibt Arbeit bei dir. Dein Team kümmert sich um die Workload-Config, Ressourcen, Zugriffsrechte und Updates. Ob deine Apps unter Last funktionieren, musst du ebenfalls prüfen.

Was macht Docker Swarm?

Swarm steckt schon in Docker Engine. Manager-Nodes verwalten den Cluster und verteilen die Tasks eines Services auf die Nodes. Services und die Zahl ihrer Replikate legst du über die Docker-CLI fest.

Die Grafik stammt aus der Doku zu Docker-Swarm-Nodes.

Das Setup ist kleiner, und vieles kennst du bereits von Docker. Swarm ersetzt ausgefallene Tasks, rollt Updates schrittweise aus und verteilt Anfragen auf die Replikate eines Services. Eine Kubernetes-Control-Plane brauchst du dafür nicht.

Dafür gibt es weniger fertige Integrationen. Braucht dein Team Kubernetes-Operatoren oder bestimmte Kubernetes-Policies, ersetzt Swarm sie nicht einfach. Swarm ist weiterhin Teil der Docker-Engine-Doku. Prüf die Funktionen, die du brauchst, statt die Entscheidung nur daran festzumachen, welches Tool öfter erwähnt wird.

Wo liegen die Unterschiede?

• Setup: Swarm ist in Docker Engine enthalten. Für Kubernetes brauchst du eine eigene Cluster-Plattform oder einen Managed Cluster.
• Skalierung: Bei beiden gibst du die Zahl der Replikate vor. Kubernetes hat Autoscaling-Controller, die du passend konfigurieren musst. Swarm braucht dafür zusätzliche Tools.
• Netzwerk: Swarm bietet Service Discovery und ein Ingress-Routing-Mesh. Kubernetes nutzt Services, ein Cluster-Netzwerk und zusätzliche Einstellungen für externe Zugriffe.
• Erweiterungen: Für Kubernetes gibt es viele Operatoren und Controller. Bei Swarm ist die Auswahl kleiner.
• Wartung: Swarm hat weniger Konzepte, aber du musst den Cluster trotzdem warten. Kubernetes bietet mehr Optionen und verlangt entsprechend mehr Entscheidungen beim Betrieb.

Beide verteilen Anfragen. Kubernetes-Services leiten Traffic an Endpunkte weiter. Für einen extern erreichbaren Service vom Typ LoadBalancer muss deine Umgebung die passende Implementierung liefern. Wie das zusammenspielt, erklärt die Kubernetes-Dokumentation zu Services.

Das Routing-Mesh von Swarm nimmt Anfragen am freigegebenen Service-Port eines Nodes an. Es leitet sie dann an einen Task weiter. Wie Traffic von außen deine Nodes erreicht, musst du trotzdem planen.

Bei Datenbanken reicht es nicht, den Container auf einem anderen Node neu zu starten. Du brauchst auch einen Plan für Speicher, Backups, Restore und Datenreplikation. Das gilt für beide Systeme.

Was würde ich wählen?

Für ein kleines Team mit Docker-Erfahrung würde ich mir Swarm anschauen, wenn mehrere Hosts nötig sind. Reichen die Funktionen aus, bedeuten weniger Komponenten oft auch weniger Arbeit.

Kubernetes würde ich nehmen, wenn wir seine Integrationen brauchen oder es im Team schon sicher betreiben. Für Anforderungen, die vielleicht irgendwann kommen, würde ich mir den zusätzlichen Aufwand sparen.

Bei wenigen Apps würde ich zuerst prüfen, ob wir überhaupt einen eigenen Cluster brauchen. Oft reicht ein einzelner Server oder ein Managed Container-Service. Auch deshalb haben wir Sliplane gebaut: Du deployest deinen Container, und wir kümmern uns um den Cluster-Betrieb.