Docker Compose vs Kubernetes: Was wirklich anders wird

1. Grundphilosophie: ein Host vs. ein Cluster

Docker Compose und Kubernetes lösen dasselbe Grundproblem – mehrere Container gemeinsam verwalten – aber auf fundamental unterschiedlichen Ebenen. Docker Compose ist ein Single-Host-Orchestrator: alle definierten Services laufen auf demselben Rechner, teilen denselben Docker-Daemon und können direkt über Netzwerknamen kommunizieren. Das ist konzeptionell einfach, verständlich und ausreichend für eine Vielzahl realer Workloads. Kubernetes hingegen ist ein Cluster-Orchestrator: Pods verteilen sich über beliebig viele Nodes, der Control Plane plant Ressourcen und verwaltet den gewünschten Zustand, Netzwerk und Storage sind explizit abstrahiert.

Der entscheidende Unterschied liegt nicht in den Features, sondern im Betriebsmodell. Docker Compose läuft dort, wo der Docker-Daemon läuft – kein weiterer Infrastruktur-Stack notwendig. Kubernetes braucht mindestens einen Control Plane, einen oder mehrere Nodes, ein CNI-Plugin für Netzwerk, einen Storage-Provisioner und oft ein Ingress-Controller. Dieser Overhead ist in großen Teams mit dediziertem Plattform-Team gut investiert. In kleinen Teams mit wenigen Services ist er oft technische Schulden in der Infrastruktur.

2. Was Docker Compose wirklich gut kann

Docker Compose ist unschlagbar für lokale Entwicklungsumgebungen: ein einziger Befehl startet die gesamte Anwendungs-Infrastruktur mit Datenbank, Cache, Message Queue und allen Abhängigkeiten. Die Konfiguration ist eine einzige lesbare YAML-Datei – kein Operator-Framework, keine CRDs, keine RBAC-Policies. Neue Entwickler sind in Minuten produktiv. Volume-Mounts für Hot-Reload, einfache Port-Weiterleitungen und eine flache Netzwerkkonfiguration machen die Iterationszyklen kurz.

Auch für kleine Produktions-Deployments auf einem einzelnen Server ist Docker Compose eine vollwertige Lösung. Mit einem Reverse-Proxy wie Traefik oder Nginx, korrekten Restart-Policies und einem Monitoring-Sidecar läuft eine ganze Anwendung stabil und wartbar auf einem einzelnen V-Server. Kein Kubernetes-Cluster, kein Cloud-Provider-Lock-in, keine etcd-Backups. Wer eine Anwendung mit fünf Services und keiner Anforderung an horizontale Skalierung betreibt, verschwendet Zeit und Geld mit Kubernetes.

# Docker Compose — deploy a full stack on a single server
# Simple, readable, no cluster required

services:
  app:
    image: registry.mironsoft.de/shop:1.4.2
    networks: [web, internal]
    environment:
      APP_ENV: production
    restart: unless-stopped
    labels:
      # Traefik reverse proxy labels — auto-routing without extra config files
      - "traefik.enable=true"
      - "traefik.http.routers.shop.rule=Host(`shop.mironsoft.de`)"
      - "traefik.http.routers.shop.tls.certresolver=letsencrypt"

  traefik:
    image: traefik:v3
    networks: [web]
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - traefik_certs:/letsencrypt
    command:
      - "--providers.docker=true"
      - "--certificatesresolvers.letsencrypt.acme.email=ops@mironsoft.de"
      - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json"
    restart: unless-stopped

networks:
  web:
  internal:
    internal: true  # no outbound traffic from internal services

volumes:
  traefik_certs:

3. Kubernetes-Konzepte, die kein Compose-Äquivalent haben

Kubernetes führt Konzepte ein, für die es in Docker Compose keine direkte Entsprechung gibt. ReplicaSets stellen sicher, dass immer eine definierte Anzahl Pod-Instanzen läuft – stirbt ein Pod, startet Kubernetes automatisch einen neuen. HorizontalPodAutoscalers skalieren die Anzahl der Replikas basierend auf CPU-Auslastung oder benutzerdefinierten Metriken. RollingUpdates deployen neue Versionen eines Services, ohne Downtime, indem sie alte Pods schrittweise durch neue ersetzen. All das ist nativ in Kubernetes integriert – in Docker Compose erfordert es externe Tools oder manuelle Eingriffe.

Namespaces ermöglichen Multi-Tenant-Isolation auf Clusterebene: verschiedene Teams, Projekte oder Umgebungen teilen denselben Cluster, ohne sich gegenseitig zu beeinflussen. RBAC (Role-Based Access Control) steuert präzise, welcher Service Account welche Kubernetes-Objekte lesen oder verändern darf. NetworkPolicies definieren erlaubte Pod-zu-Pod-Kommunikation auf Netzwerkebene – Pods können standardmäßig voneinander isoliert werden. Diese Features sind für Single-Host-Docker Compose-Deployments schlicht nicht relevant – und das ist in Ordnung, solange man keinen Cluster betreibt.

