Warum TYPO3 bei uns in Containern läuft, nicht auf klassischem Hosting
Ein Prozess, der abstürzt, bleibt unten, bis jemand es merkt
Auf klassischem Shared- oder Server-Hosting ist eine Website ein Prozess unter vielen auf einer Maschine. Stürzt dieser Prozess ab, weil ein Request zu viel Speicher zieht oder eine Extension in eine Endlosschleife läuft, bleibt die Seite unten, bis ein Mensch es bemerkt und neu startet. Kubernetes behandelt denselben Fall strukturell anders: die Plattform selbst beobachtet, ob ein Container noch antwortet, und greift ein, bevor ein Besucher etwas davon mitbekommt.
Zwei Fragen, zwei Mechanismen
Kubernetes stellt jedem Container zwei unterschiedliche Fragen. Die Liveness-Probe fragt: lebt der Prozess noch? Antwortet er nicht, beendet und startet Kubernetes ihn neu, automatisch, ohne dass jemand eingreifen muss. Die Readiness-Probe fragt etwas anderes: ist der Prozess bereit, Anfragen zu bedienen? Ein Container kann leben, aber gerade nicht bereit sein, etwa weil er noch startet oder kurzzeitig überlastet ist. In diesem Fall nimmt Kubernetes ihn aus der Lastverteilung, ohne ihn zu beenden, und gibt ihm die Zeit, sich zu erholen. Beide Mechanismen laufen kontinuierlich, nicht als einmalige Prüfung beim Start.
Isolation, die nicht an der Konfiguration hängt
Auf einer gemeinsam genutzten Maschine ohne Container-Grenzen kann ein ressourcenhungriger Prozess andere ausbremsen, einfach weil sie sich dieselbe CPU und denselben Arbeitsspeicher teilen. Container-Laufzeiten erzwingen diese Grenze technisch, über cgroups: jedem Container stehen definierte Ressourcengrenzen zur Verfügung, die das Betriebssystem selbst durchsetzt, nicht eine Anwendungseinstellung, die vergessen werden kann. Dazu kommen eigene Namespaces für Prozesse, Netzwerk und Dateisystem, sodass ein Container grundsätzlich nicht sieht, was in einem anderen passiert.
Ein Versions-Wechsel ohne Lücke
Rollt eine neue Version aus, ersetzt Kubernetes nicht alle Instanzen auf einmal. Neue Container starten, durchlaufen ihre Readiness-Probe, und erst wenn sie als bereit gelten, übernehmen sie Traffic von den alten. Schlägt die neue Version fehl, etwa weil sie nicht startet, bleibt die alte Version im Einsatz und bedient weiter Anfragen. Der Wechsel ist damit kein Umschalt-Moment mit Risiko, sondern ein schrittweiser Übergang mit eingebauter Kontrolle.
Was das für TYPO3-Hosting bedeutet
Bei TYPO3-Hosting stellt sich dieselbe Frage wie bei jedem anderen Betrieb: was passiert, wenn ein Request zu viel Speicher zieht oder eine Extension hängen bleibt. Auf klassischem Hosting ist das eine Frage der Reaktionszeit eines Menschen im Hintergrund. In einem Cluster ist es eine Frage der Konfiguration, die einmal richtig gesetzt wird und danach kontinuierlich wirkt, unabhängig davon, wer gerade erreichbar ist.
Quellen: Kubernetes-Dokumentation zu Liveness- und Readiness-Probes, NGINX-Blog zu Namespaces und cgroups.
