Kubernetes für kleine Projekte: sinnvoll oder nicht?

In kleinen Teams mit bis zu fünf Entwicklern kommt Kubernetes oft nicht aufgrund einer nüchternen Kalkulation ins Spiel, sondern wegen des Gefühls, dass „professionelle Teams das eben so machen“. In der Praxis ist ein Orchestrator ein eigenes Produkt: Er muss aktualisiert und überwacht, nachts repariert und neuen Teammitgliedern erklärt werden. Für eine einzelne API und statische Dateien hinter nginx lohnt sich das selten. Bei fünf Microservices und wöchentlichen Releases kann die Abwägung bereits anders ausfallen.

Was man tatsächlich einkauft

Kubernetes bietet eine einheitliche API für Deployments, Service Discovery, Health Checks, Rolling Updates und horizontale Skalierung. Man kauft damit kein „günstiges Hosting“, sondern:

eine Control Plane — verwaltet oder selbst betrieben;
ein Betriebsmodell — wer reagiert, wenn um 3 Uhr morgens ein CrashLoopBackOff auftritt;
zusätzliche Komponenten — Ingress, cert-manager, external-dns, Secrets und Storage Classes;
Observability — ohne Metriken und Alarme ist der Cluster praktisch blind (siehe Monitoring für Server und Kubernetes).

Fehlen diese Komponenten im Plan, wird aus dem „minimalen Cluster mit drei Nodes“ ein Risiko.

Wann Kubernetes überdimensioniert ist

Bleiben Sie bei einer VM, einer PaaS oder Docker Compose, wenn die meisten dieser Punkte zutreffen:

Es gibt nur ein oder zwei deploybare Artefakte, etwa einen Monolithen und einen Worker.
Releases erfolgen seltener als einmal pro Woche und es gibt keine strengen Zero-Downtime-Anforderungen.
Niemand ist ausdrücklich für den Bereitschaftsdienst der Plattform verantwortlich.
Das Budget liegt näher an einer MVP-Infrastruktur für 50 US-Dollar pro Monat als am Gehalt eines Platform Engineers auf mittlerem Erfahrungsniveau.

Compose auf einem einzelnen Server mit systemd, Reverse Proxy und automatisierten Backups ist langweilig, aber berechenbar. Viele B2B-SaaS-Produkte laufen auch bei ihren ersten paar Tausend Dollar MRR noch genau so.

Eine Managed PaaS wie Fly.io, Render oder ein entsprechendes Angebot eines Cloud-Anbieters übernimmt Rolling Deployments und TLS. Dafür verliert man etwas Flexibilität bei Sidecar-Mustern und fein abgestuften Netzwerkrichtlinien, gewinnt aber schon heute Monate an Entwicklungszeit.

Wann Kubernetes sinnvoll wird

Signale, die sich nur schwer künstlich erzeugen lassen:

Mehrere unabhängige Services werden von verschiedenen Personen bereitgestellt; Portkonflikte und manuelle Skripte gehören inzwischen zum Alltag.
Häufige Releases finden mehrmals täglich statt; Canary- oder Blue-Green-Deployments ohne Ausfallzeit werden benötigt.
Horizontale Skalierung soll anhand von Metriken wie CPU-Auslastung oder Queue-Tiefe erfolgen und nicht dadurch, dass jemand manuell eine zweite VM startet.
Einheitliche Richtlinien für Netzwerke, Pod-Sicherheit und Quotas sind inzwischen eine Sicherheits- oder Compliance-Anforderung.
Managed Kubernetes wird bereits bezahlt, und es ist geklärt, wer auf Alarme reagiert.

k3s und andere schlanke Distributionen senken die Einstiegshürde für Homelabs und Edge-Systeme. In der Produktion bleibt die Verantwortung ohne Runbook für „Cluster aktualisieren / etcd wiederherstellen“ jedoch dieselbe — lediglich der RAM-Verbrauch ist geringer.

