TYPO3 Kubernetes — TYPO3, das nicht am einzelnen Server klebt.

Nein. Für eine 50-Seiten-Broschüre-Website mit einer Redakteurin reicht in der Regel ein gutes Managed-TYPO3-Hosting. Kubernetes wird ab einem der drei Punkte interessant: regelmäßige Lastspitzen, mehrere Redaktions-Mandanten in einem Setup, oder Compliance-Anforderungen, die nachweisbare Trennung verlangen.

Drei Eigenheiten: fileadmin braucht Shared Storage, Scheduler-Jobs dürfen nicht parallel auf denselben Pods laufen (sonst Doppelversand), und der Install-Tool-Endpoint muss netzwerkseitig hart geschnitten werden. Wer einen TYPO3-Cluster wie eine x-beliebige PHP-App betreibt, baut sich Folge-Bugs ein.

Für eine Standard-TYPO3-Site auf einen sauberen Cluster: meist 4–8 Wochen, inklusive Helm-Chart, Persistent Storage, CI/CD-Pipeline, Monitoring-Stack und Rollback-Drills. Wer das ad-hoc macht, ist schneller; wer es nachhaltig macht — also so, dass die zweite Site in einem Bruchteil der Zeit hochgezogen wird — investiert einmal mehr.

Bei einer einzigen Site oft ja. Bei drei und mehr Sites, die sich Cluster, Monitoring und CI/CD teilen, kippt das Verhältnis. Plus: weniger Personenstunden für Routine-Updates, schnelleres Rollback bei Fehlern, geringeres Ausfall-Risiko — das läuft im klassischen TCO selten in der Hosting-Rechnung mit.

Praktisch alle ab TYPO3 9 LTS, vernünftig ab 11 LTS, empfohlen 12/13 LTS. Bei älteren Versionen wird der Container-Build und das Storage-Setup aufwändiger, weil viele Setups noch direkte Filesystem-Annahmen treffen. Ein Upgrade-Pfad parallel zur Cluster-Migration ist oft die saubere Lösung.

Erstgespräch zu aktueller Infrastruktur, Last-Profil und Compliance-Anforderungen. Daraus eine konkrete Cluster-Skizze: welcher Provider, welche Storage-Strategie, welche CI/CD-Pipeline, welche Monitoring-Bausteine. Umsetzung iterativ — erst Staging, dann Produktion, mit Rollback-Drill vor Go-Live.

Nicht zwangsläufig — beide Themen adressieren unterschiedliche Achsen. AI-Ready CMS heißt: strukturierte Content-Delivery, retrieval-/agent-kompatible Endpoints, sauberes Datenmodell. Das funktioniert auch auf einem einzelnen Server. Cluster-Betrieb heißt: Last, Verfügbarkeit, Mandantentrennung, reproduzierbare Deployments. Beide treffen sich dort, wo derselbe Mandant erstens in generativer Suche sichtbar sein und zweitens Lastspitzen oder Verfügbarkeits-Anforderungen abfedern muss. Dann zahlt die Cluster-Disziplin in die KI-Use-Cases ein — sie ist aber nicht der Grund, AI-ready zu werden, und kein Muss dafür.

Aus unserem eigenen Stack: cluster-file-backend für Shared Storage von fileadmin (S3-kompatibel oder Object Storage), frankenphp als PHP-Runtime im Worker-Mode (weniger Startup-Cost pro Pod), keyvalue-store für Redis/Valkey-Cache und Session-Sharing, typo3-config als Fluent-Config-API für Caching, Logging und TLS/mTLS, secret-resolver für SOPS-/Vault-/KMS-Anbindung. Alles offen unter MIT, alles in unserer eigenen Plattform produktiv — keine Black-Box-Lieferung. Details in der Sektion „Verwandte Open-Source-Pakete“ weiter oben.

Stateless: Frontend-Pods, Scheduler-Worker, Indexer-Pods, FrankenPHP-Workers — die können Sie beliebig hochskalieren, neu rollen und wegwerfen. Stateful: die Datenbank (MariaDB/MySQL/Postgres im StatefulSet oder als managed Service), der File-Storage (S3/Object-Store oder ReadWriteMany-Volume), der Session-/Cache-Store (Redis/Valkey), der Solr- oder OpenSearch-Index. Faustregel: alles, was Daten persistiert, wandert außerhalb des Application-Deployments — dann lässt sich der Pod-Pool wirklich stateless betreiben.

