Kubernetes gilt in vielen E-Commerce-Projekten inzwischen als Standardantwort auf jede Skalierungsfrage. Das ist verständlich und in etwa der Hälfte der Fälle falsch. Kubernetes ist ein hervorragendes Werkzeug für bestimmte Betriebsmodelle. Es ist aber kein Performance-Booster, kein Ersatz für sauberes Caching und keine Lösung für einen Shop, der an einer überlasteten Datenbank hängt.
Dieser Artikel ordnet ehrlich ein: Wann ergibt Kubernetes für einen Online-Shop wirtschaftlich und technisch Sinn und wann fahren Sie mit einem klassischen Managed Cluster oder Managed Server besser?
Inhaltsverzeichnis
- Was Kubernetes im Shop-Kontext tatsächlich leistet
- Wann sich Kubernetes für einen Online-Shop lohnt
- Wann sich Kubernetes nicht lohnt
- Die ehrliche Kostenrechnung
- Der Mittelweg, der oft übersehen wird
- Wenn Sie sich für Kubernetes entscheiden: schrittweise vorgehen
- Kubernetes ONE: Plattformbetrieb abgeben, Kontrolle behalten
Was Kubernetes im Shop-Kontext tatsächlich leistet
Kubernetes ist eine Orchestrierungsplattform. Sie verteilt containerisierte Workloads auf mehrere Nodes, startet ausgefallene Container neu, verschiebt Last, rollt neue Versionen aus und nimmt sie bei Fehlern zurück. Konkret bekommen Sie damit:
- Horizontale Skalierung einzelner Komponenten statt des gesamten Systems
- Deklarative Deployments, versioniert im Git-Repository
- Rolling Updates und Rollbacks ohne Wartungsfenster
- Self-Healing bei Container- oder Node-Ausfällen
- Saubere Trennung von Staging-, Test- und Produktionsumgebungen
- Einheitliche Umgebung für mehrere Projekte oder Mandanten
Was Kubernetes nicht leistet: Es macht Ihren Shop nicht schneller. Ein Shopware-Storefront, der 900 Millisekunden für den ersten Byte braucht, braucht sie im Cluster genauso. Kubernetes verändert, wie Sie Anwendungen betreiben und ausrollen nicht, wie schnell der Code läuft.
Wann sich Kubernetes für einen Online-Shop lohnt
Kubernetes zahlt sich aus, wenn mehrere der folgenden Punkte zutreffen. Ein einzelnes Kriterium reicht selten.
- Hohe Deployment-Frequenz: mehrmals pro Woche oder täglich. Rolling Updates und Rollbacks sparen dann echte Stunden. Bei vier Releases im Jahr rechnet sich der Aufwand nicht.
- Verteilte Architektur: Headless-Frontend, PIM/ERP-Middleware, Suchdienst, Import-Worker, eigene APIs. Ein klassischer Shopware- oder OXID-Monolith profitiert deutlich weniger.
- Stark schwankende Last: Peaks um Faktor fünf bis zehn durch Black Friday, TV-Werbung oder Newsletter. Bei gleichmäßigem Traffic zahlen Sie Komplexität ohne Gegenwert.
- Viele Umgebungen oder Mandanten: zweistellige Zahl an Shops, Staging-Systemen oder Kundenprojekten. Standardisierung per Template amortisiert den Einarbeitungsaufwand am schnellsten.
- Container-Kompetenz im Team: zustandslose Container, Konfiguration über Environment-Variablen, externalisierte Sessions, Health-Checks, Logs auf stdout. Fehlt das, ist die Containerisierung das eigentliche Projekt nicht das Cluster.
- Harte Verfügbarkeitsanforderungen: Wenn 30 Minuten Ausfall fünfstellige Umsatzverluste bedeuten, lohnen Self-Healing, Multi-Node-Verteilung und automatisiertes Failover.
Wann sich Kubernetes nicht lohnt
Genauso wichtig ist die Gegenprobe. In diesen Situationen raten wir in der Beratung regelmäßig ab:
- Ein einzelner Shop mit stabilem Traffic: Ein gut dimensionierter Managed Server oder ein klassisches Cluster ist günstiger, einfacher und für Ihr Team wartbar.
- Kleines Team ohne DevOps-Kapazität: Kubernetes verlagert Komplexität, es beseitigt sie nicht. Ohne Betriebsverantwortung im Team oder beim Provider entsteht ein System, das im Ernstfall niemand versteht.
- Der Shop ist ein klassischer Monolith: Wenn alles in einem PHP-Prozess läuft und die Datenbank der Flaschenhals ist, skaliert Kubernetes nur die Fassade. Die Datenbank bleibt Ihr Limit.
- Sie erhoffen sich bessere Ladezeiten: Ladezeiten verbessern Sie durch Caching, Datenbank-Optimierung, ein CDN, sauberes Asset-Handling und schnelleren Code nicht durch Orchestrierung.
- Der Auslöser ist ein einzelner Ausfall: Ein Vorfall rechtfertigt selten einen Architekturwechsel. Oft ist Monitoring, Redundanz auf Datenbankebene oder ein Failover-Setup die passendere Antwort.
- Das Budget ist eng kalkuliert: Nicht wegen der Node-Kosten, sondern wegen des Betriebsaufwands. Der eigentliche Preis von Kubernetes sind Personentage.
Die ehrliche Kostenrechnung
Der häufigste Fehler in der Entscheidungsfindung: Es werden Serverpreise verglichen. Der relevante Kostenblock liegt woanders.
Beim Eigenbetrieb kommen dauerhaft dazu:
- Cluster-Updates und Kubernetes-Versionssprünge, typischerweise mehrmals pro Jahr
- Betrieb von Ingress, Cert-Management, Storage-Klassen, Netzwerk-Layer
- Monitoring, Logging und Alerting-Stack inklusive Pflege
- Backup- und Restore-Konzepte für persistente Daten
- Security-Patches, RBAC, Netzwerk-Policies
- Rufbereitschaft und Know-how-Vorhaltung im Team
Rechnen Sie realistisch mit einem substanziellen Anteil einer Vollzeitstelle, sobald das Cluster produktiv Umsatz trägt. Diese Position taucht in keinem Preisvergleich auf, entscheidet aber über die Wirtschaftlichkeit.
Genau hier liegt der Unterschied zwischen selbst betriebenem und Managed Kubernetes: Sie behalten die Hoheit über Workloads, Deployments und Konfiguration die Plattform darunter betreibt Ihr Provider.
Der Mittelweg, der oft übersehen wird
Zwischen "ein Server" und "Kubernetes" liegt ein breites Feld, das viele Projekte besser abdeckt:
- Managed Cluster: Mehrere dedizierte Nodes mit Load Balancer, redundanter Datenbank und getrenntem Storage. Deckt Ausfallsicherheit und Lastverteilung ab, ohne Container-Orchestrierung zu erfordern.
- Vertikale Skalierung plus Caching-Layer: Für viele Shopware- und OXID-Shops ist ein größerer Server mit Varnish, Redis und CDN die schnellste und günstigste Verbesserung.
- Ausgelagerte Einzelkomponenten: Suche, Bildverarbeitung oder Importprozesse lassen sich isoliert skalieren, ohne den gesamten Shop umzubauen.
Wir empfehlen regelmäßig zuerst diese Optionen zu prüfen. Kubernetes ist dann der nächste Schritt, wenn die Grenze dieser Setups tatsächlich erreicht ist nicht vorher.
Wenn Sie sich für Kubernetes entscheiden: schrittweise vorgehen
Ein Big-Bang-Umzug des Produktivshops ist der häufigste Grund für gescheiterte Projekte. Bewährt hat sich diese Reihenfolge:
- Anwendung containerisieren und lokal sowie in CI stabil zum Laufen bringen
- Staging-Umgebung im Cluster aufbauen und dort Deployment-Prozesse einüben
- Unkritische Workloads zuerst migrieren, etwa Cronjobs, Importer, Worker
- Datenbank und persistente Dienste bewusst entscheiden – nicht reflexhaft ins Cluster verschieben
- Monitoring, Alerting und Backup-Restore vor dem Go-live testen, nicht danach
- Storefront zuletzt umziehen, mit definiertem Rollback-Pfad
Kubernetes ONE: Plattformbetrieb abgeben, Kontrolle behalten
Wenn die Analyse für Kubernetes spricht, Ihr Team aber den Plattformbetrieb nicht dauerhaft tragen will, ist Managed Kubernetes das passende Modell. Mit Kubernetes ONE legen Sie Cluster über ein zentrales Dashboard selbst an, konfigurieren, skalieren und aktualisieren sie ohne Terminal und ohne Wartezeit auf ein DevOps-Ticket.
Die Aufteilung ist klar:
- Wir betreiben die Plattforminfrastruktur: Server, Netzwerk, Updates, Monitoring, Betrieb in ISO-27001-zertifizierten Rechenzentren in Deutschland
- Sie behalten Ihre Cluster, Deployments und Workloads vollständig in der Hand
- Persönlicher Ansprechpartner statt anonymem Ticketsystem
- Planbare, nutzungsbasierte Kosten – Einstieg ab 79 Euro im Monat
Und wenn die Analyse gegen Kubernetes spricht, sagen wir Ihnen das auch. Ein überdimensioniertes Setup hilft niemandem am wenigsten Ihrem Shop. Fragen Sie jetzt Ihre Beratung an.
