Freigeben über

Multi-Region-Bereitstellungsmodelle für Azure Kubernetes Service (AKS)

Azure Kubernetes Service (AKS) bietet eine verwaltete Kubernetes-Umgebung zum Bereitstellen, Verwalten und Skalieren von containerisierten Anwendungen. Um Ausfallsicherheit für regionale Ausfälle für Ihre Anwendungen bereitzustellen, die auf AKS ausgeführt werden, können Sie verschiedene Bereitstellungsmodelle mit mehreren Regionen implementieren. Dieser Artikel enthält eine Übersicht über diese Modelle, deren Vor- und Nachteile sowie bewährte Methoden für die Aufrechterhaltung der Anwendungsverfügbarkeit.

AKS bietet eine Reihe von Funktionen, die sowohl hohe Verfügbarkeit (HA) als auch Notfallwiederherstellung (DR) für Ihren Cluster und die Anwendungen unterstützen, die auf AKS ausgeführt werden. Weitere Informationen dazu, wie AKS Zuverlässigkeitsanforderungen unterstützt, finden Sie unter Zuverlässigkeit in AKS.

Überlegungen

Im Folgenden finden Sie einige wichtige Überlegungen bei der Implementierung von Bereitstellungsmodellen mit mehreren Regionen in AKS:

Regionale und globale Ressourcen

Regionale Ressourcen werden als Teil eines Bereitstellungsstempels in einer einzelnen Azure-Region bereitgestellt. Diese Ressourcen teilen nichts mit Ressourcen in anderen Regionen, und sie können unabhängig entfernt oder in andere Regionen repliziert werden. Weitere Informationen finden Sie unter Regionale Ressourcen.

Globale Ressourcen teilen die Lebensdauer des Systems und können global im Kontext einer Bereitstellung mit mehreren Regionen verfügbar sein. Weitere Informationen finden Sie unter Globale Ressourcen.

Globaler Lastenausgleich

Globale Lastenausgleichsdienste verteilen den Datenverkehr auf regionale Back-Ends, Clouds oder hybride lokale Dienste. Diese Dienste leiten den Endbenutzer-Datenverkehr an das nächstgelegene verfügbare Back-End weiter. Außerdem reagieren sie auf Änderungen von Zuverlässigkeit oder Leistung des Diensts, um Verfügbarkeit und Leistung zu maximieren. Die folgenden Azure-Dienste bieten einen globalen Lastenausgleich:

Bereichsdefinition

Die Anwendungsverfügbarkeit ist beim Verwalten von AKS-Clustern wichtig. Standardmäßig bietet AKS Hochverfügbarkeit, indem mehrere Knoten in einer VM-Skalierungsgruppe verwendet werden, aber diese Knoten schützen Ihr System nicht vor einem Regionsausfall. Um die Uptime zu maximieren, müssen Sie im Voraus planen, um die Geschäftskontinuität aufrechtzuerhalten und eine Notfallwiederherstellung vorzubereiten. Wenden Sie dazu die folgenden bewährten Methoden an:

  • Planen für AKS-Cluster in mehreren Regionen.
  • Weiterleiten des Datenverkehrs über mehrere Cluster mithilfe von Azure Traffic Manager.
  • Verwenden der Georeplikation für Ihre Containerimageregistrierungen.
  • Mehrere Cluster übergreifendes Planen für den Anwendungszustand.
  • Mehrere Regionen übergreifendes Replizieren des Speichers.

Implementierungen des Bereitstellungsmodells für mehrere Regionen

In der folgenden Tabelle sind die drei wichtigsten Multi-Region-Bereitstellungsmodelle in AKS zusammen mit ihren Vor- und Nachteilen zusammengefasst:

