Kubernetes ja oder nein? Entscheidungsrahmen für kleine Unternehmen

Kaum ein Thema spaltet IT-Teams in kleinen Unternehmen so zuverlässig wie Kubernetes. Auf der einen Seite: die Faszination für das mächtige Container-Orchestrierungssystem, das große Tech-Konzerne am Laufen hält. Auf der anderen Seite: Stundenlanges Debugging, komplexe YAML-Dateien und die leise Frage, ob das alles wirklich notwendig ist.

In meiner Arbeit mit KMUs erlebe ich regelmäßig beide Extreme – Unternehmen, die Kubernetes eingeführt haben und es bereuen, und solche, die es dringend bräuchten, aber noch auf Docker Compose "basteln". Dieser Artikel soll helfen, die richtige Entscheidung zu treffen.

Was Kubernetes wirklich ist (und was nicht)

Kubernetes ist ein Container-Orchestrierungssystem. Es verwaltet, wo und wie Container auf mehreren Maschinen laufen – inklusive automatischem Neustart, Skalierung, Lastverteilung und Rolling Updates. Es ist kein Deployment-Tool, kein CI/CD-System und kein einfacher Docker-Wrapper.

Der Kern des Missverständnisses: Viele Teams denken, sie brauchen Kubernetes, weil sie Container nutzen. Das stimmt nicht. Container und Kubernetes sind zwei verschiedene Dinge. Du kannst Container sehr effektiv ohne Kubernetes betreiben – und das solltest du auch, solange du die Grenzen einfacherer Lösungen nicht erreichst.

"Kubernetes löst Probleme, die du erst haben musst, bevor du es brauchst."

Die ehrliche Kosten-Nutzen-Rechnung

Bevor wir zu Entscheidungskriterien kommen, müssen wir über Kosten sprechen – nicht nur Geld, sondern auch Zeit und Komplexität.

Was Kubernetes kostet

Infrastrukturkosten: Ein produktionstaugliches Kubernetes-Cluster braucht mindestens 3 Control-Plane-Nodes und 2–3 Worker-Nodes. Bei einem Managed Service wie EKS (AWS), GKE (Google) oder AKS (Azure) kostet das schnell 300–600 € pro Monat – allein für die Infrastruktur.
Lernkurve: Realistische Einschätzung: 3–6 Monate, bis ein Entwickler produktiv mit Kubernetes arbeitet. Concepts wie Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, PersistentVolumes, RBAC – das ist viel auf einmal.
Operativer Overhead: Cluster-Updates, Zertifikatsverwaltung, Node-Scaling, Monitoring, Logging – all das kommt on top. Für ein kleines Team bedeutet das: Jemand muss "Kubernetes-Spezialist" werden.
Debugging-Komplexität: Wenn etwas schiefläuft, ist die Fehlersuche deutlich aufwändiger als bei einfacheren Setups. Ein einfacher Containerabsturz wird zu einer Kette von kubectl-Befehlen und Event-Logs.

Was Kubernetes bringt

Automatisches Self-Healing: Ausgefallene Container werden automatisch neu gestartet, auf gesunde Nodes verschoben.
Horizontale Skalierung: Bei Last können Pods automatisch skaliert werden – auch mit Custom-Metriken.
Zero-Downtime Deployments: Rolling Updates, Blue-Green und Canary Deployments out-of-the-box.
Deklarative Infrastruktur: Der gewünschte Zustand ist in YAML-Dateien beschrieben und wird automatisch durchgesetzt.
Multi-Tenant-Fähigkeit: Mehrere Teams, Projekte oder Kunden können auf einem Cluster isoliert laufen.

Der Entscheidungsrahmen: 5 Schlüsselfragen

Beantworte diese fünf Fragen ehrlich. Die Antworten zeigen dir, ob Kubernetes der richtige Schritt ist.

1. Wie viele unabhängige Services betreibst du?

