Übersicht über eine Aktiv-Passiv-Notfallwiederherstellungslösung für Azure Kubernetes Service (AKS)

Wenn Sie eine Anwendung in Azure Kubernetes Service (AKS) erstellen und während der Ressourcenerstellung eine Azure-Region auswählen, handelt es sich um eine App mit einer einzelnen Region. Wenn die Region während eines Notfalls nicht mehr verfügbar ist, ist auch Ihre Anwendung nicht mehr verfügbar. Wenn Sie eine identische Bereitstellung in einer sekundären Azure-Region erstellen, ist Ihre Anwendung weniger anfällig für einen Notfall in einer einzelnen Region. Dadurch wird die Geschäftskontinuität gewährleistet, und durch die Datenreplikation zwischen den Regionen können Sie Ihren letzten Anwendungsstatus wiederherstellen.

In diesem Leitfaden wird eine Aktiv-Passiv-Notfallwiederherstellungslösung für AKS beschrieben. In dieser Lösung stellen wir zwei unabhängige und identische AKS-Cluster in zwei gekoppelten Azure-Regionen bereit, wobei nur ein Cluster Datenverkehr aktiv verarbeitet.

Hinweis

Die folgende Praxis wurde intern und in Verbindung mit unseren Microsoft-Partnern überprüft.

Übersicht über die Aktiv-Passiv-Lösung

Bei diesem Notfallwiederherstellungsansatz haben wir zwei unabhängige AKS-Cluster, die in zwei Azure-Regionen bereitgestellt werden. Allerdings verarbeitet jeweils nur einer der Cluster aktiv Datenverkehr. Der sekundäre Cluster (der nicht aktiv Datenverkehr verarbeitet) enthält die gleichen Konfigurations- und Anwendungsdaten wie der primäre Cluster, akzeptiert jedoch keinen Datenverkehr, es sei denn, er wird vom Azure Front Door-Datenverkehrsmanager dorthin geleitet.

Szenarien und Konfigurationen

Diese Lösung ist am besten geeignet, wenn Anwendungen gehostet werden, die auf Ressourcen wie Datenbanken angewiesen sind, die den Datenverkehr in einer Region aktiv verarbeiten. In Szenarien, in denen Sie zustandslose Anwendungen hosten müssen, die in beiden Regionen bereitgestellt werden, z. B. horizontale Skalierung, empfehlen wir, eine Aktiv-Aktiv-Lösung, da eine Aktiv-Passiv-Lösung zusätzliche Latenz bedeutet.

Komponenten

Die Aktiv-Passiv-Notfallwiederherstellungslösung verwendet viele Azure-Dienste. Die Beispielarchitektur verwendet die folgenden Komponenten:

Mehrere Cluster und Regionen: Sie stellen mehrere AKS-Cluster bereit, jeweils in einer separaten Azure-Region. Im normalen Betrieb wird Netzwerkdatenverkehr an den primären AKS-Cluster weitergeleitet, der in der Azure Front Door-Konfiguration festgelegt ist.

Konfigurierte Clusterpriorisierung: Sie legen für jeden Cluster eine Priorisierungsebene zwischen 1 und 5 fest (wobei 1 die höchste Priorität und 5 die niedrigste Priorität ist). Sie können mehrere Cluster auf dieselbe Prioritätsebene festlegen und eine Gewichtung für die einzelnen Cluster angeben. Wenn der primäre Cluster nicht verfügbar ist, wird der Datenverkehr automatisch an die nächste Region weitergeleitet, die in Azure Front Door ausgewählt ist. Der gesamte Datenverkehr muss Azure Front Door durchlaufen, damit dieses System funktioniert.

Azure Front Door: Azure Front Door führt einen Lastenausgleich aus und leitet Datenverkehr an die Azure Application Gateway-Instanz in der primären Region weiter (Cluster muss mit Priorität 1 gekennzeichnet sein). Falls diese Region ausfällt, leitet der Dienst den Datenverkehr an den nächsten Cluster in der Prioritätsliste um.

Weitere Informationen finden Sie unter Prioritätsbasiertes Datenverkehrsrouting.

Hub-Spoke-Paar: Für jede regionale AKS-Instanz wird ein Hub-Spoke-Paar bereitgestellt. Azure Firewall Manager-Richtlinien verwalten die Firewallregeln in jeder Region.

Key Vault: Sie stellen einen Azure Key Vault in jeder Region bereit, um Geheimnisse und Schlüssel zu speichern.

Log Analytics: Regionale Log Analytics-Instanzen speichern regionale Netzwerkmetriken und Diagnoseprotokolle. Eine freigegebene Instanz speichert Metriken und Diagnoseprotokolle für alle AKS-Instanzen.