Zwei Pfade. Erstens: FAL-Driver mit S3-kompatiblem Backend (über unsere cluster-file-backend-Extension oder einen S3-FAL-Driver), der fileadmin und Processed-Files im Bucket hält — Renditions landen ebenfalls dort und bleiben über Pod-Restarts hinweg erhalten. Zweitens für Bestands-Setups, die nicht migriert werden: ReadWriteMany-Volume (NFS oder CephFS) mit gemeinsamem Processed-File-Pfad. Wichtig in beiden Pfaden: ein CDN davor (CloudFront, Fastly oder europäische Alternative), damit der Bucket nicht zur Render-Maschine wird, und identische ProcessedFileRepository-Konfiguration in jedem Pod, damit dieselben Cache-Keys gebildet werden.

Im Frontend bleibt TYPO3-Session-Handling über Cookies und FE-User-Hash zustandsarm genug, dass jeder Pod sie auflösen kann. Sobald Warenkörbe, mehrstufige Formulare oder authentifizierte Sessions ins Spiel kommen, gehört der Session-Store in ein zentrales Backend — Redis oder Valkey über die keyvalue-store-Extension, mit AUTH und TLS zwischen Pod und Store. Sticky Sessions am Ingress sind eine Krücke, die im ersten Pod-Reschedule kippt; wir empfehlen sie nicht. Das Backend-Session-Handling läuft über den separaten Worker-Pool und sollte sich denselben Store teilen.

Wir setzen Redis oder Valkey praktisch immer ein, sobald TYPO3 unter realer Last steht — unabhängig davon, ob ein oder mehrere Pods laufen. Der primäre Grund ist Datenbank-Entlastung und Cache-Speed: die typo3_cache_*-Tabellen werden in MySQL oder Postgres schnell zur spürbaren Last, weil jeder Cache-Read als SQL-Query läuft statt aus dem RAM zu kommen. Ein In-Memory-Store nimmt diesen Druck weg und beschleunigt die Cache-Wege deutlich. Im Multi-Pod-Setup kommt der zweite Grund hinzu: ein zentraler Cache-Store ist sauberer als ein File-Cache auf ReadWriteMany-Volume, weil Invalidierungen atomar greifen statt über Filesystem-Locks zu laufen. Valkey ist seit dem Redis-Lizenzwechsel auf SSPL die Default-Wahl — protokollkompatibel, BSD-3-Clause-lizenziert, bei europäischen Anbietern als Managed Service verfügbar.

Wir verdrahten mTLS auf vier Ebenen, weil jede einzelne sonst die schwächste Stelle wäre:

• Pod-zu-Pod über ein Service Mesh — Linkerd in den meisten Setups (leichter Sidecar, mTLS by Default), Istio wenn die Plattform bereits dort steht. Identität kommt aus dem ServiceAccount, nicht aus der Pod-IP.
• Pod-zu-Datenbank mit Client-Zertifikaten an MariaDB oder Postgres. Kein Passwort über den Draht, Identität über das Zertifikat — sobald der Zertifikats-Workload weg ist, ist auch die Verbindung weg.
• Pod-zu-Cache mit TLS plus Client-Auth an Redis/Valkey. AUTH alleine reicht uns nicht; das Zertifikat schiebt die Identität in dieselbe Schicht wie alle anderen Verbindungen.
• Ingress-zu-Origin auf der Reverse-Proxy-Strecke (z. B. Caddy zu FrankenPHP). HTTPS am Edge ist Standard, aber zwischen Ingress-Controller und Pod laufen viele Setups noch Klartext — das schließen wir konsequent.

Zertifikate kommen aus einer internen CA, orchestriert über cert-manager, der je nach Plattform den passenden Issuer anspricht — private CA on-prem, HashiCorp Vault, AWS Private CA, Azure Key Vault. Automatische Rotation typisch alle 24 Stunden. Die typo3-config-Extension nimmt die Zertifikate aus dem Pod-Volume und mountet sie sauber an die TLS-Endpunkte der Datenbank- und Cache-Verbindungen, sodass TYPO3 selbst nichts davon mitbekommen muss außer dem Pfad.

Vorteile: keine Klartext-Credentials im Image, keine Pod-Identität über IP-Adressen, NIS-2- und Branchen-Compliance-Argument auf der Verschlüsselungs-Achse fast geschenkt. Preis: Observability wird teurer (Mesh-Sidecar bringt Latenz und Tracing-Overhead), Debugging braucht mTLS-bewusste Tools (linkerd tap, istioctl proxy-config). Wer einmal mit Klartext-Pod-Traffic gelebt hat, will nicht zurück.

Backup ohne dokumentierten Restore-Drill ist eine Hoffnung. Praxis: tägliche Datenbank-Dumps plus Persistent-Volume-Snapshots (Velero deckt beides Kubernetes-nativ ab), wöchentliche Object-Storage-Versionierung, vierteljährlicher Restore-Drill in ein isoliertes Namespace mit Smoke-Test. Dokumentiertes RPO (typisch 1 Stunde für Standard-Setups, 15 Minuten für E-Commerce) und RTO (4 Stunden Standard, 1 Stunde für kritische). Wer den Restore nicht einmal pro Quartal probt, weiß im Ernstfall nicht, ob er funktioniert — und das ist genau der Ernstfall.

Standard-Muster: eine Primary-Region mit Schreib-Datenbank und Editorial-Backend, eine oder mehrere Read-Regions mit Read-Replicas oder geografisch verteilten Frontend-Pods, die ausschließlich lesen. CDN davor (CloudFlare, Fastly oder europäische Anbieter wie OVHcloud), damit Cache-Hits regional terminieren. File-Storage entweder zentral mit CDN-Pull-Through oder über Cross-Region-Replication des Object-Stores. Editorial-Schreibvorgänge erzeugen Cache-Tag-Invalidierungen, die über die CDN-API in alle Regionen ausgerollt werden. Failover auf eine andere Region heisst Promotion eines Replicas zur Primary, nicht Multi-Master — das vermeidet Konfliktfelder im TYPO3-Datenmodell.

Vier Phasen. Erstens: am Ziel-Provider den Cluster aufbauen, dieselben Helm-Charts deployen, Test-Domain dranhängen, Smoke-Tests. Zweitens: Datenbank-Replikation aufsetzen (Primary alt → Replica neu, asynchron oder semi-synchron), File-Storage spiegeln (Object-Store-Replication oder rsync-Sync-Phase). Drittens: kurze Wartungsphase, Datenbank-Schwenk auf den neuen Primary, DNS auf neuen Ingress umstellen — oft 5 bis 15 Minuten Hard-Cutover. Viertens: der alte Cluster bleibt zwei Wochen als Rollback-Anker stehen, dann Abriss. Mit container-basierten Charts und ordentlichem Provider-Reset ist das ein zwei- bis vierwöchiges Projekt, nicht ein Quartal.

GitOps heißt: der Cluster-Zustand ist im Git-Repository, ein Controller (ArgoCD oder Flux) reconcilet ihn permanent gegen den Live-Cluster. Für TYPO3 bedeutet das: Helm-Chart-Repository plus values-Files pro Stage (dev/staging/prod) im Repo, Secrets verschlüsselt über SOPS+age oder External Secrets aus Vault/KMS gezogen — nie im Klartext, nie im Image. Jede Änderung läuft über Pull Request mit Code-Review, jedes Rollback ist ein Git-Revert. Wir setzen ArgoCD in den meisten Setups ein, Flux dort, wo der Operator bereits etabliert ist; die Wahl ist meist Team-Präferenz, nicht technisch zwingend.

Drei Hebel. Erstens llms.txt und robots.txt mit klaren Crawl-Budgets und Pfad-Whitelists — das adressiert die Bots, die sich an Regeln halten. Zweitens Ingress-seitiges Rate-Limiting pro User-Agent (NGINX limit_req mit User-Agent-Schlüssel, Traefik-Middleware oder Caddy-Rate-Limit), damit ein durchgedrehter Crawler den Frontend-Pool nicht zieht. Drittens ein separater Worker-Pool nur für identifizierten AI-Crawler-Traffic über Header-basiertes Routing — dann bleibt der Frontend-Pool für menschliche User unberührt, und der Crawler-Pool lässt sich separat skalieren oder bei Bedarf abklemmen. Bei sensiblen Pfaden (Install-Tool, Admin-Endpoints, interne Routen) sowieso 404/403 unabhängig vom User-Agent.