Bereitstellungsmodell Vorteile Nachteile
Aktiv/Aktiv • Keine Datenverluste oder Inkonsistenzen während eines Failovers
• Hohe Resilienz
• Bessere Nutzung von Ressourcen mit höherer Leistung		 • Komplexe Implementierung und Verwaltung
• Höhere Kosten
• Erfordert einen Lastenausgleich und eine Form des Datenverkehrsroutings
Aktiv/Passiv • Einfachere Implementierung und Verwaltung
• Geringere Kosten
• Erfordert keinen Lastenausgleich oder Datenverkehrs-Manager		 • Potenzial für Datenverluste oder Inkonsistenzen während eines Failovers
• Längere Wiederherstellungszeit und Downtime
• Keine vollständige Nutzung von Ressourcen
Passiv-Kalt • Niedrigste Kosten
• Erfordert weder Synchronisierung noch Replikation, Lastenausgleich oder Datenverkehrs-Manager
• Geeignet für nicht kritische Workloads mit niedriger Priorität		 • Hohes Risiko von Datenverlust oder Inkonsistenz während eines Failovers
• Längste Wiederherstellungszeit und Downtime
• Erfordert manuelle Eingriffe zum Aktivieren des Clusters und Auslösen der Sicherung

Aktiv-Aktiv-Bereitstellungsmodell für Hochverfügbarkeit

Im Aktiv-Aktiv-Bereitstellungsmodell für Hochverfügbarkeit (HA) verwenden Sie zwei unabhängige AKS-Cluster, die in zwei verschiedenen Azure-Regionen (in der Regel gekoppelte Regionen wie „Kanada, Mitte“ und „Kanada, Osten“ oder „USA, Osten 2“ und „USA, Mitte“) bereitgestellt werden und aktiv den Datenverkehr verarbeiten.

Mit dieser Beispielarchitektur:

  • Sie stellen zwei AKS-Cluster in separaten Azure-Regionen bereit.
  • Im normalen Betrieb wird der Netzwerkdatenverkehr zwischen beiden Regionen weitergeleitet. Wenn eine Region nicht mehr verfügbar ist, wird der Datenverkehr automatisch an die nächstgelegene Region der Benutzer*innen weitergeleitet, die die Anforderung gesendet haben.
  • Für jede regionale AKS-Instanz wird ein Hub-Spoke-Paar bereitgestellt. Azure Firewall Manager-Richtlinien verwalten die Firewallregeln in den Regionen.
  • Azure Key Vault wird in jeder Region bereitgestellt, um Geheimnisse und Schlüssel zu speichern.
  • Azure Front Door verwaltet den Lastenausgleich und leitet den Datenverkehr an eine regionale Instanz von Azure Application Gateway weiter, die sich vor jedem AKS-Cluster befindet.
  • Regionale Log Analytics-Instanzen speichern regionale Netzwerkmetriken und Diagnoseprotokolle.
  • Die Containerimages für die Workload werden in einer verwalteten Containerregistrierung gespeichert. Für alle Kubernetes-Instanzen im Cluster wird eine einzelne Azure Container Registry-Instanz verwendet. Durch eine Aktivierung der Georeplikation für Azure Container Registry werden Images automatisch in die ausgewählten Azure-Regionen repliziert. So kann auch dann noch auf die Images zugegriffen werden, wenn es in einer Region zu einem Ausfall kommt.

Führen Sie die folgenden Schritte aus, um ein Aktiv-Aktiv-Bereitstellungsmodell in AKS zu erstellen:

  1. Erstellen Sie zwei identische Bereitstellungen in zwei unterschiedlichen Azure-Regionen.

  2. Erstellen Sie zwei Instanzen Ihrer Web-App.

  3. Erstellen Sie ein Azure Front Door-Profil mit den folgenden Ressourcen:

    • Ein Endpunkt.
    • Zwei Ursprungsgruppen mit jeweils einer Priorität von 1.
    • Eine Route.

  4. Beschränken Sie den Netzwerkdatenverkehr zu den Web-Apps nur von der Azure Front Door-Instanz. 5. Konfigurieren Sie alle anderen Azure-Back-End-Dienste, z. B. Datenbanken, Speicherkonten und Authentifizierungsanbieter.

  5. Stellen Sie Code für beide Web-Apps mit Continuous Deployment bereit.

