Teilen über

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

  • Artikel

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 Passiv-Kalt-Lö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, wenn die Anwendung benötigt wird.

Hinweis

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

Übersicht über Passiv-Kalt-Lösung

Bei diesem Ansatz haben wir zwei unabhängige AKS-Cluster, die in zwei Azure-Regionen bereitgestellt werden. Wenn die Anwendung benötigt wird, aktivieren wir den passiven Cluster, um Datenverkehr zu empfangen. Wenn der passive Cluster ausfällt, müssen wir den „kalten“ Cluster manuell aktivieren, damit er den Datenverkehrsfluss übernimmt. Wir können diese Bedingung jedes Mal über eine manuelle Eingabe festlegen oder ein bestimmtes Ereignis angeben.

Szenarien und Konfigurationen

Diese Lösung wird am besten als „Use as needed“-Workload (Einsatz nach Bedarf) implementiert, was für Szenarien nützlich ist, für die Workloads zu bestimmten Zeiten oder nach Bedarf ausgeführt werden müssen. Beispiele für Anwendungsfälle für einen Passiv-Kalt-Ansatz sind:

  • Ein Fertigungsunternehmen, das eine komplexe und ressourcenintensive Simulation für ein großes Dataset ausführen muss. In diesem Fall befindet sich der passive Cluster in einer Cloudregion, die leistungsstarke Computing- und Speicherdienste bietet. Der passive Cluster wird nur verwendet, wenn die Simulation vom Benutzer bzw.von der Benutzerin oder von einem Zeitplan ausgelöst wird. Wenn der Cluster beim Auslösen nicht funktioniert, kann der kalte Cluster als Sicherung verwendet werden, und die Workload kann stattdessen in ihm ausgeführt werden.
  • Eine Regierungsbehörde, die eine Sicherung ihrer kritischen Systeme und Daten im Falle eines Cyberangriffs oder einer Naturkatastrophe verwalten muss. In diesem Fall befindet sich der passive Cluster an einem sicheren und isolierten Ort, der nicht für die Öffentlichkeit zugänglich ist.

Komponenten

Die Passiv-Kalt-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. Wenn die App benötigt wird, wird der passive Cluster aktiviert, um Netzwerkdatenverkehr zu empfangen.

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.

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.

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 der passive Cluster aufgrund eines Problems in seiner spezifischen Azure-Region nicht ordnungsgemäß funktioniert, können Sie den kalten Cluster aktivieren und den gesamten Datenverkehr an die Region dieses Clusters umleiten. Sie können diesen Prozess verwenden, solange der passive Cluster deaktiviert ist, bis er wieder funktioniert. Es kann einige Minuten dauern, bis der kalte Cluster online ist, da er deaktiviert wurde und den Einrichtungsprozess abschließen muss. Dieser Ansatz ist nicht ideal für zeitkritische Anwendungen. In diesem Fall wird empfohlen, ein Aktiv-Aktiv-Failover in Betracht zu ziehen.

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: