Kubernetes-Failover für Ingress und API Server planen

TL;DR

Ein belastbares Kubernetes Ingress Failover beginnt nicht beim DNS, sondern bei klar definierten Fehlerbildern und aussagekräftigen Backend Health Checks. Aktiv-Aktiv-Architekturen verkürzen Ausfallzeiten, lösen aber weder fehlerhafte Anwendungen noch unklare Zuständigkeiten. Die Edge muss Status, Routing und Failover unabhängig von einzelnen Clustern bewerten.

Einleitung

Kubernetes-Hochverfügbarkeit scheitert häufig an einer falschen Annahme: Wenn mehrere Cluster existieren, ist der Dienst automatisch ausfallsicher. Tatsächlich kann ein Cluster erreichbar sein, während der Ingress keine Anfragen mehr verarbeitet, ein Netzwerkpfad gestört ist oder der Kubernetes API Server nicht antwortet. Für Kubernetes Ingress Failover müssen deshalb drei Ebenen getrennt betrachtet werden: der öffentliche Zugang, die Erreichbarkeit des Backends und die Funktionsfähigkeit des Dienstes. Erst daraus lässt sich ableiten, wann Traffic umgelenkt werden darf und wann ein Failover lediglich einen bereits bestehenden Fehler weiterverteilt.

1. Fehlerbilder vor dem Failover definieren

Ein Cluster-Ausfall ist nur eines von mehreren relevanten Szenarien. Ein kompletter Verlust eines Clusters ist vergleichsweise eindeutig: Der externe Endpunkt antwortet nicht, und ein alternatives Backend kann den Traffic übernehmen. Schwieriger sind partielle Fehler. Dazu gehören nicht erreichbare Nodes, ein ausgefallener Ingress, blockierte Netzwerkpfade oder ein Backend, das TCP-Verbindungen annimmt, aber HTTP-Anfragen nicht korrekt verarbeitet.

Für die Planung ist deshalb eine Fehler-Matrix sinnvoll. Sie ordnet jedem Fehlerbild eine Erkennung, eine Aktion und eine Rückkehrstrategie zu. Ein Health Check auf Portebene erkennt beispielsweise keine fehlerhafte Anwendungsschicht. Ein HTTP-Check kann dagegen einen definierten Pfad und Statuscode prüfen. Für den Kubernetes API Server gelten andere Kriterien als für eine veröffentlichte Anwendung: Er muss über den vorgesehenen Endpoint erreichbar sein und eine für den Betriebsfall ausreichende Antwort liefern.

Diese Unterscheidung verhindert, dass ein scheinbar gesundes, aber funktionsloses Backend weiterhin Traffic erhält.

2. Backend Health Checks müssen zum Dienst passen

Backend Health Checks sind kein rein technisches Detail, sondern eine Routing-Entscheidung mit direkten Betriebsfolgen. Für einen Ingress sollte der Check möglichst die relevante Anwendungskette abbilden: TLS beziehungsweise HTTP-Erreichbarkeit, Routing zum Service und ein definierter Health-Endpunkt. Dabei darf der Prüfpfad nicht von einer Funktion abhängen, die bei hoher Last absichtlich deaktiviert wird. Ebenso sollten Checks keine schreibenden Operationen auslösen.

Bei API-Servern steht dagegen die Erreichbarkeit des Control-Plane-Endpunkts im Vordergrund. Ein Check muss zwischen temporärer Überlastung, Netzwerkfehler und dauerhaftem Ausfall unterscheiden können. Zu aggressive Schwellenwerte erzeugen unnötiges Failover und Flapping; zu großzügige Werte verlängern die Störung.

Die ayedo Edge Cloud kann Backends über Health Checks überwachen und bei Ausfall Failover auslösen. Entscheidend bleibt die korrekte Definition des Prüfmodells: Die Edge bewertet die Erreichbarkeit des veröffentlichten Backends, nicht automatisch den Zustand aller Kubernetes-Ressourcen dahinter.

3. Aktiv-Aktiv mit mehreren Clustern entwerfen

Eine Aktiv-Aktiv-Architektur verteilt Anfragen gleichzeitig auf mehrere gesunde Backends. Das reduziert die Abhängigkeit von einem einzelnen Cluster und erlaubt, Kapazität sowie Wartungsarbeiten über mehrere Standorte oder Provider zu verteilen. Gleichzeitig steigen die Anforderungen an Zustandsdaten, Datenbankzugriffe, Sessions und konsistente Konfigurationen. Stateless HTTP-Services eignen sich typischerweise besser als zustandsgebundene Anwendungen.

