Kubernetes vs. Docker Swarm: Technischer Vergleich fuer Container-Orchestrierung

TL;DR

• Docker Swarm ist in unter 5 Minuten einsatzbereit und nutzt die bekannte Docker-CLI -- ideal fuer kleine Teams mit einfachen Workloads.
• Kubernetes bietet ein wesentlich breiteres Feature-Set (Network Policies, RBAC, CRDs, HPA), erfordert aber deutlich mehr Einarbeitungszeit.
• Swarm hat seit Docker 23.0 keine nennenswerten Feature-Updates erhalten. Die Community und das Tooling schrumpfen.
• Fuer Workloads mit mehr als 10-15 Services, mehreren Umgebungen oder strengen Compliance-Anforderungen ist Kubernetes die nachhaltigere Wahl.
• Managed Kubernetes (AKS, EKS, GKE) eliminiert den groessten Nachteil von Kubernetes: die Komplexitaet der Control Plane.

Architektur im Direktvergleich

Beide Systeme verfolgen ein aehnliches Grundprinzip: Eine Control Plane verwaltet den Cluster-Zustand, Worker Nodes fuehren Container aus. Die Details unterscheiden sich aber erheblich.

Docker Swarm baut direkt auf der Docker Engine auf. Jeder Docker-Daemon kann per docker swarm init zum Manager werden. Manager nutzen den Raft-Konsens-Algorithmus fuer State-Replikation. Services werden als Tasks auf Worker Nodes verteilt.

Kubernetes nutzt eine dedizierte Control Plane mit API Server, etcd, Scheduler und Controller Manager. Worker Nodes laufen mit kubelet und kube-proxy. Die Architektur ist modularer, dafuer aber auch komplexer.

Deployment: Swarm Stack vs. Kubernetes Manifests

Schauen wir uns an, wie dasselbe Deployment in beiden Systemen aussieht: eine einfache Web-Applikation mit 3 Replicas, Resource Limits und einem Health Check.

Docker Swarm (docker-compose.yml fuer Stack Deploy)

version: "3.8"
services:
  webapp:
    image: nginx:1.25-alpine
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: "0.5"
          memory: 256M
        reservations:
          cpus: "0.25"
          memory: 128M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
      update_config:
        parallelism: 1
        delay: 10s
        order: start-first
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost"]
      interval: 30s
      timeout: 5s
      retries: 3
    ports:
      - "80:80"
    networks:
      - frontend

networks:
  frontend:
    driver: overlay

Deployment mit einem Befehl:

docker stack deploy -c docker-compose.yml myapp

Kubernetes (Deployment + Service)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: nginx
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 250m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 30
            timeoutSeconds: 5
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: webapp
spec:
  selector:
    app: webapp
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
    - host: webapp.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: webapp
                port:
                  number: 80

Der Unterschied faellt sofort auf: Kubernetes braucht mehr YAML, bietet dafuer aber getrennte Liveness- und Readiness-Probes, explizite Ingress-Konfiguration und eine feinere Rolling-Update-Strategie.

Skalierung und Auto-Scaling

Docker Swarm skaliert manuell:

docker service scale myapp_webapp=10

Kubernetes kann das auch manuell (kubectl scale), bietet aber zusaetzlich den Horizontal Pod Autoscaler:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

Der HPA reagiert auf Metriken und skaliert automatisch hoch und runter. Docker Swarm hat keine vergleichbare Funktion -- dafuer braeuchte man externe Tools wie Orbiter oder eigene Skripte.

Fuer detaillierte HPA-Konfiguration siehe den Artikel zu Kubernetes Resource Management.

Netzwerk und Security

Hier zeigt sich der groesste Unterschied. Docker Swarm bietet ein einfaches Overlay-Netzwerk mit integriertem Routing Mesh. Jeder Service ist ueber seinen Namen erreichbar, und Swarm verteilt eingehenden Traffic automatisch.

Kubernetes ist wesentlich granularer. Network Policies erlauben es, Traffic auf Pod-Ebene zu kontrollieren:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-netpol
spec:
  podSelector:
    matchLabels:
      app: webapp
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 80
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432

Diese Policy erlaubt nur eingehenden Traffic vom API-Gateway und ausgehenden Traffic zur Datenbank. In Docker Swarm gibt es kein Aequivalent -- alle Container im selben Overlay-Netzwerk koennen miteinander kommunizieren.

Fuer mehr Details zu Netzwerksicherheit in Kubernetes lohnt sich der Artikel zu Security Hardening.

