TYPO3 on Kubernetes under IT-Grundschutz, part 12: Availability with a high protection need
Confidentiality and integrity can be secured well in a TYPO3 cluster with reasonable effort. Availability is different. A high protection need means that a single failure must not take the website offline for longer than defined. That takes redundancy at every level, from the control plane to the database.
Part 12 of 14 of the series "TYPO3 on Kubernetes under IT-Grundschutz". The overview of all parts is in part 1.
01 — What high availability means in Grundschutz
The protection need for availability comes from one simple question: how long can you tolerate an outage? If the answer is hours rather than days, the requirements for an increased protection need apply. APP.4.4.A19 then asks for high availability of Kubernetes. SYS.1.6.A25 asks for high availability of the containerised applications.
Together that means no single node, no single availability zone and no single storage system may carry the application alone. It affects the control of the cluster, the compute nodes, the storage and the database.
02 — Control plane and nodes
A control plane with a single server is a single point of failure. If it goes down, existing pods keep running. But nothing gets scheduled, scaled or repaired any more. k3s supports three server nodes with embedded etcd or an external datastore for this. With kubeadm the same principle applies with stacked or external etcd. Managed services run the control plane redundantly anyway. Three is the minimum so that etcd keeps its quorum when one node fails.
The worker nodes are spread across several availability zones. Topology spread constraints make sure a tenant's replicas do not end up in the same zone by chance:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app.kubernetes.io/name: typo3
ScheduleAnyway matters here. With DoNotSchedule, Kubernetes keeps counting the nodes of a failed zone as a zone of their own. No pod runs there any more. Depending on the number of zones, the rule then forbids starting the replacement pods in the remaining zones, and they stay Pending. That happens in exactly the outage the spread was meant for. The soft rule spreads just as evenly in normal operation.
If a zone fails, the deployment controller replaces the lost pods in the remaining zones. For enough room there, you need spare capacity or the cluster autoscaler from part 9.
03 — Storage and database that follow along
Pods move quickly. Their storage often does not. A block volume in one zone ties the pod to exactly that zone. For TYPO3 it helps to keep as little state local as possible, as described in part 8: fileadmin in object storage, sessions and caches in Valkey. Whatever remains needs replicated storage or a volume that is available in every zone. Valkey itself then needs replication with automatic failover, otherwise its loss ends every session.
The database is the hardest part. A single MariaDB instance is a point of failure, even with a perfect backup. High availability requires replication. Either a primary and replica with automatic failover. Or a Galera cluster with several equal nodes. Both need practice, because a failover that was never rehearsed tends to fail on a detail.
Backups also belong in another region. If a whole region fails, a replica in the same region does not help. How the backup itself is built is shown in part 10.
04 — Rebuild instead of fail over, and the residual risk
Not every setup needs three zones and a database cluster right away. An alternative for smaller setups is a fast rebuild. The entire infrastructure exists as code, the application arrives via GitOps, the data comes from the backups. If the environment fails, it is rebuilt instead of failed over.
That works, but it has a clear limit: the RTO. A rebuild takes hours, a failover minutes. If the measured rebuild time fits the defined protection need, the approach is defensible. If it does not, there is no way around redundancy.
If you do not yet meet “high” for availability, document it as residual risk. With a reason, an owner and a date for the next review. Disaster drills belong in either case, embedded in business continuity management following BSI standard 200-4. Only the drill shows whether the planned time holds.
Frequently asked questions
How many control plane nodes does a highly available k3s cluster need?+
Three server nodes with embedded etcd. Alternatively two or more server nodes with an external datastore that is itself highly available. With three nodes, etcd survives the loss of one node and keeps its quorum.
Is a fast rebuild enough instead of high availability?+
Only if the measured rebuild time stays within the tolerable downtime. With a high protection need for availability, that is rarely the case. Then the rebuild remains part of disaster preparedness, but it does not replace redundancy.
Galera or primary and replica for TYPO3?+
Both work. Galera allows writes on every node, but needs at least three nodes and has limits with very large transactions. A primary and replica setup is simpler to build. It stands or falls with a reliable automatic failover.
How do you document an unmet availability requirement?+
As residual risk in the risk analysis. Which requirement is not met, what an outage would cause, why the risk is accepted and who owns it. Plus a date for the next review.
Conclusion
High availability is the most demanding part of the series. It needs redundancy in control plane, nodes, storage and database. And it needs practice. If you do not meet it yet, decide consciously and document the residual risk in your risk analysis following BSI standard 200-3.
Continue with part 13: hardening TYPO3 itself. The overview of all parts and how they map to the Grundschutz modules is in part 1: which modules actually apply. Back to part 11: evidence and operations.
I plan the availability of your TYPO3 cluster with you, from the control plane to a practised failover.
Define the protection need, choose the right redundancy, and measure the recovery time in a test instead of estimating it.
Platform operations rather than advice on paper: if you want, I accompany your disaster drills and document result and residual risk for your audit.
About the author
Kai Ole Hartwig
Programming since 2002 – self-taught, set up my own business with KO-Web in 2012. Over 100 projects, with a focus on security, performance, automation and quality. Today freelance: DevSecOps consulting, training and software development.