Kubernetes-HA über mehrere Rechenzentren in der Schweiz: so funktioniert es

Replizierte Control Plane, etcd im Quorum, Storage Genf-Gland-Luzern: was wirklich passiert, wenn ein Rechenzentrum ausfällt.

Ein Kubernetes-Cluster in Single-Zone-Konfiguration erreicht in der Regel 99,9 % Verfügbarkeit, also bis zu 8,7 Stunden Ausfall pro Jahr. Der Wechsel zu einer Multi-Rechenzentrums-Architektur mit replizierter Control Plane hebt das auf 99,99 %, also unter 53 Minuten pro Jahr. Für eine geschäftskritische Anwendung ist das der Unterschied zwischen einem beherrschbaren Vorfall und einem Unterbruch, der kostet.

Was die meisten Beiträge zu Kubernetes-HA auslassen: Die Verfügbarkeit entscheidet sich nicht allein auf Ebene der Worker Nodes. Sie wird an der Control Plane und in etcd gewonnen oder verloren. Diese beiden Schichten zu verstehen, bevor irgendetwas konfiguriert wird, ist die Voraussetzung echter Hochverfügbarkeit.

Was die Verfügbarkeit eines Kubernetes-Clusters wirklich bestimmt

Zwei Kennzahlen steuern jeden HA-Architekturentscheid.

Die RTO (Recovery Time Objective) misst die Zeit, bis Workloads nach einem Ausfall auf den gesunden Standorten neu geplant sind. Auf einem Single-Master-Cluster dauert das mehrere Minuten: Der Ausfall muss erkannt, die Control Plane wiederhergestellt und die Pods neu geplant werden. Auf einem Multi-Master-Cluster mit etcd im Quorum erfolgt das Failover automatisch und in Sekunden: Die Control Plane arbeitet ohne menschlichen Eingriff weiter.

Die RPO (Recovery Point Objective) bestimmt, wie viele Daten bei einem Vorfall verloren gehen können. Sie hängt unmittelbar von der Replikationsstrategie des persistenten Speichers ab. Synchrone Replikation strebt eine RPO an (synchrone Replikation; keine publizierte Zusage): Es gehen keine Daten verloren, weil jeder Schreibvorgang auf allen Standorten bestätigt wird, bevor er quittiert wird. Asynchrone Replikation nimmt einen geringen Datenverlust in Kauf und senkt dafür die Schreiblatenz.

* SLA für Hikube Managed Kubernetes, bestätigt auf hikube.cloud

Diese Kennzahlen setzen die Ziele. Ob sie erreichbar sind, entscheidet die Architektur der Control Plane.

Die Hikube-Control-Plane über drei Schweizer Standorte

Die Hikube-Control-Plane läuft mit 3 von Hikube betriebenen Replicas, verteilt auf die drei Schweizer Rechenzentren Genf, Gland und Luzern. Jedes Replica umfasst einen kube-apiserver, einen kube-scheduler und einen kube-controller-manager. Ergänzt wird das durch einen über die drei Standorte replizierten etcd-Cluster.

Der zentrale Mechanismus ist das etcd-Quorum. Damit die Control Plane weiterarbeitet, muss eine Mehrheit der etcd-Mitglieder verfügbar bleiben. Bei 3 Mitgliedern liegt dieses Quorum bei 2. Fällt das Rechenzentrum Gland vollständig aus, halten Genf und Luzern das Quorum, und die Control Plane plant Workloads ohne Unterbruch weiter. Fallen 2 Rechenzentren gleichzeitig aus, geht das Quorum verloren und die Control Plane wechselt in den Lesemodus, bis ein drittes Mitglied wiederhergestellt ist. Dieser Fall, zwei gleichzeitige Standortausfälle, entspricht einer Wahrscheinlichkeit unterhalb dessen, was ein SLA von 99,99 % abdeckt.

Dieser Mechanismus wird vollständig von Hikube betrieben. Die Kundschaft verwaltet etcd nicht, überwacht das Quorum nicht und löst kein Failover aus. Die Control-Plane-Konfiguration in einem Hikube-Cluster-Manifest:

controlPlane:
replicas, 3
apiServer:
resourcesPreset, small
controllerManager:
resourcesPreset, small
scheduler:
resourcesPreset, micro

Eine Control Plane, die einen Standortausfall übersteht, genügt allein nicht, um die Anwendung verfügbar zu halten. Die Verteilung der Pods (Topology Spread, PDB) ist der zweite Hebel.

Pods: was Kubernetes nicht von selbst verteilt

Die Worker Nodes (Node Groups) laufen im Tenant der Kundschaft. Hikube verteilt sie automatisch auf Genf, Gland und Luzern: Das Rechenzentrum wird nicht gewählt. Kubernetes verteilt Pods nicht von selbst: Ein Deployment mit 3 Replicas kann alle drei ins selbe Rechenzentrum legen. Fällt dieses aus, ist die Anwendung nicht verfügbar, auch wenn die Control Plane auf den beiden anderen Standorten überlebt.

Zwei Mechanismen korrigieren das. Der erste ist der Topology Spread Constraint, der die Verteilung der Pods über Verfügbarkeitszonen erzwingt:

topologySpreadConstraints:
- maxSkew, 1
topologyKey, topology.kubernetes.io/zone
whenUnsatisfiable, DoNotSchedule
labelSelector:
matchLabels:
app, meine-anwendung