Wann Swarm, wann Kubernetes?

Docker Swarm ist sinnvoll wenn:

• Das Team klein ist (1-3 Personen) und bereits Docker-Erfahrung hat
• Die Anwendung aus weniger als 10 Services besteht
• Kein Auto-Scaling benoetigt wird
• Einfache Deployments genuegen (kein Canary, kein Blue/Green)
• Kein Bedarf an feingranularer Netzwerk-Isolation besteht
• Schnelle Ergebnisse wichtiger sind als langfristige Flexibilitaet

Kubernetes ist sinnvoll wenn:

• Mehrere Teams an unterschiedlichen Services arbeiten
• Auto-Scaling und Self-Healing unverzichtbar sind
• Compliance-Anforderungen (DSGVO, BSI-Grundschutz) granulare Zugriffskontrolle erfordern
• Eine Multi-Cloud- oder Hybrid-Strategie geplant ist
• CI/CD mit GitOps (ArgoCD, Flux) betrieben werden soll
• Stateful Workloads (Datenbanken, Message Queues) orchestriert werden muessen

Fuer GitOps-Workflows mit Kubernetes bietet der Artikel zu ArgoCD und GitOps einen guten Einstieg.

Migration von Swarm zu Kubernetes

Wer mit Docker Swarm gestartet ist und an Grenzen stoesst, kann schrittweise migrieren. Die Docker-Images bleiben identisch. Was sich aendert, ist die Orchestrierungsschicht.

Ein typischer Migrationspfad:

1. Bestandsaufnahme: Alle docker-compose.yml / Stack-Dateien inventarisieren. Services, Volumes, Secrets und Netzwerke dokumentieren.

2. Kubernetes-Cluster aufsetzen: Fuer den Einstieg genuegt k3s auf einer einzelnen VM oder ein Managed Service. Fuer Produktionsumgebungen: Cluster Setup Production.

3. Kompose fuer initiale Konvertierung: Das Tool kompose konvertiert Docker-Compose-Dateien in Kubernetes-Manifests:

kompose convert -f docker-compose.yml -o k8s-manifests/

Die generierten Dateien sind ein Startpunkt, kein fertiges Ergebnis. Sie muessen manuell angepasst werden: Resource Limits, Probes, Ingress, Network Policies.

4. Parallelbetrieb: Beide Systeme parallel laufen lassen. Traffic schrittweise per DNS oder Load Balancer umleiten.

5. Swarm abschalten: Erst wenn alle Services stabil auf Kubernetes laufen und Monitoring/Alerting etabliert sind.

Fuer eine ausfuehrlichere Anleitung zur Cloud-Migration: Migration in die Cloud mit Kubernetes.

Ecosystem und Community

Dieser Punkt wird oft unterschaetzt. Kubernetes hat ein massives Ecosystem: Helm, Kustomize, ArgoCD, Prometheus, Grafana, Cert-Manager, External-DNS, Velero -- die Liste ist lang. Fuer fast jedes Problem gibt es eine etablierte Loesung.

Docker Swarm hat ein deutlich kleineres Ecosystem. Viele Tools, die frueher Swarm unterstuetzt haben (Portainer, Traefik), fokussieren sich zunehmend auf Kubernetes. Neue Features und Integrationen erscheinen fast ausschliesslich fuer Kubernetes.

Auf dem Arbeitsmarkt ist Kubernetes-Erfahrung stark nachgefragt. Docker-Swarm-Kenntnisse allein werden in Stellenausschreibungen kaum noch erwahnt. Das hat Auswirkungen auf die Rekrutierung und die langfristige Teamplanung.

Fazit

Docker Swarm bleibt ein solides Tool fuer einfache Use Cases. Wer eine Handvoll Container auf wenigen Nodes orchestrieren will und Docker bereits kennt, kommt damit schnell ans Ziel.

Fuer alles, was darueber hinausgeht -- Multi-Team-Setups, Compliance, Auto-Scaling, Stateful Workloads, GitOps -- fuehrt kein Weg an Kubernetes vorbei. Managed Kubernetes hat die Einstiegshuerde erheblich gesenkt. Die Frage ist nicht mehr, ob Kubernetes zu komplex ist, sondern ob die eigenen Anforderungen komplex genug sind, um den Einsatz zu rechtfertigen.

Sie stehen vor der Entscheidung und brauchen eine Einschaetzung fuer Ihren konkreten Fall? Wir helfen bei der Bewertung und Planung -- sprechen Sie uns an.