Docker Compose ist für viele Projekte der natürliche Startpunkt. Eine Datei, ein Befehl, der ganze Stack läuft. Irgendwann taucht die Frage auf, ob Kubernetes der nächste Schritt ist. Die Antwort ist seltener ja, als die übliche Diskussion vermuten lässt. Hier ist, wie ich die Entscheidung einordne.

Was Compose richtig macht

Compose beschreibt einen Stack deklarativ und startet ihn auf einem einzelnen Host. Für lokale Entwicklung, kleine interne Dienste und überschaubare Deployments reicht das oft vollständig. Du bekommst Netzwerke, Volumes und Startreihenfolge ohne nennenswerten Lernaufwand. Eine typische Datei sieht so aus:

version: "3.9"
services:
  web:
    image: meine-app:1.4.2
    ports:
      - "8080:8080"
    environment:
      - DB_HOST=db
    depends_on:
      - db
  db:
    image: postgres:16
    volumes:
      - dbdata:/var/lib/postgresql/data
volumes:
  dbdata:

Das ist lesbar, versionierbar und in Sekunden gestartet. Solange ein Host genügt und kurze Ausfälle bei einem Deploy verkraftbar sind, gibt es keinen technischen Grund zu wechseln.

Wo Compose an die Grenze kommt

Die Grenze ist nicht die Anzahl der Container, sondern die Anforderung an Verfügbarkeit und Betrieb. Compose kennt keinen zweiten Knoten. Fällt der Host aus, ist der Dienst weg. Es gibt kein automatisches Neustarten auf einem anderen Server, kein Rolling Update ohne kurze Lücke und kein eingebautes horizontales Scaling über Maschinen hinweg. Wer das mit Compose nachbaut, schreibt am Ende ein eigenes kleines Orchestrierungssystem. Genau an dieser Stelle wird der Eigenbau teurer als das fertige Werkzeug.

Die ehrlichen Signale für den Wechsel

Kubernetes lohnt sich nicht, weil es modern ist, sondern wenn mehrere dieser Punkte gleichzeitig zutreffen: Du brauchst echte Hochverfügbarkeit über mehrere Knoten. Du deployst mehrmals täglich und willst dabei keine Downtime. Du musst je nach Last automatisch hoch und runter skalieren. Mehrere Teams teilen sich dieselbe Plattform und brauchen Isolation. Trifft nur einer dieser Punkte zu, gibt es meist eine einfachere Lösung als ein eigenes Cluster.

Wie der Übergang konkret aussieht

Aus dem Service oben wird in Kubernetes ein Deployment plus ein Service. Werkzeuge wie kompose erzeugen einen ersten Entwurf automatisch, aber den solltest du nie ungeprüft übernehmen. Das generierte Ergebnis ignoriert Health Checks, Ressourcenlimits und sinnvolle Labels. Von Hand sieht das Deployment etwa so aus:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: meine-app:1.4.2
          ports:
            - containerPort: 8080
          env:
            - name: DB_HOST
              value: db
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080

Der entscheidende Unterschied steckt nicht in der Syntax, sondern in den drei Replicas und der readinessProbe. Erst damit bekommst du das, wofür sich der Aufwand überhaupt lohnt: einen Dienst, der einen Knotenausfall übersteht und beim Deploy keine kaputten Pods in den Traffic nimmt. Wer das weglässt, hat Compose mit mehr YAML nachgebaut.

Was der Sprung kostet

Kubernetes verschiebt Komplexität, es entfernt sie nicht. Du betreibst ab jetzt ein Cluster, kümmerst dich um Ingress, Secrets, RBAC, Netzwerk-Policies und Updates der Steuerungsebene. Das ist ein eigener Wartungsposten, der nie wieder verschwindet. Ein Managed-Angebot bei einem Cloud-Anbieter nimmt dir den Betrieb der Steuerungsebene ab, aber die Workloads, die Sicherheit und die Pipelines bleiben deine Aufgabe. Diese laufenden Kosten gehören in die Entscheidung, nicht nur die einmalige Migration.

Meine Entscheidungsregel

Bleib bei Compose, solange ein Host reicht und du mit kurzen Deploy-Lücken leben kannst. Wechsle zu Kubernetes, wenn Ausfallsicherheit über mehrere Knoten und Deployments ohne Downtime echte Anforderungen sind und nicht nur Wünsche. Und plane den Wechsel so, dass Sicherheit von Anfang an mitläuft: gepinnte Images, getrennte Secrets, klare Rollen. Wie sich diese Pipeline- und Lieferketten-Themen sauber verzahnen, vertiefe ich regelmäßig auf digital-business.blog. Kubernetes ist ein gutes Werkzeug. Es ist nur selten das erste, das du brauchst.