Bei Kubernetes Ingress Failover muss außerdem geklärt sein, ob beide Cluster denselben Hostnamen, dieselben Zertifikatsannahmen und kompatible API-Verträge bedienen. Andernfalls kann ein technisch erreichbares Backend fachlich ungeeignete Antworten liefern. Für den API Server ist die Situation noch sensibler: Mehrere Cluster sind keine gemeinsame Control Plane. Jeder Endpoint repräsentiert einen eigenen Cluster mit eigener Ressourcensicht und eigenen Berechtigungen.

Die Edge Cloud kann mehrere Backends providerunabhängig veröffentlichen und zwischen ihnen verteilen. Aktiv-Aktiv entsteht jedoch erst durch die Kombination aus Edge-Routing, kompatiblen Workloads und einem konsistenten Betriebsmodell.

4. Failover braucht Rückfall- und Betriebsregeln

Failover endet nicht mit der Umschaltung. Sobald ein Backend wieder erreichbar ist, muss geregelt sein, wann es erneut Traffic erhält. Ein sofortiger Rückfall kann eine instabile Umgebung erneut belasten. Sinnvoll sind daher getrennte Kriterien für Ausfall und Wiederaufnahme, ergänzt durch Beobachtung der Traffic- und Usage-Statistiken. Diese zeigen, ob die Umschaltung tatsächlich den erwarteten Entlastungseffekt erzielt.

Auch die Fehlerdomäne der Edge ist relevant. Wenn DNS, Routing und Backendzugang an dieselbe Infrastruktur gekoppelt sind, kann ein einzelner Ausfall mehrere Funktionen gleichzeitig beeinträchtigen. Anycast DNS und Multi-Provider-DNS adressieren unterschiedliche Teile dieses Risikos; sie ersetzen aber keine gesunden Backends. Die ayedo Edge Cloud verbindet Anycast-basiertes Layer-4- und Layer-7-Loadbalancing mit Backend Health Checks, Failover und einer verteilten Aktiv-Aktiv-Architektur. Dadurch liegt die Entscheidung über den öffentlichen Traffic-Eingang vor den Clustern und kann unabhängig von ayedo Managed Kubernetes genutzt werden.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt einen Ingress in zwei Kubernetes-Clustern bei unterschiedlichen Providern. Beide Backends sind zunächst aktiv. Der Health Check prüft einen dedizierten HTTP-Endpunkt, der zentrale Abhängigkeiten berücksichtigt, aber keine schreibende Aktion ausführt.

Fällt ein Cluster vollständig aus, entfernt die Edge das Backend aus der Verteilung. Ist nur der Netzwerkpfad zu einem Cluster gestört, führt dasselbe Verhalten zu einer kontrollierten Umschaltung. Antwortet der Ingress zwar, liefert die Anwendung aber Fehler, muss der HTTP-Check diesen Zustand erkennen. Beim API Server wird ein separater Backend-Pool verwendet, weil seine Erreichbarkeit und Betriebslogik nicht mit dem Ingress identisch sind. Nach der Wiederherstellung bleibt das Backend zunächst außerhalb des aktiven Routings und wird erst nach stabilen Checks wieder aufgenommen.

FAQ

Ist DNS-Failover allein ausreichend?

Nein. DNS kann Clients zu einem anderen Endpoint lenken, erkennt aber nicht zuverlässig jede Anwendungsschichtstörung. Health Checks und Routing an der Edge ermöglichen eine kontrolliertere Reaktion.

Muss Kubernetes Ingress Failover immer Aktiv-Aktiv sein?

Nein. Aktiv-Passiv kann für zustandsbehaftete Systeme einfacher sein. Aktiv-Aktiv reduziert jedoch ungenutzte Kapazität und eignet sich für kompatible, ausreichend entkoppelte Workloads.

Sollte der API Server wie ein normaler Ingress behandelt werden?

Nein. Der API Server ist ein Control-Plane-Endpunkt mit eigener Sicherheits- und Betriebslogik. Health Checks, Zugriffsregeln und Failover müssen separat geplant werden.

Fazit

Kubernetes-Failover ist eine Frage des Fehler- und Zustandsmodells, nicht nur der Anzahl vorhandener Cluster. Backend Health Checks müssen zum jeweiligen Dienst passen, Failover-Regeln müssen Netzwerk- und Anwendungsausfälle unterscheiden, und Aktiv-Aktiv setzt kompatible Betriebsprozesse voraus. Eine Edge-Plattform wie die ayedo Edge Cloud schafft dafür eine providerunabhängige Routing- und Schutzebene vor Ingresses und API-Servern, ohne Edge und Compute miteinander zu vermischen.