Weitere Informationen finden Sie in der Übersicht über die empfohlene Aktiv-Aktiv-Lösung mit Hochverfügbarkeit für AKS.

Aktiv-Passiv-Bereitstellungsmodell für die Notfallwiederherstellung

Im Aktiv-Passiv-Bereitstellungsmodell für die Notfallwiederherstellung (DR) verwenden Sie zwei unabhängige AKS-Cluster, die in zwei verschiedenen Azure-Regionen (in der Regel gekoppelte Regionen wie „Kanada, Mitte“ und „Kanada, Osten“ oder „USA, Osten 2“ und „USA, Mitte“) bereitgestellt werden und aktiv den Datenverkehr verarbeiten. Zu jedem Zeitpunkt verarbeitet immer nur einer der Cluster aktiv den Datenverkehr. Der andere Cluster enthält die gleichen Konfigurations- und Anwendungsdaten wie der aktive Cluster, akzeptiert jedoch keinen Datenverkehr, es sei denn, dieser wird von einem Datenverkehrs-Manager weitergeleitet.

Mit dieser Beispielarchitektur:

  • Sie stellen zwei AKS-Cluster in separaten Azure-Regionen bereit.
  • Im normalen Betrieb wird der Netzwerkdatenverkehr an den primären AKS-Cluster weitergeleitet, den Sie in der Azure Front Door-Konfiguration festlegen.
    • Die Priorität muss auf einen Wert zwischen 1 und 5 festgelegt werden, wobei 1 die höchste 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 (bei einem Notfall), wird der Datenverkehr automatisch an die nächste Region weitergeleitet, die in Azure Front Door ausgewählt ist.
    • Der gesamte Datenverkehr muss den Azure Front Door-Datenverkehrs-Manager durchlaufen, damit dieses System funktioniert.
  • Azure Front Door leitet Datenverkehr an die Azure Application Gateway-Instanz in der primären Region weiter (der Cluster muss mit Priorität 1 gekennzeichnet sein). Wenn diese Region ausfällt, leitet der Dienst den Datenverkehr an den nächsten Cluster in der Prioritätsliste um.
    • Die Regeln stammen aus Azure Front Door.
  • Für jede regionale AKS-Instanz wird ein Hub-Spoke-Paar bereitgestellt. Azure Firewall Manager-Richtlinien verwalten die Firewallregeln in den Regionen.
  • Azure Key Vault wird in jeder Region bereitgestellt, um Geheimnisse und Schlüssel zu speichern.
  • Regionale Log Analytics-Instanzen speichern regionale Netzwerkmetriken und Diagnoseprotokolle.
  • Die Containerimages für die Workload werden in einer verwalteten Containerregistrierung gespeichert. Für alle Kubernetes-Instanzen im Cluster wird eine einzelne Azure Container Registry-Instanz verwendet. Durch eine Aktivierung der Georeplikation für Azure Container Registry werden Images automatisch in die ausgewählten Azure-Regionen repliziert. So kann auch dann noch auf die Images zugegriffen werden, wenn es in einer Region zu einem Ausfall kommt.

