Best Practices für Geschäftskontinuität und Notfallwiederherstellung in Azure Kubernetes Service (AKS)
Bei der Verwaltung von Clustern in Azure Kubernetes Service (AKS) ist die Betriebsbereitschaft Ihrer Anwendungen von größter Bedeutung. Standardmäßig bietet AKS durch die Verwendung mehrerer Knoten pro VMSS-Instanz (Virtual Machine Scale Sets) Hochverfügbarkeit. Diese mehreren Knoten bieten allerdings keinen Schutz Ihres Systems beim Ausfall einer ganzen Region. Um die Betriebszeit zu maximieren, planen Sie voraus, um die Geschäftskontinuität beizubehalten und die Notfallwiederherstellung vorzubereiten.
Thema dieses Artikels sind Planungen zur Geschäftskontinuität und Notfallwiederherstellung in AKS-Cluster. Folgendes wird vermittelt:
- 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.
Planen für die Bereitstellung in mehreren Regionen
Bewährte Methode
Wenn Sie mehrere AKS-Cluster bereitstellen, wählen Sie Regionen aus, in denen AKS verfügbar ist. Verwenden Sie Regionspaare.
Ein AKS-Cluster wird in einer einzelnen Region bereitgestellt. Um für Schutz Ihres Systems beim Ausfall dieser Region zu sorgen, stellen Sie Ihre Anwendung in mehreren AKS-Clustern in verschiedenen Regionen bereit. Beachten Sie bei der Planung des Bereitstellungsorts für Ihren AKS-Cluster Folgendes:
Verfügbarkeit der AKS-Regionen
- Wählen Sie Regionen in der Nähe Ihrer Benutzer aus.
- AKS wird fortlaufend auf neue Regionen ausgeweitet.
-
- Wählen Sie für den geografischen Bereich zwei miteinander gekoppelte Regionen aus.
- AKS-Plattform-Updates (geplante Wartungen) werden nach einer Verzögerung von mindestens 24 Stunden zwischen gekoppelten Regionen serialisiert.
- Der Wiederherstellungsaufwand für gekoppelte Regionen wird bei Bedarf priorisiert.
Dienstverfügbarkeit
- Entscheiden Sie, ob Ihre Regionspaare heiß/heiß, heiß/warm oder heiß/kalt sein sollen.
- Möchten Sie beide Regionen gleichzeitig betreiben, sodass eine Region sofort zur Verarbeitung des Datenverkehrs bereit ist? oder
- Möchten Sie, dass eine Region eine gewisse Vorlaufzeit hat, bis sie zur Verarbeitung des Datenverkehrs bereit ist?
AKS-Regionsverfügbarkeit und Regionspaare sollten zusammen geplant werden. Stellen Sie Ihre AKS-Cluster in Regionspaaren bereit, die für die gemeinsame Verwaltung der Notfallwiederherstellung in den Regionen konzipiert sind. Ein Beispiel: AKS ist in den Regionen USA, Osten und USA, Westen verfügbar. Diese Regionen sind gekoppelt. Wählen Sie diese beiden Regionen aus, wenn Sie Ihre Strategie für Geschäftskontinuität und Notfallwiederherstellung von AKS entwickeln.
Wenn Sie Ihre Anwendung bereitstellen, fügen Sie auch Ihrer CI/CD-Pipeline einen zusätzlichen Schritt hinzu, um die Bereitstellung in diesen AKS-Clustern zu ermöglichen. Durch das Aktualisieren der Bereitstellungspipelines wird verhindert, dass Anwendungen nur in einer Ihrer Regionen und nur einem Ihrer AKS-Cluster bereitgestellt werden. In diesem Szenario erhält Datenverkehr von Kunden, der an eine sekundäre Region gesendet wird, nicht die neusten Codeupdates.
Weiterleiten von Datenverkehr mit Azure Traffic Manager
Bewährte Methode
Um optimale Leistungs- und Redundanzwerte zu erzielen, leiten Sie den gesamten Anwendungsdatenverkehr über Traffic Manager an Ihren AKS-Cluster.
Wenn Sie mehrere AKS-Cluster in verschiedenen Regionen bereitgestellt haben, steuern Sie den Datenverkehrsfluss zu den in jedem Cluster ausgeführten Anwendungen mit Traffic Manager. Azure Traffic Manager ist ein DNS-basierter Lastenausgleichsdienst, der Datenverkehr auf mehrere Regionen verteilen kann. Leiten Sie Benutzerdatenverkehr mit Traffic Manager basierend auf der Antwortzeit des Clusters oder der Priorität weiter.
Wenn Sie einen einzelnen AKS-Cluster haben, stellen Sie in der Regel eine Verbindung mit der Dienst-IP-Adresse oder dem DNS-Namen einer bestimmten Anwendung her. Bei einer Bereitstellung mit mehreren Clustern sollten Sie eine Verbindung mit einem Traffic Manager-DNS-Namen herstellen, der auf die Dienste in den einzelnen AKS-Clustern verweist. Definieren Sie diese Dienste mithilfe von Traffic Manager-Endpunkten. Jeder Endpunkt stellt die IP-Adresse des Lastenausgleichsdiensts dar. Leiten Sie mit dieser Konfiguration Netzwerkdatenverkehr vom Traffic Manager-Endpunkt in einer Region zum Endpunkt in einer anderen Region.
Traffic Manager führt DNS-Lookups durch und gibt den am besten geeigneten Endpunkt zurück. Mit prioritätsbasiertem Routing können Sie einen primären Dienstendpunkt und mehrere Sicherungsendpunkte aktivieren, falls der primäre oder einer der Sicherungsendpunkte nicht verfügbar ist.
Informationen zum Einrichten der Endpunkte und des Routings finden Sie unter Konfigurieren der prioritätsbasierten Routingmethode für Datenverkehr in Traffic Manager.
Anwendungsrouting mit Azure Front Door Service
Azure Front Door Service verbindet Ihre Endbenutzer mithilfe des Split TCP-basierten Anycast-Protokolls sofort mit dem nächstgelegenen Front Door-POP (Point of Presence). Weitere Features von Azure Front Door Service sind:
- TLS-Terminierung
- Benutzerdefinierte Domäne
- Web Application Firewall
- URL Rewrite
- Sitzungsaffinität
Überprüfen Sie die Anforderungen des Anwendungsdatenverkehrs, um zu ermitteln, welche Lösung sich am besten eignet.
Verbinden von Regionen mit globalem Peering virtueller Netzwerke
Verbinden Sie die beiden virtuellen Netzwerke über das Peering virtueller Netzwerke miteinander, um die Kommunikation zwischen Clustern zu ermöglichen. Das Peering virtueller Netzwerke verbindet virtuelle Netzwerke und bietet eine hohe Bandbreite für das Backbone-Netzwerk von Microsoft – auch über geografische Regionen hinweg.
Verwenden Sie vor dem Peering virtueller Netzwerke mit ausgeführten AKS-Clustern den Load Balancer Standard in Ihrem AKS-Cluster. Wenn diese Voraussetzung erfüllt ist, sind Kubernetes-Dienste über das Peering virtueller Netzwerke erreichbar.
Aktivieren der Georeplikation für Containerimages
Bewährte Methode
Speichern Sie Ihre Containerimages in Azure Container Registry (ACR), und erstellen Sie per Georeplikation in jeder AKS-Region eine Instanz der Registry.
Um Ihre Anwendungen in AKS bereitzustellen und zu registrieren, benötigen Sie eine Möglichkeit, die Containerimages zu speichern und abzurufen. Container Registry lässt sich in AKS integrieren, um Containerimages oder Helm-Charts sicher zu speichern. Container Registry unterstützt die Multimaster-Georeplikation, mit der Sie Ihre Images automatisch weltweit in Azure-Regionen replizieren können.
Um Leistung und Verfügbarkeit zu verbessern, verwenden Sie die Georeplikation von Container Registry, um eine Registrierung in jeder Region zu erstellen, in der Sie über einen AKS-Cluster verfügen. Jeder AKS-Cluster ruft dann Containerimages aus der lokalen Containerregistrierung in derselben Region ab.
Die Verwendung der Georeplikation von Container Registry zum Pullen von Images aus derselben Region bietet die folgenden Vorteile:
- Schneller: Sie pullen Images über latenzarme Hochgeschwindigkeits-Netzwerkverbindungen innerhalb derselben Azure-Region.
- Zuverlässiger: Wenn eine Region nicht verfügbar ist, pullt Ihr AKS-Cluster die Images aus einer verfügbaren Container Registry-Instanz.
- Kostengünstiger: Für den ausgehenden Netzwerkdatenverkehr zwischen Rechenzentren fallen keine Gebühren an.
Die Georeplikation ist ein Feature der Premium-SKU von Container Registry. Informationen zum Konfigurieren der Georeplikation finden Sie unter Georeplikation in Container Registry.
Entfernen des Dienstzustands aus Containern
Bewährte Methode
Speichern Sie den Dienstzustand nach Möglichkeit nicht im Container. Verwenden Sie stattdessen eine Azure-PaaS-Lösung (Platform as a Service), die die Replikation in mehreren Regionen unterstützt.
Der Dienstzustand bezieht sich auf die Daten im Arbeitsspeicher oder auf einem Datenträger, die ein Dienst für seine Ausführung benötigt. Hierzu gehören auch die Datenstrukturen und Membervariablen, die vom Dienst gelesen und geschrieben werden. Je nach Architektur des Diensts kann der Zustand auch Dateien oder andere Ressourcen umfassen, die auf dem Datenträger gespeichert sind. Der Zustand könnte z.B. die Dateien umfassen, die eine Datenbank zum Speichern von Daten und Transaktionsprotokollen verwendet.
Der Zustand kann ausgelagert oder mit dem Code zusammengestellt werden, der den Zustand ändert. In der Regel lagern Sie den Zustand mithilfe einer Datenbank oder einem anderen Datenspeicher aus, der über das Netzwerk auf verschiedenen Computern oder prozessextern auf dem gleichen Computer ausgeführt wird.
Container und Microservices sind dann am stabilsten, wenn die darin ausgeführten Prozesse ihren Zustand nicht beibehalten. Da Anwendungen fast immer einen Zustand enthalten, sollten Sie eine PaaS-Lösung verwenden, z. B.:
- Azure Cosmos DB
- Azure Database for PostgreSQL
- Azure Database for MySQL
- Azure SQL-Datenbank
Wie Sie portable Anwendungen erstellen, können Sie den folgenden Richtlinien entnehmen:
- The 12-factor app methodology (Die Zwölf-Faktoren-Methodik für Apps)
- Ausführen einer Webanwendung in mehreren Azure-Regionen
Erstellen eines Plans für die Speichermigration
Bewährte Methode
Wenn Sie Azure Storage verwenden, bereiten Sie die Migration Ihres Speichers von der primären zur Sicherungsregion vor, und testen Sie sie.
Ihre Anwendungen nutzen möglicherweise Azure Storage für ihre Daten. Wenn dies Fall ist, werden Ihre Anwendungen auf mehrere AKS-Cluster in verschiedenen Regionen verteilt. Sie müssen daher dafür sorgen, dass die Speicher synchronisiert werden. Zwei allgemeine Verfahren zum Replizieren von Speicher sind:
- Infrastrukturbasierte asynchrone Replikation
- Anwendungsbasierte asynchrone Replikation
Infrastrukturbasierte asynchrone Replikation
Ihre Anwendungen erfordern möglicherweise auch dann noch einen beständigen Speicher, nachdem ein Pod gelöscht wurde. In Kubernetes können Sie persistente Volumes verwenden, um Daten dauerhaft zu speichern. Persistente Volumes werden auf einem virtuellen Computerknoten bereitgestellt und dann für die Pods verfügbar gemacht. Persistente Volumes folgen Pods, auch dann, wenn ein Pod auf einen anderen Knoten im gleichen Cluster verschoben wird.
Welche Replikationsstrategie Sie verwenden, hängt von Ihrer Speicherlösung ab. Für die folgenden gängigen Speicherlösungen sind eigene Anleitungen zur Notfallwiederherstellung und Replikation verfügbar:
In der Regel stellen Sie einen gemeinsamen Speicher bereit, in den Anwendungen ihre Daten schreiben. Diese Daten werden dann regionsübergreifend repliziert, und der Zugriff auf die Daten erfolgt lokal.
Wenn Sie Azure Managed Disks verwenden, können Sie Velero on Azure und Kasten für die Replikation und Notfallwiederherstellung verwenden. Diese Sicherungslösungen sind nativ in Kubernetes integriert, werden jedoch nicht unterstützt.
Anwendungsbasierte asynchrone Replikation
Kubernetes bietet zurzeit keine native Implementierung für die anwendungsbasierte asynchrone Replikation. Da Container und Kubernetes lose gekoppelt sind, sollte jeder herkömmliche Anwendungs- oder Sprachansatz funktionieren. In der Regel replizieren die Anwendungen selbst die Speicheranforderungen, die dann in den zugrunde liegenden Datenspeicher jedes Clusters geschrieben werden.
Nächste Schritte
In diesem Artikel werden Überlegungen zur Geschäftskontinuität und Notfallwiederherstellung für AKS-Cluster erläutert. Weitere Informationen zu Clustervorgängen in AKS finden Sie in diesen Artikeln über Best Practices: