Die 5 grössten Irrtümer beim Betrieb von TYPO3 auf Kubernetes
TYPO3 auf Kubernetes zu betreiben ist heute technisch unproblematisch. Was Projekte unnötig teuer und fragil macht, sind selten technische Grenzen — sondern Annahmen, die unverändert aus der klassischen Hosting-Welt übernommen wurden. Wir sehen in der Praxis immer wieder dieselben fünf. Dieser Beitrag benennt sie und zeigt, woran man erkennt, ob Kubernetes für ein TYPO3-Projekt überhaupt der richtige Weg ist.
Worum es geht
Die folgenden fünf Irrtümer begegnen uns regelmässig in TYPO3-auf-Kubernetes-Projekten — quer durch Branchen und Teamgrössen. Keiner davon ist ein TYPO3-Problem. Alle entstehen, weil eine in der Single-Server-Welt richtige Annahme unbesehen in eine verteilte Plattform mitwandert. Wer sie hinterfragt, betreibt seine Plattform einfacher, robuster und kosteneffizienter.
Irrtum 1: TYPO3 braucht zwingend ein Shared Filesystem
Das ist die häufigste Annahme — und der Reflex, sofort NFS, EFS oder CephFS einzuziehen. Tatsächlich braucht vor allem der Cache kein gemeinsames Dateisystem: Es genügt, die Cache-Metadaten zentral zu halten (Datenbank oder Redis), während die eigentlichen Cache-Dateien lokal in jedem Pod entstehen und bei Bedarf neu erzeugt werden. Persistente Assets wie fileadmin oder verarbeitete Bilder gehören ohnehin in Object Storage über FAL, nicht auf ein RWX-Volume. Damit fällt für die meisten Cluster die teuerste und fragilste Komponente weg. (Wir haben das im Detail im Schwester-Beitrag zum RWX-freien TYPO3-Cluster beschrieben.)
Irrtum 2: Kubernetes macht TYPO3 automatisch hochverfügbar
Mehrere Pods sind nicht dasselbe wie Hochverfügbarkeit. Solange zentrale Bausteine wie Datenbank, Redis, Storage oder DNS als Single Point of Failure bestehen, bleibt das Ausfallrisiko genau dort. Kubernetes verteilt zuverlässig die zustandsarmen Teile — aber es macht keine Komponente hochverfügbar, die nicht selbst dafür ausgelegt wurde. Hochverfügbarkeit ist eine Eigenschaft jeder einzelnen kritischen Komponente, nicht ein Nebenprodukt des Orchestrators.
Irrtum 3: Mehr Pods bedeuten automatisch mehr Performance
TYPO3-Anwendungen sind selten CPU-limitiert. Die realen Engpässe liegen meist woanders: in teuren Datenbankabfragen, in Solr, in externen APIs oder in einem langsamen Dateisystem. Mehr Pods skalieren die Anwendungsschicht — sie beheben aber keinen Engpass, der eine Schicht tiefer sitzt. Wer ohne Messung skaliert, vervielfacht im schlechtesten Fall nur die Last auf denselben überlasteten Datenbank-Server.
Irrtum 4: Containerisierung ist bereits Cloud-Native
Ein Docker-Container macht eine Anwendung noch nicht Cloud-Native. Cloud-Native heisst unter anderem: reproduzierbare Deployments, horizontale Skalierbarkeit, zustandsarme Services und automatisierte Wiederherstellung. Zwischen „läuft im Container“ und „ist Cloud-Native“ liegt genau die Arbeit, die später über Betriebsruhe entscheidet — etwa die Frage, welcher Zustand wohin gehört (siehe Irrtum 1). Ein Container ist die Verpackung, nicht die Architektur.
Irrtum 5: Kubernetes lohnt sich für jedes TYPO3-Projekt
Nicht jedes Projekt braucht Kubernetes. Für eine einzelne Website oder eine kleine Landschaft ist ein gut betriebener Server häufig die wirtschaftlichere und ruhigere Lösung. Kubernetes spielt seine Stärken erst aus, wenn mehrere Umgebungen, viele Deployments, echte Verfügbarkeitsanforderungen und ein DevOps-orientiertes Team zusammenkommen. Wer Kubernetes ohne diese Treiber einführt, kauft sich vor allem Komplexität ein, die niemand braucht.
Wann Kubernetes wirklich sinnvoll wird
Interessant wird Kubernetes, sobald Infrastruktur als Plattform verstanden wird — also als wiederverwendbare, standardisierte Grundlage für viele Projekte statt als Einzelfall pro Website. Dann entstehen die eigentlichen Vorteile: standardisierte, reproduzierbare Deployments, automatisierte Skalierung und eine höhere Betriebssicherheit, weil der immer gleiche Weg gegangen wird. Für grössere TYPO3-Landschaften ist das oft der Punkt, an dem sich der Aufwand klar auszahlt. Unsere Faustregel: Kubernetes lohnt sich, wenn die Plattform mehr als ein Projekt trägt.
Häufige Fragen
Braucht TYPO3 auf Kubernetes ein Shared Filesystem?+
Für den Cache in der Regel nicht — Metadaten zentral, Cache-Dateien lokal pro Pod. Persistente Assets (fileadmin, _processed_) gehören in Object Storage über FAL, nicht auf ein RWX-Volume.
Ist TYPO3 mit mehreren Pods automatisch hochverfügbar?+
Nein. Datenbank, Redis, Storage und DNS müssen einzeln hochverfügbar ausgelegt sein. Kubernetes verteilt die zustandsarmen Teile, ersetzt aber kein HA-Konzept für die zentralen Komponenten.
Lösen mehr Pods Performance-Probleme?+
Nur wenn der Engpass in der Anwendungsschicht liegt. Häufiger sitzen die Bremsen in Datenbankabfragen, Solr, externen APIs oder im Dateisystem — dort hilft Skalierung der Pods nicht.
Lohnt sich Kubernetes für ein einzelnes TYPO3-Projekt?+
Meist nicht. Ein gut betriebener Server ist für eine einzelne Website oft wirtschaftlicher. Kubernetes lohnt sich, wenn die Plattform mehrere Umgebungen, viele Deployments und echte Verfügbarkeitsanforderungen trägt.
Fazit
TYPO3 funktioniert hervorragend auf Kubernetes. Die meisten Schwierigkeiten entstehen nicht durch TYPO3, sondern durch Annahmen, die aus klassischen Hosting-Umgebungen übernommen und nie überprüft wurden. Wer diese Annahmen hinterfragt — beginnend bei der Frage, welcher Zustand wirklich geteilt werden muss — gestaltet seine Plattform einfacher, robuster und kosteneffizienter. Und wer ehrlich prüft, ob Kubernetes überhaupt der richtige Weg ist, trifft die wirtschaftlichere Entscheidung, egal wie sie ausfällt.
Wir sagen Ihnen ehrlich, ob Kubernetes Ihr TYPO3-Projekt voranbringt — oder nur teurer macht.
Standortbestimmung für TYPO3 auf Kubernetes: Wir prüfen Annahmen gegen Ihre tatsächliche Last, benennen die echten Engpässe (Datenbank, Solr, Storage) und bauen eine Plattform, die trägt — oder raten begründet vom Cluster ab, wenn ein Server die bessere Wahl ist.
Plattformbetrieb statt Beratung-on-paper: Wir analysieren, bauen und betreiben TYPO3-Plattformen entlang des tatsächlichen Bedarfs — nicht entlang des Trends.