Führen Sie die folgenden Schritte aus, um ein Aktiv-Passiv-Bereitstellungsmodell in AKS zu erstellen:

  1. Erstellen Sie zwei identische Bereitstellungen in zwei unterschiedlichen Azure-Regionen.

  2. Konfigurieren Sie Regeln für die automatische Skalierung für die sekundäre Anwendung, damit sie auf die gleiche Instanzanzahl wie die primäre Anwendung skaliert wird, wenn die primäre Region inaktiv wird. Im inaktiven Zustand ist keine Skalierung erforderlich. Dies trägt dazu bei, die Kosten zu senken.

  3. Erstellen Sie zwei Instanzen Ihrer Webanwendung mit einer Instanz in jedem Cluster.

  4. Erstellen Sie ein Azure Front Door-Profil mit den folgenden Ressourcen:

    • Ein Endpunkt.
    • Einer Ursprungsgruppe mit der Priorität 1 für die primäre Region.
    • Einer zweiten Ursprungsgruppe mit einer Priorität von 2 für die sekundäre Region.
    • Eine Route.

  5. Beschränken Sie den Netzwerkdatenverkehr an die Webanwendungen auf ausschließlich die Azure Front Door-Instanz.

  6. Konfigurieren Sie alle anderen Azure-Back-End-Dienste, z. B. Datenbanken, Speicherkonten und Authentifizierungsanbieter.

  7. Stellen Sie Code für beide Webanwendungen mit Continuous Deployment bereit.

Weitere Informationen finden Sie in der Übersicht über die empfohlene Aktiv-Passiv-Lösung für die Notfallwiederherstellung für AKS.

Passiv-Kalt-Bereitstellungsmodell mit Failover

Das Passiv-Kalt-Bereitstellungsmodell mit Failover wird auf die gleiche Weise wie das Aktiv-Passiv-Bereitstellungsmodell für die Notfallwiederherstellung konfiguriert, nur dass die Cluster inaktiv bleiben, bis Benutzer*innen sie im Fall eines Notfalls aktivieren. Dieser Ansatz wird hier nicht behandelt, da er eine ähnliche Konfiguration wie der Aktiv-Passiv-Ansatz erfordert, aber mit dem Zusatzaufwand des manuellen Eingriffs, um den Cluster zu aktivieren und eine Sicherung auszulösen.

Mit dieser Beispielarchitektur:

  • Sie erstellen zwei AKS-Cluster, vorzugsweise in verschiedenen Regionen oder Zonen, um die Resilienz zu verbessern.
  • Wenn Sie ein Failover ausführen müssen, aktivieren Sie die Bereitstellung, um den Datenverkehrsflow zu übernehmen.
  • Wenn der primäre passive Cluster ausfällt, müssen Sie den „kalten“ Cluster manuell aktivieren, damit er den Datenverkehrsflow übernimmt.
  • Dies muss entweder jedes Mal manuell oder durch ein bestimmtes Ereignisses ausgelöst werden, das von Ihnen angegeben wird.
  • Azure Key Vault wird in jeder Region bereitgestellt, um Geheimnisse und Schlüssel zu speichern.
  • Regionale Log Analytics-Instanzen speichern regionale Netzwerkmetriken und Diagnoseprotokolle für jeden Cluster.

Führen Sie die folgenden Schritte aus, um ein Passiv-Kalt-Bereitstellungsmodell mit Failover in AKS zu erstellen:

  1. Erstellen Sie zwei identische Bereitstellungen in unterschiedlichen Zonen/Regionen.
  2. Konfigurieren Sie Regeln für die automatische Skalierung für die sekundäre Anwendung, damit sie auf die gleiche Instanzanzahl wie die primäre Anwendung skaliert wird, wenn die primäre Region inaktiv wird. Im inaktiven Zustand ist keine Skalierung erforderlich, wodurch die Kosten reduziert werden.
  3. Erstellen Sie zwei Instanzen Ihrer Webanwendung mit einer Instanz in jedem Cluster.
  4. Konfigurieren Sie alle anderen Azure-Back-End-Dienste, z. B. Datenbanken, Speicherkonten und Authentifizierungsanbieter.
  5. Legen Sie eine Bedingung fest, bei der der „kalte“ Cluster ausgelöst werden soll. Sie können bei Bedarf einen Lastenausgleich verwenden.

Weitere Informationen finden Sie in der Übersicht über die empfohlenen Passiv-Kalt-Lösung mit Failover für AKS.

Weitere Informationen finden Sie in den folgenden Artikeln: