Kubernetes-Alternativen: Wann der Cluster Overkill ist

Kubernetes hat sich als Standard für Container-Orchestrierung durchgesetzt, und genau das ist das Problem: Der Cluster wird oft gewählt, weil er Standard ist, nicht weil die Anforderungen ihn verlangen. In vielen Unternehmen laufen am Ende fünf Services auf einer Plattform, die für fünfhundert gebaut wurde. Dieser Beitrag zieht eine ehrliche Bilanz: Was kostet Kubernetes im Betrieb wirklich, in welchen Situationen spielt es seine Stärken aus, und welche Alternativen liefern dasselbe Ergebnis mit einem Bruchteil des Aufwands.

Was ein Kubernetes-Cluster im Betrieb wirklich kostet

Die Einstiegshürde ist nicht die Installation. Ein Managed Cluster bei AWS, Azure oder GCP steht in einer halben Stunde. Die Kosten entstehen danach, und sie sind dauerhaft.

Kubernetes veröffentlicht drei Minor-Releases pro Jahr, jede Version wird rund 14 Monate unterstützt. Wer nicht regelmäßig aktualisiert, landet schnell auf einer Version ohne Patches, mit APIs, die beim nächsten Sprung wegbrechen. Upgrades sind damit keine Kür, sondern ein fester Posten im Betriebskalender, inklusive Tests der eigenen Workloads gegen deprecated APIs.

Dazu kommt die Sicherheitsarbeit. Die Defaults eines frischen Clusters sind nicht produktionsreif, denn Härtung bedeutet Arbeit an vielen Stellen: RBAC, Network Policies, Pod Security Standards und Image-Scanning kosten in einem realen Projekt schnell 15 Personentage, bis ein Cluster CIS-Level-1-konform ist. Diese Arbeit fällt unabhängig davon an, ob darauf drei oder dreihundert Services laufen.

Der größte Posten ist aber das Wissen im Team. Ingress-Controller, CNI, Operatoren, Helm-Charts, Observability-Stack: Wer das ernsthaft betreibt, braucht mindestens zwei Personen, die das System tief verstehen, sonst hängt die Produktionsumgebung an einer einzelnen Person. Die offizielle Dokumentation zu produktionsreifen Umgebungen liest sich aus gutem Grund wie ein eigenes Berufsbild. Für ein Team mit acht Entwicklern, das eigentlich Fachsoftware bauen will, ist das eine strukturelle Fehlallokation.

Wann Kubernetes die richtige Wahl ist

Die Gegenrechnung gehört dazu, denn es gibt Situationen, in denen Kubernetes durch nichts sinnvoll zu ersetzen ist.

Erstens bei echter Service-Vielfalt: Ab etwa 15 bis 20 Services mit unterschiedlichen Teams, Deployment-Zyklen und Skalierungsprofilen zahlt sich die einheitliche Plattform aus. Selbstheilung, deklarative Konfiguration und GitOps-Workflows reduzieren dann genau die Koordinationskosten, die sie in kleinen Setups erst erzeugen. Ob die eigene Architektur diese Vielfalt überhaupt braucht, ist die vorgelagerte Frage, die wir im Vergleich Microservices vs. Monolith behandelt haben.

Zweitens bei Lastprofilen mit starken Schwankungen, etwa im E-Commerce oder bei Event-getriebenen Systemen. Horizontal Pod Autoscaling und Cluster Autoscaler sind hier schwer zu schlagen.

Drittens bei On-Premises- oder Multi-Cloud-Pflichten. Wer aus regulatorischen Gründen im eigenen Rechenzentrum bleiben muss oder bewusst anbieterunabhängig fahren will, bekommt mit Kubernetes eine portable Abstraktionsschicht, die es so kein zweites Mal gibt.

Wer sich in diesen Profilen wiederfindet, sollte Kubernetes nutzen, dann aber managed (EKS, AKS, GKE) statt mit selbst betriebener Control Plane.

Drei Alternativen, die oft besser passen

Für alle anderen gibt es drei Wege, die in unseren Projekten regelmäßig die bessere Bilanz liefern.

Managed Container-Plattformen wie Google Cloud Run, AWS Fargate mit ECS oder Azure Container Apps nehmen das gesamte Cluster-Management ab. Das Team liefert ein Container-Image, die Plattform übernimmt Skalierung, Patching und Verfügbarkeit, abgerechnet wird nach Nutzung. Für APIs, Webanwendungen und Hintergrund-Jobs ist das in den meisten Fällen die rationalste Wahl. Der Preis ist eine moderate Anbieterbindung auf Deployment-Ebene, das Container-Image selbst bleibt portabel.

Die zweite Alternative klingt unspektakulär und ist gerade deshalb unterschätzt: eine oder zwei VMs mit Docker Compose. Für interne Anwendungen, B2B-Portale mit planbarer Last oder ein Produkt mit wenigen tausend Nutzern reicht das oft jahrelang:

services:
  app:
    image: registry.example.com/portal:1.8.2
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 10s
volumes:
  pgdata:

Mit einem Reverse Proxy davor, automatisierten Backups und einer CI-Pipeline, die per SSH deployt, ist das ein vollwertiger, wartungsarmer Produktionsbetrieb. Was dabei nicht fehlen darf, von Deployment-Automatisierung bis Monitoring, haben wir im pragmatischen DevOps-Einstieg für den Mittelstand beschrieben.

Der dritte Weg ist der ehrliche Mittelweg für alle, die Kubernetes-Konzepte wollen, aber keinen Konzern-Cluster: k3s als schlanke, zertifizierte Distribution auf zwei, drei Nodes. Die Betriebslast sinkt deutlich, die Manifeste bleiben kompatibel, und ein späterer Umzug auf einen Managed Cluster ist kein Rewrite.

Fünf Fragen vor der Cluster-Entscheidung

In Architektur-Reviews stellen wir vor jeder Orchestrierungs-Entscheidung dieselben fünf Fragen. Wie viele Services mit eigenständigem Lebenszyklus existieren wirklich, heute und in 18 Monaten? Wer im Team kann einen Cluster um 3 Uhr nachts debuggen, und was passiert, wenn diese Person kündigt? Schwankt die Last tatsächlich so stark, dass Autoscaling Geld spart, oder ist sie planbar? Gibt es harte On-Prem- oder Multi-Cloud-Anforderungen? Und schließlich: Würde das Budget für den Cluster-Betrieb, ehrlich gerechnet über drei Jahre, anderswo mehr Wirkung entfalten? Bei der letzten Frage lohnt der Blick auf die laufenden Ausgaben, denn ungenutzte Cluster-Kapazität ist einer der häufigsten Posten, die wir bei der Cloud-Kostenoptimierung finden.

Wer drei dieser fünf Fragen gegen den Cluster beantwortet, fährt mit einer Managed Plattform oder einer Compose-Umgebung fast sicher besser.

Fazit

Kubernetes ist ein hervorragendes Werkzeug für ein spezifisches Problem: viele Services, viele Teams, schwankende Last, Portabilitätspflichten. Wer dieses Problem nicht hat, kauft mit dem Cluster vor allem laufende Komplexität. Managed Container-Plattformen, eine solide Compose-Umgebung oder k3s liefern für den typischen Mittelstands-Workload dasselbe Ergebnis bei deutlich geringeren Betriebskosten. Die Architektur-Entscheidung sollte beim Workload anfangen, nicht beim Werkzeug.

EverBright IT unterstützt bei genau dieser Abwägung, von der Architektur-Review über den Plattform-Vergleich bis zur Migration in beide Richtungen. Mehr zu unserer Cloud-Beratung oder direkt Kontakt aufnehmen.

Häufige Fragen

Ist Kubernetes für kleine Teams sinnvoll?

Meist nicht. Unter etwa zehn Services und ohne dediziertes Plattform-Know-how erzeugt ein Cluster mehr Betriebsaufwand, als er einspart. Managed Container-Dienste wie Cloud Run oder Azure Container Apps liefern Skalierung und Verfügbarkeit ohne Cluster-Administration. Kubernetes lohnt sich, wenn Service-Anzahl, Teamgröße oder Compliance-Anforderungen die Plattform-Investition rechtfertigen.

Was sind die wichtigsten Alternativen zu Kubernetes?

Drei Optionen decken die meisten Fälle ab: Managed Container-Plattformen (Google Cloud Run, AWS Fargate/ECS, Azure Container Apps) für den Großteil der Web- und API-Workloads, Docker Compose auf einer VM für interne Anwendungen mit planbarer Last, und k3s als schlanke Kubernetes-Distribution, wenn Cluster-Konzepte gewünscht sind, aber keine Konzern-Infrastruktur.

Was kostet der Betrieb eines Kubernetes-Clusters?

Neben den Infrastrukturkosten fallen dauerhafte Personalkosten an: drei Minor-Upgrades pro Jahr, Security-Hardening (in der Praxis rund 15 Personentage bis CIS-Level-1-Konformität), Patching, Monitoring und Incident-Bereitschaft. Realistisch bindet ein produktiver Cluster mindestens eine halbe bis ganze Stelle an Plattform-Arbeit, unabhängig von der Anzahl der Workloads.

Wann lohnt sich der Umstieg von Docker Compose auf Kubernetes?

Wenn konkrete Grenzen erreicht werden: mehr als ein Dutzend Services mit eigenen Deployment-Zyklen, Lastspitzen, die manuelles Skalieren überfordern, oder Hochverfügbarkeitsanforderungen über mehrere Nodes. Der Wechsel gelingt am besten über einen Managed Cluster, da die Container-Images unverändert bleiben und nur die Deployment-Beschreibung migriert wird.