Mit Kanonen auf Spatzen. Wann Sie keinen Kubernetes-Cluster brauchen
Kubernetes ist für viele Mittelstands-Projekte der falsche Hammer. Wir zeigen, wann ein Single-Server bei Hetzner reicht, wann Laravel Cloud, und wann erst K8s - mit Zahlen.
Ausgangslage
Warum K8s zur Default-Antwort geworden ist - und warum das falsch ist
Wir bekommen regelmäßig Ausschreibungen, in denen Kubernetes als gesetzte Anforderung steht. Nicht als geprüfte Lösung, sondern als Buzzword im Anforderungskatalog. Cloud-Native steht daneben, Kosten-Schätzung daneben fehlt. Wer sich auf einen K8s-Cluster einlässt, kauft sich nicht nur Infrastruktur, sondern eine ganze Betriebs-Disziplin ein.
Unsere ehrliche Beobachtung: In den meisten Mittelstands-Projekten reicht eine deutlich einfachere Architektur. Hetzner-Server, ein sauberes Deployment-Skript, ein Monitoring, fertig. Die K8s-Komplexität bringt erst ab einer bestimmten Last und Team-Größe wirklichen Nutzen.
Der Ops-Overhead, den niemand einplant
Ein produktionsreifer Kubernetes-Cluster bedeutet: Control-Plane-Updates, Ingress-Controller, Cert-Manager, externe Secret-Stores, Network-Policies, Pod-Security-Standards, Backup für etcd, Disaster-Recovery-Plan. Jede dieser Komponenten will gewartet werden. Wer das ohne dediziertes Plattform-Team aufsetzt, baut sich eine Wartungs-Schuld auf, die das Projekt überleben wird.
Entscheidungsmatrix
Drei Stufen, klar getrennt, mit echten Kosten
Wir denken Hosting in drei Stufen. Welche Stufe passt, hängt nicht am Wachstumswunsch, sondern an realer Last, realer Team-Größe und realen Verfügbarkeits-Anforderungen.
Stufe 1: Single-Server bei Hetzner - 20 bis 80 Euro im Monat
Ein Hetzner-Cloud-Server mit 4 vCPU, 8 GB RAM, 80 GB SSD kostet aktuell rund 16 Euro im Monat. Dazu Backup, Object-Storage und Snapshot-Strategie - wir landen bei 30 bis 80 Euro Gesamtkosten. Das trägt Tausende täglicher Sessions für eine ordentlich gebaute Laravel-Anwendung. Wir setzen das mit nginx, PHP-FPM, MariaDB oder PostgreSQL und Redis auf einer Box auf. Deployment per Git-Push, Zero-Downtime über symlinkbasierte Releases.
Wann das passt: ein Produkt, ein Team, EU-Datenhaltung gewünscht, normale Lastprofile. Welche Risiken bleiben: Single-Point-of-Failure. Bei Wartung Downtime einplanen, dafür sind die Kosten transparent und der Ops-Aufwand winzig.
Stufe 2: Laravel Cloud - 80 bis 400 Euro im Monat
Sobald Sie Auto-Scaling, Multi-Region, Built-in-Queues und managed Postgres wollen, ist Laravel Cloud die ehrlichste Wahl. Sie bekommen eine produktionsreife Plattform für Laravel-Apps, ohne ein Plattform-Team aufbauen zu müssen. Der Preis bewegt sich nutzungsabhängig zwischen 80 und ein paar hundert Euro im Monat - abhängig von Traffic, Compute und Datenbankgröße.
Wann das passt: mehrere Umgebungen, Auto-Scaling-Bedarf, Worker-Queues, kein eigenes DevOps-Team. Was Sie kaufen: weniger Kontrolle, dafür radikal weniger Betriebs-Verantwortung. Die Anwendung läuft auf bekannter PHP-Infrastruktur - kein Container-Lernkurs nötig.
Stufe 3: Kubernetes - ab 1.500 Euro im Monat aufwärts, plus Personal
Erst hier sehen wir Kubernetes als sinnvolle Wahl: mehrere parallele Services im selben Cluster, ein dediziertes Plattform-Team mit zwei bis drei FTE, Multi-Region-Anforderungen mit harten Recovery-Zielen. Reine Cluster-Kosten bei einem Managed-Anbieter starten bei 1.500 Euro im Monat - der eigentliche Hebel sind die Personalkosten. Wenn Sie K8s seriös fahren, haben Sie zwei bis drei Plattform-Engineers im Team.
Wann das passt: viele Teams, viele Services, harte Verfügbarkeit, ein Geschäftsmodell, das die Personalkosten trägt. Wenn Sie diese Bedingungen nicht erfüllen, bauen Sie eine Plattform für ein Problem, das Sie nicht haben.
Ehrliche Faustregel
Wer keine zwei FTE Plattform-Engineering im Plan hat, sollte keinen Kubernetes-Cluster bauen. Punkt. Alles andere ist Kostenverschiebung von Cloud-Rechnung in Personal-Schmerz - meistens beides gleichzeitig.
Stufenwechsel
Wann Sie von Stufe zu Stufe wechseln sollten
Der Wechsel ist nie eine Bauchsache. Es gibt klare, beobachtbare Trigger.
Von Single-Server zu Laravel Cloud
Indikatoren: erste Lastspitzen bringen den Server ins Schwitzen, Background-Jobs blockieren das Webfrontend, Sie brauchen eine separate Staging-Umgebung mit echten Daten, die Wartungsfenster werden geschäftlich teuer. Spätestens dann lohnt sich der Sprung auf eine managed Plattform - bevor Sie selbst zum Operator werden.
Von Laravel Cloud zu Kubernetes
Indikatoren: mehrere parallel betriebene Produkte, dedizierte Plattform-Verantwortung intern, polyglotte Stacks neben Laravel, harte Multi-Region-Anforderungen aus Compliance-Gründen. Wenn diese Punkte zusammenkommen und das Plattform-Team budgetiert ist, wird Kubernetes zur sinnvollen Wahl. Nicht früher.
Wann der Rückweg sinnvoll ist
Wir haben Projekte begleitet, in denen wir bestehende K8s-Setups zurückgebaut haben - auf Laravel Cloud, in einem Fall auf einen ordentlich gehärteten Single-Server. Der Befund war jedes Mal derselbe: zu viele YAML-Files für zu wenig Last. Skalierung ist auch eine Richtung - nach unten.
K8s im Pitch enthalten?
Wenn ein Angebot auf Ihrem Tisch Kubernetes voraussetzt: schicken Sie es uns, wir lesen es gegen und sagen Ihnen, ob die Komplexität gerechtfertigt ist.
Unser Default
Was wir bei neuen Projekten vorschlagen
Wir starten Projekte fast immer mit Hetzner EU als Default-Hosting. Wenn das Produkt wächst, Auto-Scaling sinnvoll wird oder ein Team in mehrere Squads zerfällt, wechseln wir auf Laravel Cloud. Beide Schritte sind reversibel und überschaubar. Kubernetes diskutieren wir erst, wenn die Last-Realität und das Plattform-Team es rechtfertigen.
Hetzner EU als Standard
Europäische Datenhaltung, transparente Preise, faire Bandbreite. Wer keine zwingenden Argumente für Hyperscaler hat, fährt damit besser als mit AWS-Stack-Tetris. Wir kennen die Schwächen - keine voll-managed Datenbanken auf jeder Größe - und arbeiten drumherum.
Migrationen vorbereiten, nicht vorwegnehmen
Wir bauen Anwendungen so, dass sie zwischen den Stufen migrieren können: 12-Factor-Konfiguration, Stateless-Sessions, externe Object-Stores für Uploads, klare DB-Migrationen. Damit ist der Sprung auf Laravel Cloud - oder weiter - eine Wochen-Arbeit, kein Großprojekt.
Artikel teilen
Welche Stufe passt zu Ihrem Projekt?
Schicken Sie uns die Eckdaten: Nutzer pro Tag, Datenmengen, Team-Größe, Verfügbarkeits-Anforderungen. Wir antworten mit einer ehrlichen Empfehlung und einer Kostenkurve über zwölf Monate.