Automatisches Failover für Kubernetes-Backends planen

TL;DR

Kubernetes Backend Failover beginnt nicht beim Umschalten des Traffics, sondern bei klar definierten Zuständen: Welche Endpunkte gelten als gesund, wann wird ein Backend aus dem Routing genommen und wohin wird weitergeleitet? Die ayedo Edge Cloud trennt diese Edge-Entscheidung von der Verfügbarkeit der Kubernetes-Workloads und schafft damit eine belastbare Grundlage für kontrolliertes Failover.

Einleitung

Ein Kubernetes-Service kann intern verfügbar sein und trotzdem von außen nicht zuverlässig erreichbar bleiben. Umgekehrt kann ein Backend technisch antworten, obwohl die Anwendung bereits fehlerhafte oder unvollständige Antworten liefert. Genau deshalb ist automatisches Failover keine einzelne Loadbalancer-Funktion, sondern eine Architekturentscheidung: Health Checks müssen den relevanten Zustand prüfen, Failover-Regeln müssen zum Betriebsmodell passen und die Kubernetes-Workloads müssen selbst hochverfügbar ausgelegt sein. Die Edge Cloud kann öffentlichen Traffic bei einem erkannten Backend-Ausfall kontrolliert umleiten. Sie ersetzt jedoch weder Replica-Strategien noch Pod-Scheduling, Datenbankreplikation oder Disaster-Recovery-Verfahren innerhalb der Compute-Infrastruktur.

1. Health Checks müssen den richtigen Fehler erkennen

Ein Backend Health Check beantwortet nicht pauschal die Frage, ob ein Kubernetes-Cluster „online“ ist. Er prüft einen definierten technischen Zustand: Erreichbarkeit, Protokollverhalten oder die Antwort eines festgelegten Endpunkts. Ein einfacher TCP-Check erkennt beispielsweise, dass ein Port Verbindungen annimmt. Er sagt jedoch wenig darüber aus, ob die Anwendung Requests korrekt verarbeitet. Ein HTTP-Check kann dagegen Statuscodes oder die Erreichbarkeit eines konkreten Pfads bewerten.

Für Kubernetes-Backends sollte der Prüfpunkt zur Verantwortungsgrenze passen. Ein Readiness-Zustand innerhalb des Clusters und ein Health Check an der öffentlichen Edge verfolgen ähnliche, aber nicht identische Ziele. Die Kubernetes-Steuerung entscheidet, ob ein Pod Traffic erhalten soll. Die Edge Cloud entscheidet, ob ein öffentlich erreichbares Backend für eingehenden Traffic verwendet wird. Werden beide Ebenen vermischt, entstehen falsche Sicherheit oder unnötige Failover-Ereignisse.

2. Failover-Regeln brauchen eindeutige Zustände

Kubernetes Backend Failover funktioniert nur zuverlässig, wenn Ausfall, Degradation und Wartung unterscheidbar sind. Ein einzelner fehlgeschlagener Check sollte nicht automatisch zu einer sofortigen globalen Umschaltung führen. Netzwerkunterbrechungen, kurze Neustarts oder temporäre Überlast können sonst unnötige Routingwechsel auslösen. Umgekehrt darf ein dauerhaft fehlerhaftes Backend nicht zu lange als gesund gelten.

Bei der Planung sind deshalb Prüfintervall, Fehlergrenze und Wiederfreigabe gemeinsam zu betrachten. Entscheidend ist außerdem, ob auf ein alternatives Backend, einen anderen Cluster oder eine bewusst begrenzte Fehlerantwort umgeschaltet wird. Traffic Failover ist kein Versuch, beliebige Kapazität zu erzeugen. Das Ziel besteht darin, Requests nur an ein Ziel weiterzuleiten, dessen Betriebszustand bekannt und für den jeweiligen Service geeignet ist.

Die ayedo Edge Cloud stellt dafür Backend Health Checks und Failover auf der öffentlichen Traffic-Ebene bereit. Die konkrete Wirkung hängt von den definierten Backends und Routing-Regeln ab. Eine automatische Umschaltung sollte daher immer mit Runbooks, Monitoring und einem kontrollierten Rückschaltverhalten verbunden werden.

3. Edge-Failover und Workload-Verfügbarkeit trennen

Die Edge kann einen ausgefallenen Cluster aus dem öffentlichen Routing nehmen. Sie stellt dadurch aber keine neuen Pods bereit, repariert keine fehlerhafte Anwendung und synchronisiert keine Daten. Kubernetes Hochverfügbarkeit bleibt eine Aufgabe der Compute-Infrastruktur. Dazu gehören unter anderem ausreichende Replikate, Verteilung über geeignete Ausfallbereiche, funktionierende Readiness- und Liveness-Mechanismen sowie die Verfügbarkeit abhängiger Systeme.

