TYPO3 auf Kubernetes unter IT-Grundschutz, Teil 12: Verfügbarkeit bei hohem Schutzbedarf

01 — Was hohe Verfügbarkeit im Grundschutz bedeutet

Der Schutzbedarf für Verfügbarkeit ergibt sich aus einer einfachen Frage: Wie lange ist ein Ausfall tragbar? Liegt die Antwort bei Stunden statt Tagen, greifen die Anforderungen für erhöhten Schutzbedarf. APP.4.4.A19 verlangt dann Hochverfügbarkeit von Kubernetes. SYS.1.6.A25 verlangt Hochverfügbarkeit der containerisierten Anwendungen.

Zusammen bedeutet das: Kein einzelner Knoten, keine einzelne Verfügbarkeitszone und kein einzelnes Speichersystem darf die Anwendung allein tragen. Betroffen sind die Steuerung des Clusters, die Rechenknoten, der Speicher und die Datenbank.

02 — Control Plane und Knoten

Eine Control Plane mit einem einzigen Server ist ein Single Point of Failure. Fällt er aus, laufen die vorhandenen Pods zwar weiter. Aber nichts wird mehr neu geplant, skaliert oder repariert. k3s unterstützt dafür drei Server-Knoten mit eingebettetem etcd oder einen externen Datenspeicher. Bei kubeadm gilt dasselbe Prinzip mit gestapeltem oder externem etcd. Verwaltete Dienste betreiben die Control Plane ohnehin redundant. Drei ist die Mindestzahl, damit etcd beim Ausfall eines Knotens die Mehrheit behält.

Die Worker-Knoten verteilen sich auf mehrere Verfügbarkeitszonen. Topology Spread Constraints sorgen dafür, dass die Replicas eines Mandanten nicht zufällig in derselben Zone landen:

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app.kubernetes.io/name: typo3

Wichtig ist hier ScheduleAnyway. Mit DoNotSchedule zählt Kubernetes die Knoten einer ausgefallenen Zone weiter als eigene Zone mit. Dort läuft kein Pod mehr. Je nach Zahl der Zonen verbietet die Regel dann, die Ersatz-Pods in den übrigen Zonen zu starten, und sie bleiben im Zustand Pending. Das passiert genau in dem Ausfall, für den die Verteilung gedacht ist. Die weiche Regel verteilt im Normalbetrieb genauso gleichmäßig.

Fällt eine Zone aus, ersetzt der Deployment-Controller die verlorenen Pods in den übrigen Zonen. Damit dort genug Platz ist, braucht es freie Reserve oder den Cluster Autoscaler aus Teil 9.

03 — Speicher und Datenbank, die mitziehen

Pods lassen sich schnell verschieben. Ihr Speicher oft nicht. Ein Block-Volume in einer Zone bindet den Pod an genau diese Zone. Für TYPO3 hilft es, so wenig Zustand wie möglich lokal zu halten, wie in Teil 8 beschrieben: fileadmin im Objektspeicher, Sessions und Caches in Valkey. Was dann noch bleibt, braucht replizierten Speicher oder ein Volume, das in jeder Zone verfügbar ist. Valkey selbst braucht dann Replikation mit automatischem Umschalten, sonst meldet sein Ausfall alle Sitzungen ab.

Die Datenbank ist der schwierigste Teil. Eine einzelne MariaDB-Instanz ist auch mit perfektem Backup ein Ausfallpunkt. Hohe Verfügbarkeit verlangt Replikation. Entweder eine Primär-Replik-Kopplung mit automatischem Failover. Oder ein Galera-Cluster mit mehreren gleichberechtigten Knoten. Beides braucht Übung, denn ein Failover, der nie geprobt wurde, scheitert gern am Detail.

Sicherungen gehören zusätzlich in eine andere Region. Fällt eine ganze Region aus, hilft eine Replik in derselben Region nicht. Wie die Sicherung selbst aufgebaut ist, zeigt Teil 10.

04 — Neu aufbauen statt umschalten, und das Restrisiko

Nicht jede Umgebung braucht sofort drei Zonen und einen Datenbank-Cluster. Eine Alternative für kleinere Setups ist der schnelle Neuaufbau. Die komplette Infrastruktur liegt als Code vor, die Anwendung kommt per GitOps, die Daten kommen aus den Sicherungen. Fällt die Umgebung aus, entsteht sie neu, statt umzuschalten.

Das funktioniert, hat aber eine klare Grenze: das RTO. Ein Neuaufbau dauert Stunden, ein Failover Minuten. Reicht die gemessene Wiederaufbauzeit für den festgelegten Schutzbedarf, ist der Weg vertretbar. Reicht sie nicht, führt kein Weg an Redundanz vorbei.

Wer „hoch“ bei der Verfügbarkeit noch nicht erfüllt, dokumentiert das als Restrisiko. Mit Begründung, Verantwortlichem und einem Termin für die nächste Bewertung. Notfallübungen gehören in jedem Fall dazu, eingebettet in ein Notfallmanagement nach BSI-Standard 200-4. Erst die Übung zeigt, ob die geplante Zeit hält.

Fazit

Hohe Verfügbarkeit ist der aufwendigste Teil der Serie. Sie verlangt Redundanz bei Control Plane, Knoten, Speicher und Datenbank. Und sie verlangt Übung. Wer sie noch nicht erfüllt, entscheidet bewusst und dokumentiert das Restrisiko in der Risikoanalyse nach BSI-Standard 200-3.

Weiter mit Teil 13: TYPO3 selbst härten. Die Übersicht aller Teile und die Einordnung in die Grundschutz-Bausteine stehen in Teil 1: Welche Bausteine wirklich greifen. Zurück zu Teil 11: Nachweis und Betrieb.