4. Konzept-Mapping: Compose-Elemente in Kubernetes

Wer von Docker Compose zu Kubernetes wechselt, findet für die meisten Compose-Konzepte ein Kubernetes-Äquivalent – aber selten eine direkte 1:1-Übersetzung. Ein Compose-service wird in Kubernetes zu einem Deployment plus einem Service-Objekt. Das Deployment verwaltet die Pod-Template-Spezifikation und die gewünschte Anzahl Replikas. Das Service-Objekt stellt einen stabilen DNS-Namen und einen virtuellen Load Balancer vor den Pods bereit. Compose-volumes werden zu PersistentVolumeClaims, networks zu NetworkPolicies. Die Compose-environment-Liste entspricht einer Kombination aus Kubernetes ConfigMap und Secret.

Das Tool kompose convert kann eine Docker Compose-Datei automatisch in Kubernetes-Manifeste konvertieren. Das Ergebnis ist ein guter Ausgangspunkt, aber fast nie produktionsreif: Health-Checks werden als Liveness Probes übernommen, Volumes als PVCs angelegt, aber Ingress-Routing, Resource-Requests, Tolerations und Anti-Affinity-Regeln fehlen. Kompose ist nützlich, um das manuelle Tippen zu reduzieren – nicht als vollständige Migrations-Lösung.

# Kubernetes equivalent of a Docker Compose service
# One Compose service = Deployment + Service + (optionally) Ingress

---
# Deployment: manages pod replicas and rolling updates
apiVersion: apps/v1
kind: Deployment
metadata:
  name: shop-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: shop-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0        # zero-downtime deploy
  template:
    metadata:
      labels:
        app: shop-app
    spec:
      containers:
        - name: app
          image: registry.mironsoft.de/shop:1.4.2
          ports:
            - containerPort: 9000
          envFrom:
            - configMapRef:
                name: shop-config          # non-sensitive config
            - secretRef:
                name: shop-secrets         # credentials, API keys
          readinessProbe:
            httpGet:
              path: /health
              port: 9000
            initialDelaySeconds: 10
            periodSeconds: 5
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"

---
# Service: stable DNS name and load balancing across pods
apiVersion: v1
kind: Service
metadata:
  name: shop-app
  namespace: production
spec:
  selector:
    app: shop-app
  ports:
    - port: 80
      targetPort: 9000

5. Netzwerk: der größte Denkwechsel

Im Netzwerk liegt der größte konzeptionelle Unterschied zwischen Docker Compose und Kubernetes. In Docker Compose kommunizieren Services einfach über ihren Service-Namen: db ist unter db:3306 erreichbar, weil Docker ein internes DNS-System für das definierte Netzwerk bereitstellt. Service-Discovery ist automatisch, kein zusätzliches Objekt nötig. In Kubernetes läuft die Kommunikation über das Service-Objekt: ein Deployment hat keinen stabilen DNS-Namen, nur das zugehörige Service-Objekt macht den Pod unter shop-app.production.svc.cluster.local erreichbar.

Eingehender Traffic, den Docker Compose über Port-Mappings löst (ports: "443:443"), wird in Kubernetes durch Ingress-Ressourcen und einen Ingress-Controller abgewickelt. Das ist mächtiger – Routing auf URL-Pfad-Ebene, TLS-Terminierung, Header-basiertes Routing – aber auch erheblich komplexer. Ein Nginx Ingress Controller oder Traefik-Ingress muss im Cluster laufen. TLS-Zertifikate werden über cert-manager und Let's Encrypt oder über Kubernetes-native Certificate-Objekte verwaltet. Diese Infrastruktur aufzusetzen und zu betreiben ist eine Investition, die sich erst ab einer bestimmten Anzahl Services rentiert.

6. Storage: PersistentVolumes statt Host-Mounts

Storage ist einer der Bereiche, in dem Docker Compose und Kubernetes am stärksten voneinander abweichen. In Compose sind Volumes entweder benannte Docker-Volumes oder direkte Host-Pfad-Mounts. Beides ist einfach zu konfigurieren und verständlich – der Pfad auf dem Host, der in den Container gemountet wird, ist direkt sichtbar. In Kubernetes gibt es PersistentVolumes (PV), PersistentVolumeClaims (PVC) und StorageClasses. Ein PVC fordert Speicher einer bestimmten Größe und Klasse an – welches konkrete Volume darauf bereitgestellt wird, entscheidet der Storage-Provisioner automatisch.

Diese Abstraktion ist in Kubernetes-Clustern notwendig, weil Pods auf beliebigen Nodes laufen können und ein Host-Pfad-Mount nur auf dem spezifischen Node verfügbar wäre, auf dem der Pod zufällig gestartet wurde. Stateful-Workloads wie Datenbanken benötigen in Kubernetes StatefulSets statt Deployments – StatefulSets vergeben stabile Pod-Namen (db-0, db-1) und erstellen für jede Instanz einen eigenen PVC. Dieses Modell ist erheblich komplexer als Docker Compose Volumes, weil es für Multi-Node-Szenarien ausgelegt ist – in einem Single-Node-Deployment ist der Aufwand kaum gerechtfertigt.

