Ü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 (nicht aktiv bedienter Datenverkehr) enthält die gleichen Konfigurations- und Anwendungsdaten wie der primäre Cluster, akzeptiert jedoch keinen Datenverkehr, es sei denn, er wird von Azure Front Door Datenverkehrs-Manager 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 betreiben müssen, die in beiden Regionen bereitgestellt werden, beispielsweise für horizontale Skalierung, empfehlen wir, eine Aktiv-Aktiv-Lösung in Betracht zu ziehen, da eine Aktiv-Passiv-Lösung mit zusätzlicher Latenz verbunden ist.

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 Routing des Datenverkehrs.

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.

Container-Registry: Die Container-Images für die Workload werden in einer verwalteten Container-Registry 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 davon nicht verfügbar ist, wird der Datenverkehr auf die verbleibenden Replikate umgeleitet. Die Kubernetes-Replikatgruppe (ReplicaSet) versucht, den Betrieb der angegebenen Anzahl von Replikaten aufrechtzuerhalten. Wenn eine Instanz ausfällt, sollte eine neue Instanz erstellt werden. Liveness-Probes können den Zustand der Anwendung oder des Prozesses prüfen, der in dem Pod ausgeführt wird. Wenn der Pod nicht reagiert, entfernt die Liveness-Probe den Pod, was das ReplicaSet dazu zwingt, eine neue Instanz zu erstellen.

Weitere Informationen finden Sie unter Kubernetes: ReplicaSet.

Anwendungs-Pods (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 den Horizontal Pod Autoscaler, um die Anzahl der Pod-Replikate 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. Verwenden Sie Azure Verfügbarkeitszonen, um Ihre AKS-Knoten in dieser aktiv-passiven Lösung vor einem einzigen regionalen Fehler zu schützen. Verfügbarkeitszonen stellen sicher, dass AKS-Knoten in jeder Verfügbarkeitszone physisch von denen getrennt werden, 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 innerhalb von AKS vorhanden sind, um eine gesamte Bereitstellungsregion zu Testzwecken zu erfassen, können Sie Azure Chaos Studio Arbeitsbereiche verwenden, um einen Ausfall der Verfügbarkeitszone für die Knotenpools Ihres Clusters zu simulieren.

Nächste Schritte

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

  • Zuletzt aktualisiert um