Managed oder selbst betrieben: Kosten und Risiken

Bei Managed Kubernetes fallen feste Kosten für die Control Plane sowie die Worker Nodes an. Der Eigenbetrieb auf eigenen Servern kann bei der Hardware günstiger sein, dafür aber mehr Arbeitszeit kosten. Dieser Zielkonflikt wird auch im Vergleich zwischen Self-Hosting und Cloud im Jahr 2026 behandelt.

Ein typischer Fehler bei kleinen Projekten ist, nur die monatlichen Kosten der Nodes zu vergleichen. Hinzu kommen:

der Zeitaufwand für die Konfiguration von Ingress und DNS;
die Kosten eines fehlerhaften Deployments einschließlich Ausfallzeit;
CI-Werkzeuge, die Container-Images erstellen und in eine Registry übertragen;
die Aufbewahrung von Logs und Traces aus dem Cluster.

Kosten die Arbeitsstunden mehr als die Einsparung gegenüber einer PaaS, sollte Kubernetes warten.

Praktische Checkliste vor `kubectl`

Beantworten Sie diese Fragen schriftlich:

Frage	„Nein“ bedeutet: eher kein K8s
Wie viele Services werden in sechs Monaten in Produktion laufen?	1–2
Wer übernimmt den Bereitschaftsdienst für den Cluster?	„Bislang niemand“
Wird Autoscaling anhand von Queue-Tiefe oder RPS benötigt?	Nein
Gibt es eine Registry und eine CI-Pipeline für Images?	Nein
Ist das Team bereit, Kubernetes alle paar Monate zu aktualisieren?	Nein

Wenn die meisten Antworten gegen Kubernetes sprechen, beginnen Sie mit einer VM, Compose oder einer PaaS. Planen Sie einen Migrationspfad ein: Containerisieren Sie die Anwendung, lagern Sie die Konfiguration in Umgebungsvariablen aus und richten Sie Health Checks ein. Dann wird ein späterer Wechsel zu Kubernetes zu einer Migration statt zu einer Neuentwicklung.

Wenn die meisten Antworten dagegen zeigen, dass Kubernetes sinnvoll ist, aber kein eigener On-Call Engineer zur Verfügung steht, kann die Verantwortung für den Cluster an ein externes Team wie Ecooz übertragen werden. Zuständigkeiten, SLA, Eskalationswege und Zugriffsrechte sollten vorab klar festgelegt werden, damit der „externe Bereitschaftsdienst“ nicht nur eine mündliche Absprache bleibt.

Kompromisse, die funktionieren

Ein Managed Cluster mit getrennten Namespaces für Staging und Produktion ist günstiger als zwei Cluster, erfordert aber konsequentes RBAC.
Helm oder Kustomize vom ersten Tag an verhindert, dass die YAML-Konfigurationen der Umgebungen auseinanderlaufen.
GitOps mit Argo CD oder Flux ist bei vielen Deployments sinnvoll; für einen einzelnen Service reichen oft CI und kubectl set image.

Bauen Sie kein Platform-Team aus zwei Personen auf, um einen einzigen Pod zu betreiben.

Fazit

Ein kleines Projekt braucht Kubernetes nicht dann, wenn das Team einen modernen Stack möchte, sondern wenn manuelle Deployments und Skalierung mehr kosten als der Betrieb des Clusters. Bis dahin ist es einfacher und ehrlicher, eine minimale Infrastruktur beizubehalten, Monitoring hinzuzufügen und erst danach zu entscheiden, ob ein Orchestrator der nächste sinnvolle Schritt ist — und nicht nur der nächste Trend.

Quellen

Kubernetes Documentation — Production environment considerations. https://kubernetes.io/docs/setup/production-environment/
Kubernetes Documentation — Cluster administration overview. https://kubernetes.io/docs/concepts/cluster-administration/
CNCF — Cloud Native Definition. https://github.com/cncf/toc/blob/main/DEFINITION.md