Kubernetes entfaltet seinen Wert erst ab einer gewissen Komplexität. Als Faustregel gilt: Unter 5–8 Services bist du mit Docker Compose + einem Reverse Proxy sehr gut bedient. Ab 15–20 Services, die unabhängig skalieren und deployed werden müssen, beginnt Kubernetes echten Mehrwert zu liefern.

Wenn du eine monolithische Applikation oder 2–3 Microservices betreibst, ist Kubernetes Overengineering.

2. Was sind deine Verfügbarkeitsanforderungen?

Braucht deine Applikation 99.9% Uptime (ca. 8 Stunden Ausfallzeit pro Jahr) oder 99.99% (ca. 52 Minuten)? Für die meisten KMU-Anwendungen reicht 99.9% völlig aus – das erreichst du auch mit einem einzelnen Server und einem soliden Monitoring + Alerting-Setup.

Kubernetes bietet echten HA-Vorteil erst, wenn du mehrere Replicas auf mehreren Nodes betreibst. Das kostet aber auch entsprechend mehr.

3. Wie oft deployest du?

Teams, die mehrmals täglich deployen und dabei Zero-Downtime brauchen, profitieren stark von Kubernetes' Rolling-Update-Mechanismus. Wenn du einmal pro Woche oder seltener deployest, ist ein kurzes Wartungsfenster mit Docker Compose kein Problem.

Häufige Deployments + hohe Verfügbarkeitsanforderungen + mehrere Services = gutes Kubernetes-Signal.

4. Hast du das notwendige Know-how im Team?

Das ist die Frage, die am häufigsten unterschätzt wird. Kubernetes zu betreiben braucht nicht nur Wissen bei der Einführung, sondern dauerhaft. Wer im Team kümmert sich um Cluster-Updates, Sicherheitsupdates, Kapazitätsplanung und Incident Response?

Wenn die ehrliche Antwort "niemand so richtig" ist, entsteht schnell technische Schuld – und Ausfälle, die niemand debuggen kann.

5. Was kostet dich Komplexität?

Für ein 5-Personen-Startup ist der Kubernetes-Overhead relativ zum Team riesig. Für ein 50-Personen-Unternehmen mit dediziertem SRE-Team ist es vernünftig. Berechne den effektiven Stundensatz, den dein Team für Kubernetes-Operations aufwendet, und vergleiche ihn mit dem Wert, den die zusätzlichen Features bringen.

Wann du definitiv mit Kubernetes anfangen solltest

Diese Kombination von Faktoren spricht klar für Kubernetes:

Du betreibst 10+ Microservices, die unabhängig skalieren müssen
Du hast eine dedizierte DevOps- oder Platform-Person im Team
Mehrere Teams deployen unabhängig in unterschiedliche Namespaces
Du brauchst automatisches Horizontal Pod Autoscaling bei Traffic-Spitzen
Du verwendest GitOps-Workflows (ArgoCD, Flux) und willst deklarative Infrastruktur
Multi-Cloud oder Hybrid-Cloud ist ein Ziel in den nächsten 12 Monaten

Wann du Kubernetes besser meidest

Diese Signale sprechen klar dagegen:

Du betreibst weniger als 5 Services
Dein Team hat unter 5 Personen und kein dediziertes Ops-Know-how
Deine Applikation ist primär ein Monolith
Du deployest seltener als täglich
Deine Infrastrukturkosten sind bereits ein Thema
Der Entscheid kommt primär von "wir wollen es mal gelernt haben"

Die realen Alternativen

Kubernetes ist nicht die einzige Option zwischen "roher VM" und "vollständiges Orchestrierungssystem". Es gibt sinnvolle Zwischenlösungen:

Docker Compose + Traefik (für 1–10 Services)

Die einfachste und am meisten unterschätzte Lösung. Docker Compose definiert deine Services deklarativ, Traefik übernimmt Routing, SSL-Terminierung und sogar einfaches Load Balancing. Mit Watchtower kannst du automatische Container-Updates einrichten. Für kleine Teams ist das eine extrem wartbare und gut verstandene Lösung.

# docker-compose.yml (vereinfacht)
version: '3.8'
services:
  app:
    image: myapp:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.tls.certresolver=le"
  traefik:
    image: traefik:v3
    ports:
      - "80:80"
      - "443:443"

Dokku (Heroku-ähnlich, Self-Hosted)

Dokku gibt dir ein Heroku-ähnliches Interface auf einem eigenen Server. git push dokku main deployed deine App automatisch, inklusive SSL und Datenbanken. Perfekt für Teams, die schnell deployen wollen, ohne tief in Infrastruktur einzutauchen.

Nomad (HashiCorp)

HashiCorp Nomad ist ein Container-Orchestrator, der deutlich einfacher als Kubernetes ist. Er unterstützt nicht nur Container, sondern auch Raw Executables, JVM-Anwendungen und mehr. Die Lernkurve ist wesentlich flacher und der operative Overhead geringer. Für Teams, die "etwas mehr als Docker Compose, aber weniger als Kubernetes" suchen, ist Nomad eine ernsthafte Option.

Managed App Platforms

AWS App Runner, Google Cloud Run, Azure Container Apps oder Render.com nehmen dir die gesamte Infrastruktur ab. Du schickst einen Container-Image, sie kümmern sich um Skalierung, Updates und Verfügbarkeit. Die Kosten sind höher als Self-Hosting, aber der Overhead ist minimal. Für viele KMUs ist das die sinnvollste Option.

Wenn du dich für Kubernetes entscheidest: Einstiegsempfehlungen

Entscheidest du dich nach diesem Rahmen dennoch für Kubernetes, hier die wichtigsten Empfehlungen für den Start:

Managed Kubernetes nutzen: Kein eigenes Cluster aufbauen. EKS, GKE oder AKS nehmen dir die Control-Plane-Verwaltung ab. Das allein spart enorm viel Aufwand.
Klein starten: Beginne mit 2–3 Services, lerne die Konzepte, bevor du alle Workloads migrierst.
Helm von Anfang an: Kubernetes-Manifeste direkt pflegen ist schmerzhaft. Helm-Charts strukturieren deine Deployments und machen Upgrades einfacher.
Monitoring von Tag 1: Prometheus + Grafana (oder eine Managed-Lösung) sollte vor dem ersten Produktions-Workload installiert sein.
Namespace-Strategie festlegen: Zumindest production, staging und dev Namespaces trennen – mit entsprechenden RBAC-Regeln.
GitOps einführen: ArgoCD oder Flux machen Deployments nachvollziehbar, reproduzierbar und sicher. Der Mehraufwand beim Setup zahlt sich schnell aus.

Fazit: Die richtige Frage stellen

Die Frage "Sollen wir Kubernetes einführen?" ist oft die falsche. Die richtige Frage lautet: "Welche konkreten Probleme haben wir, und ist Kubernetes die einfachste Lösung dafür?"

Kubernetes ist ein fantastisches Werkzeug für die Probleme, die es löst. Aber es ist kein Default für "wir nutzen Container". Für die meisten kleinen Unternehmen, die ich berate, ist die Empfehlung: Fangt mit Docker Compose und einem Managed Deployment-Service an. Wenn ihr gegen die Grenzen stoßt – und das werden manche – dann ist Kubernetes der nächste Schritt.

Wer Kubernetes hingegen einführt, bevor die Probleme aufgetaucht sind, zahlt einen hohen Preis in Komplexität und Betriebsaufwand – für Features, die er noch nicht braucht.

Hast du konkrete Fragen zu deinem Stack? Ich bin Emre Hayta, IT-Freelancer aus Linz – vereinbare gerne ein kostenloses Erstgespräch.