Der zweite ist das PodDisruptionBudget, das sicherstellt, dass während eines Rolling Updates oder einer Wartung eine Mindestzahl Pods verfügbar bleibt:

apiVersion, policy/v1
kind, PodDisruptionBudget
metadata:
name, meine-anwendung-pdb
spec:
minAvailable, 2
selector:
matchLabels:
app, meine-anwendung

Beide Konfigurationen liegen in der Verantwortung der Kundschaft, nicht bei Hikube. Ein auf Hikube-Seite korrekt konfigurierter Cluster ohne diese Vorgaben auf Workload-Seite erreicht das SLA von 99,99 % in der Praxis nicht. Wer tiefer in CI/CD-Deploymentstrategien auf Kubernetes einsteigen will, findet in unserem eigenen Beitrag GitOps-Pipelines mit FluxCD.

StorageClass: die Wahl, die Ihre RPO bestimmt

Hikube bietet für persistente Kubernetes-Volumes die Replikation über die drei Standorte, je mit einem anderen Kompromiss zwischen Verfügbarkeit, Leistung und Betriebsaufwand.

* Quelle, Hikube-Dokumentation, docs.hikube.cloud/services/kubernetes/faq

Die Entscheidungsregel ist einfach, Ist Datenverlust nicht hinnehmbar, synchrone Replikation nutzen. Steht die Schreibleistung im Vordergrund und ist ein geringer Verlust tragbar, ist die asynchrone Replikation der richtige Kompromiss. Hikube-Block-Volumes sind stets geo-redundant (Genf, Gland, Luzern), synchron oder asynchron. Die storageClass wird auf Ebene des Cluster-Manifests gesetzt und gilt für alle in diesem Cluster erstellten PVC. Für GPU-Workloads auf Kubernetes empfiehlt sich die storageClass mit synchroner Replikation, um Modell-Checkpoints zu schützen.

Rolling Updates ohne Unterbruch: was Hikube übernimmt, was Sie übernehmen

Kubernetes-Versionsupdates laufen als Rolling Update ohne Unterbruch der Control Plane. Hikube rotiert die Control-Plane-Komponenten einzeln, hält das etcd-Quorum während des gesamten Upgrades und verwaltet die unterstützten Versionen. Die Kundschaft löst das Update über eine Änderung des Cluster-Manifests aus.

Auf Kundenseite gelten zwei Vorgaben. Erstens müssen Upgrades inkrementell sein: Minor-Versionen werden nicht übersprungen. Zweitens müssen die Workloads so konfiguriert sein, dass sie das Rolling Update der Worker Nodes überstehen. Ein kritisches Deployment ohne PodDisruptionBudget und ohne maxUnavailable: 0 kann während der Node-Rotation Pods verlieren.

Empfohlene Konfiguration für kritische Workloads während eines Upgrades:

strategy:
type, RollingUpdate
rollingUpdate:
maxUnavailable, 0
maxSurge, 1

Was passiert, wenn das Rechenzentrum Gland um 3 Uhr morgens ausfällt

Ein konkretes Szenario auf einem korrekt konfigurierten Hikube-Produktionscluster, 3 Control-Plane-Replicas auf Genf, Gland und Luzern, storageClass mit synchroner Replikation, nodeGroups mit aktivierten Topology Spread Constraints.

T+0: vollständiger Ausfall des Rechenzentrums Gland. Alle dort gehosteten Komponenten werden unerreichbar.

T+15 Sekunden: Der kube-apiserver erkennt den Verlust des etcd-Mitglieds in Gland. Das Quorum bleibt mit Genf und Luzern erhalten (2 von 3 Mitgliedern). Die Control Plane arbeitet lesend und schreibend ohne Unterbruch weiter.

T+30 Sekunden: Der kube-controller-manager identifiziert die verwaisten Pods, die zuvor in Gland liefen. Der kube-scheduler plant sie auf den verfügbaren Worker Nodes in Genf und Luzern neu, unter Beachtung der Topology Spread Constraints.

T+45 bis 60 Sekunden: Workloads mit minReplicas ≥ 2 und konfigurierten PodDisruptionBudgets sind wieder voll betriebsbereit. Persistente Volumes mit synchroner Replikation sind ohne Datenverlust aus Genf und Luzern erreichbar.

RTO: eine Grössenordnung, keine publizierte Zusage für korrekt konfigurierte Workloads. RPO angestrebt (synchrone Replikation; keine publizierte Zusage) mit der storageClass für synchrone Replikation. Dieses Szenario setzt eine Konfiguration nach der in diesem Beitrag beschriebenen guten Praxis voraus. Ein Cluster ohne Topology Spread Constraints und ohne PodDisruptionBudgets hat eine deutlich längere RTO.

Fazit

Drei Schichten bestimmen die reale HA eines Kubernetes-Clusters: die Control Plane mit mehreren Replicas und etcd im Quorum über drei Schweizer Standorte (von Hikube betrieben), die Verteilung der Workloads über Topology Spread Constraints und PodDisruptionBudgets (von der Kundschaft zu konfigurieren) und die Wahl der storageClass passend zur angestrebten RPO. HA lässt sich nicht per Klick einschalten. Sie ist eine Verkettung von Architekturentscheiden auf jeder Schicht.

Ihr Kubernetes-Cluster muss den Ausfall eines Schweizer Rechenzentrums überstehen. Unser Managed-Kubernetes-Angebot ansehen →