Diese Trennung ist auch für die Fehlersuche wichtig. Wenn die Edge einen Cluster wegen fehlgeschlagener Checks aus dem Traffic nimmt, kann der Fehler im Ingress-Pfad, im Service, in der Anwendung oder in einer nachgelagerten Abhängigkeit liegen. Wenn dagegen die Workloads gesund sind, aber DNS, Netzwerk oder ein vorgelagerter Zugang ausfallen, kann ein Edge-Failover die Erreichbarkeit verbessern.

Die ayedo Edge Cloud bildet den öffentlichen Eingang vor Anwendungen und APIs. Sie kann Kubernetes-Backends über die Edge absichern und verteilen, unabhängig davon, ob die Cluster mit ayedo Managed Kubernetes oder bei einem anderen Provider betrieben werden. Die Verfügbarkeit der Workloads muss trotzdem separat geplant und nachgewiesen werden.

4. Failover verändert Betrieb, Security und Kosten

Ein Failover verschiebt nicht nur IP-Traffic. Es verändert Lastverteilung, Fehlerbilder, Logquellen und möglicherweise die Datenpfade einer Anwendung. Das alternative Backend muss deshalb dieselben Protokolle, Zertifikatsannahmen und Request-Erwartungen erfüllen. Backend Cloaking kann dabei die interne Struktur der Cluster aus dem öffentlichen Zugriff herausnehmen: Clients kommunizieren mit der Edge, nicht direkt mit den eigentlichen Backend-Adressen.

Auch Sicherheitskontrollen müssen im Umschaltfall gelten. WAF, TLS Termination und DDoS Protection sollten nicht nur für das primäre Ziel betrachtet werden, sondern als zentrale Edge-Funktionen für den gesamten öffentlichen Pfad. Gleichzeitig kann Failover Betriebskosten erhöhen, wenn ein alternatives Backend dauerhaft vorgehalten, synchronisiert und überwacht werden muss. Ein nominelles Zweit-Backend ohne getestete Kapazität ist keine belastbare Hochverfügbarkeitsstrategie.

Die ayedo Edge Cloud nutzt eine verteilte Multi-PoP-Architektur, ein eigenes Autonomous System und ein Aktiv-Aktiv-Prinzip. Für die Planung bedeutet das: Edge-seitige Ausfallszenarien und Backend-seitige Ausfallszenarien sind getrennt zu bewerten. Erst diese Trennung zeigt, welchen Fehler das Failover tatsächlich behandelt.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt einen öffentlichen API-Service auf zwei Kubernetes-Clustern bei unterschiedlichen Providern. Cluster A ist primär, Cluster B dient als alternatives Backend. Die Edge prüft einen dedizierten, anwendungsnahen HTTP-Endpunkt und entfernt Cluster A bei wiederholtem Fehlschlag aus dem Routing. Der Traffic wird anschließend an Cluster B weitergeleitet.

Vor dem produktiven Einsatz muss geklärt sein, ob Cluster B aktuelle Daten besitzt, ausreichende Kapazität hat und dieselben Sicherheits- und Protokollanforderungen erfüllt. Ebenso braucht es einen Test für Rückschaltung und einen Mechanismus, der bei einer fehlerhaften Anwendung nicht beide Cluster gleichzeitig als gesund bewertet. Die Edge behandelt den Ausfall des Backends; die Anwendungsteams verantworten Datenkonsistenz und Workload-Betrieb.

FAQ

Was ist der Unterschied zwischen Kubernetes-Hochverfügbarkeit und Edge-Failover?

Kubernetes-Hochverfügbarkeit hält Workloads innerhalb der Compute-Infrastruktur verfügbar. Edge-Failover steuert, welches erreichbare Backend öffentlichen Traffic erhält. Beide Ebenen ergänzen sich, ersetzen einander aber nicht.

Muss das alternative Kubernetes-Backend beim selben Provider liegen?

Nein. Ein Failover-Design kann auch Cluster bei unterschiedlichen Providern einbeziehen. Entscheidend sind technische Kompatibilität, Datenversorgung, Kapazität und ein getesteter Betriebsprozess.

Wann ist ein Health Check zu oberflächlich?

Wenn er nur Netzwerkport oder Prozessstatus prüft, obwohl die Anwendung bereits keine gültigen Antworten liefert. Für öffentliche Services sollte der Check einen für den Traffic relevanten Zustand abbilden.

Fazit

Automatisches Failover ist dann belastbar, wenn die Zuständigkeiten präzise getrennt sind: Die Edge erkennt den Zustand öffentlicher Backends und steuert den Traffic, Kubernetes und die Compute-Infrastruktur sichern die Workloads und ihre Abhängigkeiten. Die ayedo Edge Cloud unterstützt diese Architektur mit Backend Health Checks und Failover für Kubernetes-Umgebungen, auch außerhalb von ayedo Managed Kubernetes. Entscheidend bleiben realistische Prüfpunkte, geeignete Alternativen und regelmäßig getestete Umschaltprozesse.