Containerregistrierung Die Containerimages für die Workload werden in einer verwalteten Containerregistrierung gespeichert. Mit dieser Lösung wird eine einzelne Azure Container Registry-Instanz für alle Kubernetes-Instanzen im Cluster verwendet. Durch eine Aktivierung der Georeplikation für Azure Container Registry können Sie Images in die ausgewählten Azure-Regionen replizieren. So kann auch dann noch auf die Images zugegriffen werden, wenn es in einer Region zu einem Ausfall kommt.

Failoverprozess

Wenn ein Dienst oder eine Dienstkomponente in einer Region ausfällt, sollte der Datenverkehr an eine Region umgeleitet werden, in der dieser Dienst verfügbar ist. Eine Architektur mit mehreren Regionen umfasst viele verschiedene Fehlerstellen. In diesem Abschnitt behandeln wir die möglichen Fehlerpunkte.

Anwendungspods (regional)

Ein Kubernetes-Bereitstellungsobjekt erstellt mehrere Replikate eines Pods (ReplicaSet). Wenn eines der Podreplikate nicht verfügbar ist, wird der Datenverkehr zwischen den verbleibenden Replikaten weitergeleitet. Die Kubernetes-Replikatgruppe (ReplicaSet) versucht, den Betrieb der angegebenen Anzahl von Replikaten aufrechtzuerhalten. Wenn eine Instanz ausfällt, sollte eine neue Instanz erstellt werden. Anhand von Livetests kann der Zustand von Anwendungen oder Prozessen überprüft werden, die im Pod ausgeführt werden. Wenn der Pod nicht antwortet, entfernt der Livetest den Pod, wodurch das ReplicaSet zum Erstellen einer neuen Instanz gezwungen wird.

Weitere Informationen finden Sie unter Kubernetes: ReplicaSet.

Anwendungspods (global)

Wenn eine ganze Region ausfällt, stehen die Pods im Cluster nicht mehr zur Verarbeitung von Anforderungen zur Verfügung. In diesem Fall leitet die Azure Front Door-Instanz den gesamten Datenverkehr an die verbleibenden fehlerfreien Regionen weiter. Die Kubernetes-Cluster und -Pods in diesen Regionen setzen die Verarbeitung von Anforderungen fort. Beachten Sie den folgenden Leitfaden, um erhöhten Datenverkehr und Anforderungen an den verbleibenden Cluster auszugleichen:

• Stellen Sie sicher, dass die Netzwerk- und Rechenressourcen richtig dimensioniert sind, um einen plötzlichen Anstieg des Datenverkehrs aufgrund eines Regionsfailovers aufzufangen. Stellen Sie beispielsweise bei Verwendung von Azure Container Network Interface (CNI) sicher, dass das verwendete Subnetz alle Pod-IP-Adressen bei einer hohen Datenverkehrslast unterstützen kann.
• Verwenden Sie die horizontale automatische Podskalierung, um die Anzahl von Podreplikaten zu erhöhen und so die gestiegene regionale Nachfrage zu kompensieren.
• Verwenden Sie die Autoskalierung für AKS-Cluster, um die Anzahl von Kubernetes-Instanzknoten zu erhöhen und so die gestiegene regionale Nachfrage zu kompensieren.

Kubernetes-Knotenpools (regional)

Gelegentlich kann es zu lokalen Ausfällen von Computeressourcen kommen, z. B. wenn die Stromversorgung eines einzelnen Racks mit Azure-Servern ausfällt. Nutzen Sie Azure-Verfügbarkeitszonen, damit Ihre AKS-Knoten nicht zu einem Single Point of Failure (SPOF) für eine Region werden. Verfügbarkeitszonen stellen sicher, dass AKS-Knoten in jeder Verfügbarkeitszone physisch von denen getrennt sind, die in einer anderen Verfügbarkeitszone definiert sind.

Kubernetes-Knotenpools (global)

Bei einem Ausfall einer vollständigen Region leitet Azure Front Door den Datenverkehr an die verbleibenden fehlerfreien Regionen weiter. Stellen Sie auch hier sicher, den erhöhten Datenverkehr und die Anforderungen an den verbleibenden Cluster zu kompensieren.

Teststrategie für Failover

Obwohl derzeit keine Mechanismen in AKS zur Verfügung stehen, um eine gesamte Bereitstellungsregion für Testzwecke ausfallen zu lassen, bietet Azure Chaos Studio die Möglichkeit, ein Chaosexperiment in Ihrem Cluster zu erstellen.

Nächste Schritte

Wenn Sie eine andere Lösung in Betracht ziehen, lesen Sie die folgenden Artikel:

• Übersicht über eine Aktiv-Aktiv-Hochverfügbarkeitslösung für Azure Kubernetes Service (AKS)
• Übersicht über eine Passiv-Kalt-Notfalllösung für Azure Kubernetes Service (AKS)