TYPO3 auf Kubernetes ohne RWX-Volume — warum wir das Shared Filesystem entfernt haben
Viele TYPO3-Cluster laufen auf einem Shared Filesystem — NFS, AWS EFS, CephFS oder Azure Files. Das funktioniert, kostet aber Latenz, Geld und eine zusätzliche Ausfallstelle, die jeder Pod teilt. Wir haben für unsere betreuten TYPO3-Plattformen die unbequeme Frage gestellt, ob ein gemeinsames Dateisystem für den Cache überhaupt nötig ist — und sie für diesen Fall mit Nein beantwortet. Dieser Beitrag zeigt, warum wir Cache-Metadaten zentral halten, die Cache-Dateien aber lokal in jedem Pod erzeugen lassen, und welche Grenze dieser Ansatz hat.
TL;DR
Viele TYPO3-Cluster werden mit einem Shared Filesystem betrieben — meist, weil es in klassischen Hosting-Umgebungen so üblich war. Für den TYPO3-Cache ist das in den meisten Fällen nicht nötig: Der Cache braucht keine geteilte Datei, sondern ein clusterweit einheitliches Bild davon, ob ein Eintrag gültig ist. Trennt man beides — Metadaten zentral, Cache-Dateien lokal pro Pod — entfällt das RWX-Volume für diesen Anwendungsfall: weniger Infrastruktur, schnellere Pods, eine Ausfallstelle weniger. Wichtig zur Abgrenzung: Das betrifft den Cache, nicht persistente Nutzerdaten wie fileadmin oder verarbeitete Bilder — die gehören in Object Storage über FAL, nicht auf ein RWX-Volume.
Der klassische TYPO3-Betrieb
Historisch lief TYPO3 auf einem einzelnen Server, und ein lokales Dateisystem war selbstverständlich: Cache-Dateien, Temp-Dateien und der PHP-Code lagen alle auf derselben Platte. Es gab genau einen Server und damit genau eine Sicht auf das Dateisystem — Synchronisationsfragen stellten sich nie. Diese Selbstverständlichkeit ist der Grund, warum sie später so selten hinterfragt wird: Sie war nie eine Entscheidung, sondern eine Gegebenheit.
Der erste Kubernetes-Cluster
Sobald TYPO3 auf mehrere Pods verteilt wird, taucht eine neue Frage auf: Was passiert mit Dateien, die ein Pod zur Laufzeit erzeugt? Die übliche Antwort lautet reflexhaft „Wir brauchen ein Shared Filesystem“, und es wird NFS, AWS EFS, Azure Files, CephFS oder GlusterFS eingeführt. Auf den ersten Blick funktioniert das. Auf den zweiten entsteht eine neue, dauerhafte Abhängigkeit — eingeführt, um ein Problem zu lösen, das man vorher nicht präzise benannt hat.
Das eigentliche Problem
Ein Shared Filesystem löst die Synchronisationsfrage, schafft aber vier neue Themen, die im Betrieb dauerhaft Aufmerksamkeit kosten.
Höhere Latenz
Ein lokaler Dateizugriff dauert Mikrosekunden. Ein Netzwerk-Dateisystem braucht zusätzliche Netzwerk- und Storage-Operationen für dieselbe Datei. Bei einem cachelastigen CMS, das viele kleine Dateien liest und schreibt, summiert sich das spürbar.
Komplexere Infrastruktur
Mit dem Shared Filesystem kommt ein weiterer kritischer Baustein in den Stack — inklusive Monitoring, Backup, Security-Härtung und Hochverfügbarkeit. Das ist kein einmaliger Aufwand, sondern eine Komponente, die ab sofort mitbetrieben werden will.
Single Point of Failure
Fällt das gemeinsame Dateisystem aus, sind in der Regel alle TYPO3-Pods gleichzeitig betroffen. Die Architektur, die für Ausfallsicherheit gedacht war, bekommt damit eine zentrale Stelle, an der genau diese Sicherheit kippt.
Höhere Kosten
Gerade bei Cloud-Providern sind RWX-fähige Volumes spürbar teurer als lokale Block- oder Ephemeral-Storage-Klassen — ein laufender Posten, der mit jeder Umgebung mitwächst.
Braucht TYPO3 wirklich ein Shared Filesystem?
Diese Frage haben wir uns für unsere betreuten Plattformen konkret gestellt. Die überraschende Antwort: für viele Cache-Anwendungsfälle nicht. Der Denkfehler steckt in der Formulierung der Anforderung. Sie lautet meist implizit „Alle Pods müssen dieselbe Cache-Datei besitzen“ — gemeint ist aber eigentlich „Alle Pods müssen wissen, ob ein Cache-Eintrag gültig ist“. Das sind zwei verschiedene Probleme, und nur das zweite verlangt zwingend einen geteilten Zustand.
Eine andere Architektur: Metadaten zentral, Payloads lokal
Statt die Cache-Dateien zentral zu speichern, trennen wir zwei Dinge, die historisch im selben Filesystem lagen.
Cache-Metadaten
Schlüssel, Tags, Ablaufzeiten und Invalidierungsinformationen. Dieser Zustand muss clusterweit identisch sein, ist aber klein und strukturiert — also genau das, was ein zentraler Store (etwa eine Datenbank oder Redis) gut und schnell verwaltet.
Cache-Payloads
Die eigentlichen Cache-Dateien. Sie können lokal in jedem Pod liegen. Fehlt eine Datei in einem Pod, wird sie dort schlicht neu erzeugt. Der geteilte Zustand bleibt damit dort, wo er hingehört — in den Metadaten — und die grossen, häufigen Lese-/Schreibzugriffe bleiben lokal und schnell.
Deterministische Re-Materialisierung
Der entscheidende Gedanke dahinter: Eine Cache-Datei ist kein Geschäftsobjekt, sondern ein reproduzierbares Zwischenergebnis. Startet ein Pod neu oder fehlt ihm eine Datei, kann er sie aus den Quelldaten und den zentralen Metadaten erneut erzeugen. Der Verlust einer Cache-Datei ist deshalb kein Datenverlust, sondern bestenfalls eine einmalige Neuberechnung. Genau diese Eigenschaft — Verlustfreiheit durch Reproduzierbarkeit — erlaubt es, Pods als austauschbar zu behandeln, statt sie an ein gemeinsames Volume zu binden.
Was das im Betrieb gebracht hat
Für die betreuten TYPO3-Plattformen, auf denen wir das umgesetzt haben, heisst das konkret: kein RWX-Volume mehr für den Cache, dafür schnelle lokale Storage-Klassen pro Pod, Pods, die sich beliebig neu erzeugen und skalieren lassen, und trotzdem eine clusterweit konsistente Cache-Invalidierung über die zentralen Metadaten. Eine Komponente weniger im kritischen Pfad bedeutet auch eine Komponente weniger in Monitoring, Backup und Incident-Betrieb. Genau aus dieser Überlegung ist unser Cluster File Backend für TYPO3 entstanden — die saubere Umsetzung der Trennung von Metadaten und Payloads.
Wann ein Shared Filesystem trotzdem die richtige Wahl ist
Diese Architektur löst den Cache-Fall — sie ist kein pauschales „RWX ist überflüssig“. Persistente, nicht reproduzierbare Daten brauchen weiterhin einen geteilten, dauerhaften Speicher. In TYPO3 sind das vor allem fileadmin, Nutzer-Uploads und verarbeitete Bilder (_processed_). Für diese Klasse ist unsere Empfehlung in der Regel nicht ein RWX-Volume, sondern Object Storage über FAL (S3-kompatibel) — verlustfrei, skalierbar und ohne den geteilten Dateisystem-Layer. Wer beides sauber trennt — reproduzierbarer Cache lokal, persistente Assets in Object Storage — kommt für die meisten TYPO3-Cluster ganz ohne RWX-Volume aus.
Häufige Fragen
Gilt das auch für fileadmin und Nutzer-Uploads?+
Nein. Der Ansatz betrifft den reproduzierbaren Cache. fileadmin, Uploads und verarbeitete Bilder (_processed_) sind persistent und gehören in Object Storage über FAL (S3-kompatibel), nicht auf ein RWX-Volume.
Wo liegen die Cache-Metadaten, wenn nicht im Dateisystem?+
In einem zentralen Store, den der Cluster ohnehin betreibt — typischerweise die Datenbank oder Redis. Dort liegen Schlüssel, Tags, Ablaufzeiten und Invalidierung; clusterweit konsistent und klein genug, um schnell zu sein.
Was passiert, wenn ein Pod eine Cache-Datei nicht hat?+
Er erzeugt sie lokal neu. Eine fehlende Cache-Datei ist kein Datenverlust, sondern eine einmalige Neuberechnung aus Quelldaten und zentralen Metadaten.
Spart das wirklich Kosten, oder nur Komplexität?+
Beides. RWX-Volumes sind bei Cloud-Providern spürbar teurer als lokale Storage-Klassen, und die wegfallende Komponente entlastet zusätzlich Monitoring, Backup und Incident-Betrieb.
Fazit
Ein Shared Filesystem ist für TYPO3 auf Kubernetes nicht automatisch die beste Lösung — oft ist es nur die aus der Single-Server-Zeit übernommene. Wer Cache-Metadaten und Cache-Dateien voneinander trennt und persistente Assets in Object Storage legt, betreibt sein Cluster einfacher, günstiger und mit einer Ausfallstelle weniger. Die Frage ist selten „Welches RWX-Volume?“, sondern „Welche dieser Daten brauchen wirklich geteilten Zustand — und welche nur, reproduzierbar zu sein?“
Wir prüfen, ob Ihr TYPO3-Cluster das Shared Filesystem wirklich braucht — und bauen es sauber zurück, wo nicht.
Architektur-Review Ihres TYPO3-auf-Kubernetes-Betriebs: Trennung von reproduzierbarem Cache und persistenten Assets, Cluster File Backend für den Cache, Object Storage über FAL für fileadmin, und ein Cluster ohne RWX-Abhängigkeit im kritischen Pfad.
Plattformbetrieb statt Beratung-on-paper: Wir analysieren, bauen um und validieren produktive TYPO3-Plattformen — vom Storage-Konzept bis zum Rollout.