7. Secrets und ConfigMaps: strukturierter als .env

Kubernetes bietet ein nativer Secret-Typ, der besser als die Docker Compose-.env-Dateien abschneidet – aber nur mit der richtigen Konfiguration. Kubernetes Secrets sind standardmäßig base64-kodiert, aber nicht verschlüsselt: jeder mit Cluster-Zugriff kann sie lesen. Echte Sicherheit kommt durch Encryption-at-Rest im API-Server und durch External Secret Stores wie HashiCorp Vault oder AWS Secrets Manager, die via Kubernetes External Secrets Operator eingebunden werden. ConfigMaps trennen nicht-sensible Konfigurationsdaten von Secrets und erlauben Updates, ohne Images neu zu bauen.

Der praktische Vorteil gegenüber Docker Compose-.env: Secrets und ConfigMaps können im laufenden Betrieb aktualisiert werden, und Pods nehmen die Änderungen auf – entweder durch Neustart oder, bei Volume-gemounteten ConfigMaps, automatisch nach einem kurzen Delay. Das ermöglicht Konfigurationsänderungen ohne neues Image-Build und ohne Service-Unterbrechung. Allerdings erfordert es RBAC-Konfiguration, um sicherzustellen, dass Pods nur auf die Secrets zugreifen können, die sie tatsächlich benötigen.

8. Direkter Feature-Vergleich

Die folgende Tabelle zeigt die wesentlichen Unterschiede zwischen Docker Compose und Kubernetes im direkten Vergleich – ohne Marketing, nur das, was in der Praxis relevant ist.

Der Vergleich zeigt: Docker Compose gewinnt bei Einfachheit und Betriebskosten. Kubernetes gewinnt bei Skalierung, Selbstheilung und Multi-Tenant-Isolation. Die Wahl ist keine Qualitätsfrage, sondern eine Frage der Anforderungen – und die meisten Anwendungen haben keine Anforderungen, die Kubernetes rechtfertigen.

9. Wann lohnt der Wechsel – und wann nicht

Ein Wechsel von Docker Compose zu Kubernetes lohnt sich, wenn mindestens eines dieser Szenarien zutrifft: die Anwendung muss horizontal auf mehrere Hosts skalieren, weil ein einzelner Server an seine Grenzen stößt; die Uptime-Anforderungen erfordern automatisches Failover bei Node-Ausfall; mehrere Teams deployen unabhängig in denselben Cluster und brauchen Namespace-Isolation; oder eine Plattform-Team-Kapazität ist vorhanden, die Kubernetes-Infrastruktur zu betreiben und zu warten. Ohne eines dieser Szenarien ist Kubernetes meist technische Schulden in der Infrastruktur.

Ein Wechsel lohnt sich nicht, wenn: das Team klein ist und keine Kubernetes-Expertise vorhanden ist; die Anwendung auf einem einzelnen Server problemlos läuft; kein dedizierter Platform-Engineer die Infrastruktur betreut; oder der Haupttreiber "alle nutzen Kubernetes" ist, ohne konkrete technische Anforderung dahinter. Docker Compose mit einem guten Reverse-Proxy, Monitoring und Backup-Strategie ist für eine Vielzahl von Produktions-Workloads eine vollwertige und wartungsärmere Alternative zu einem selbst betriebenen Kubernetes-Cluster.

10. Zusammenfassung

Docker Compose und Kubernetes sind keine konkurrierenden Technologien auf derselben Ebene – sie lösen Probleme unterschiedlicher Größenordnung. Docker Compose ist die richtige Wahl für lokale Entwicklung, Single-Host-Deployments und Teams ohne Kubernetes-Expertise. Kubernetes ist die richtige Wahl für Multi-Node-Cluster, automatische Skalierung und Hochverfügbarkeit mit Node-Failover. Der Migrationspfad existiert – Tools wie kompose helfen beim Start – aber die konzeptionellen Unterschiede bei Netzwerk, Storage und Deployment-Modell erfordern echtes Umlernen.

Die ehrliche Empfehlung für kleine Teams: Mit Docker Compose anfangen, sauber strukturieren und erst dann zu Kubernetes wechseln, wenn ein konkretes technisches Problem auftritt, das Compose nicht lösen kann. Kubernetes-Komplexität zu früh einzuführen bindet Engineering-Kapazität für Infrastruktur statt für das Produkt. Ein gut strukturiertes Docker Compose-Projekt, das verlässlich deployed und monitorbar ist, schlägt ein schlecht betriebenes Kubernetes-Cluster an jedem realen Maßstab.

11. FAQ: Docker Compose vs Kubernetes