Kubernetes: 30%-Knoten-Ausfalltest

Kubernetes-Failover-Übungen: 30 % der Knoten im Produktivbetrieb deaktivieren

Das Team deaktivierte 30 % der Knoten in einem produktiven OKD-basierten Kubernetes-Cluster, um echte Schwächen in der Systemresilienz aufzudecken. Diese Übung testete, wie die Steuerungsebene, Infrastrukturkomponenten und Anwendungs-Dienste auf einen schwerwiegenden Infrastrukturausfall reagierten. Bisher unsichtbare Probleme mit Webhook-Controllern und Replikatverteilung traten nun deutlich zutage.

Cluster-Architektur im Test

Der Cluster läuft in der Cloud über drei Verfügbarkeitszonen, jeweils in einem separaten Rechenzentrum mit einer Latenz von weniger als 1 ms zwischen ihnen. Die vollständig vernetzte Topologie simuliert lokales Netzwerkverhalten.

Wichtige Komponenten:

• Benutzer-Lastverteilung: Backends sind 3 Infra-Knoten mit Ingress-Pods und Persistent Volume Controller.
• API-Lastverteilung: Backends sind 3 Master-Knoten, die die Steuerungsebene hosten.
• Worker-Knoten: Gleichmäßig über die Zonen verteilt, insgesamt N Stück.

Diese Architektur ermöglicht die Simulation eines kompletten Zonen-Ausfalls ohne Verlust der Quorum-Bedingung – etcd kann den Ausfall von bis zu einem der drei Master-Knoten überstehen.

Vorbereitung der Katastrophenübung

Der Plan umfasste acht Schritte:

• Überprüfung des Baseline-Zustands von Cluster und Diensten.
• Erstellung von Snapshots für Master- und Infra-Knoten zur schnellen Wiederherstellung.
• Deaktivierung aller Knoten in einer Zone (oder 1 Master, 1 Infra + 30 % Worker-Knoten).
• Beobachtung über 1–2 Stunden: Protokollierung von Fehlern, Sammlung von Metriken, Unterstützung durch Teams.
• Wiederherstellung der deaktivierten Knoten.
• Neubewertung des Cluster-Zustands.
• Abschluss der Übung.
• Dokumentation der Maßnahmen.

Snapshots werden bei Übungen bevorzugt gegenüber etcd-Backups – sie ermöglichen schnellere Wiederherstellung und geringeres Risiko. Worker-Knoten werden nicht gesichert, da ihr Zustand in etcd liegt. Infra-Knoten werden gesichert, da sie persistenten Speicher nutzen.

30 % ist ein ausgewogener Zielwert: realistischer Ausfall-Szenario (Test von Anti-Affinity, PDBs, Replikation), aber nicht katastrophal. Das Master-Quorum hält bis zu 33 % Verlust stand.

Erfolgskriterien:

• API bleibt erreichbar.
• Pods können erstellt und gelöscht werden.
• Persistent Volumes bleiben verfügbar.
• Dienste funktionieren weiterhin.
• Replikat-Wiederherstellung innerhalb von 10–15 Minuten.
• Warnmeldungen sind behoben (außer jene von abgeschalteten Knoten).

Übung #1: Entwicklungsumgebung

Deaktiviert: 1/3 – 1 Master, 1 Infra, ca. 80 Worker-Cores. Der Load Balancer entfernte fehlerhafte Backends innerhalb einer Minute. Die API blieb reaktionsschnell, doch die Knoten wechselten für 300 Sekunden in den Zustand "Unknown", danach in "NotReady"/"Unreachable".

Pods starteten erst nach zehn Minuten neu. Beim Erstellen neuer Pods erschien folgender Fehler:

Error from server (InternalError): error when creating "pod.yaml": Internal error occurred: failed calling webhook "mutate.kyverno.svc-fail": failed to call webhook: Post "https://infra-kyverno-svc.infra-kyverno.svc:443/mutate/fail?timeout=30s": dial tcp 10.128.4.174:9443: connect: connection refused

Kyverno (Admission/Mutation-Webhook) hatte je Typ nur einen Pod, wobei 2/3 in der deaktivierten Zone lagen – nun im Zustand "Terminating". Ohne aktive Webhooks erreichen Änderungen nie etcd. System-Namespace sind von Kyverno ausgeschlossen, um Deadlocks zu vermeiden.

Erhöhung der Kyverno-Replikazahl. Ereignisse zeigten, dass das Scheduling aufgrund von Ressourcenengpässen blockiert war (implizit aus Kontext, nicht explizit genannt).

Probleme und Lösungen

Kyverno: Umstellung auf mindestens 3 Replikas pro Webhook-Typ mit zone-awarer Topologie-Verteilung.

Scheduler-Blockade: Überprüfung von Ressourcenquoten und -grenzen in betroffenen Namespaces.

In der Produktion (Übungen #2 & #3) zeigten sich ähnliche Szenarien in größerem Maßstab: PDB-Verstöße bei Diensten ohne korrekte Anti-Affinity sowie Verzögerungen bei der Migration von PVs.

Die Anwendungsteams erhielten eine Checkliste:

• Mindestens 3 Replikas.
• PodDisruptionBudget mit minAvailable.
• TopologySpreadConstraints oder nodeAffinity.
• Ressourcenanforderungen/Limits.
• Liveness-/Readiness-Probes mit sinnvollen Timeout-Werten.

Was wirklich zählt

• Die Deaktivierung von 30 % der Knoten bringt verborgene Probleme mit Webhooks und Scheduling ans Licht, die sonst nicht sichtbar sind.
• Kyverno benötigt mehr als eine Replik, gleichmäßig über die Zonen verteilt.
• Der standardmäßige 300-Sekunden-Timeout für "NotReady/Unreachable" erfordert Puffer-Ressourcen.
• Snapshots von Infra- und Master-Knoten sind essenziell für sichere Übungen.
• Vollständige Wiederherstellung: 10–15 Minuten für Replikate plus Auflösung von Warnmeldungen.

Empfehlungen für Teams

Für Service-Entwickler:

• Setze PDBs: minAvailable: 50 %.
• Nutze topologySpreadConstraints für Zonen-Verteilung.
• Setze CPU/RAM-Anforderungen/Grenzen auf 80 % der beobachteten Spitzenwerte.
• Probes mit 5–10 Sekunden Timeout und 3 Wiederholungen.

Für Kubernetes-Admins:

• Stelle sicher, dass Kyverno und andere Webhooks >3 Replikas mit hoher Verfügbarkeit haben.
• Überwache etcd-Leader-Wahlen.
• Plane Kapazität mit +30 % Reserve.
• Automatisiere Snapshots vor jeder Übung.

Diese Übungen sind unverzichtbar für jeden Produktiv-Cluster mit mehr als 100 Knoten.

— Editorial Team