AKS-Baseline für Cluster in mehreren Regionen

In dieser Architektur wird ausführlich dargelegt, wie mehrere Instanzen eines AKS-Clusters (Azure Kubernetes Service) regionsübergreifend in einer Aktiv/Aktiv-Konfiguration mit Hochverfügbarkeit ausgeführt werden können.

Diese Architektur baut auf der AKS-Baselinearchitektur auf, dem von Microsoft empfohlenen Ausgangspunkt für die AKS-Infrastruktur. Die AKS-Baseline enthält Infrastrukturfeatures wie Microsoft Entra-Workloadidentität, Einschränkungen für ein- und ausgehende Daten, Ressourcenlimits und andere sichere AKS-Infrastrukturkonfigurationen. Diese Infrastrukturdetails werden in diesem Dokument nicht behandelt. Es wird empfohlen, sich mit der AKS-Baseline vertraut zu machen, bevor Sie mit den Inhalten zu mehreren Regionen fortfahren.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

In der AKS-Architektur mit mehreren Regionen werden zahlreiche Komponenten und Azure-Dienste verwendet. Hier werden nur die Komponenten aufgeführt, die für diese Architektur mit mehreren Clustern charakteristisch sind. Informationen zu den weiteren Komponenten finden Sie unter Baselinearchitektur für einen AKS-Cluster.

• Regionale AKS-Cluster Es werden mehrere AKS-Cluster bereitgestellt, jeweils in einer separaten Azure-Region. Während des normalen Betriebs wird der Netzwerkdatenverkehr zwischen allen Regionen geroutet. Wenn eine Region nicht mehr verfügbar ist, wird der Datenverkehr an die nächstgelegene Region für den Benutzer weitergeleitet, der die Anforderung gesendet hat.
• Regionale Hub-Spoke-Netzwerke Für jede regionale AKS-Instanz wird ein regionales Hub-Spoke-Netzwerkpaar bereitgestellt. Mithilfe von Azure Firewall Manager-Richtlinien werden Firewallrichtlinien regionsübergreifend verwaltet.
• Regionaler Schlüsseltresor: Azure Key Vault wird in jeder Region bereitgestellt. Schlüsseltresore werden zum Speichern vertraulicher Werte und Schlüssel verwendet, die für den AKS-Cluster spezifisch sind, und unterstützen die Dienste, die sich in dieser Region befinden.
• Mehrere Protokollarbeitsbereiche: Regionale Log Analytics-Arbeitsbereiche werden zum Speichern regionaler Netzwerkmetriken und Diagnoseprotokolle verwendet. Darüber hinaus wird eine freigegebene Log Analytics-Instanz verwendet, um Metriken und Diagnoseprotokolle für alle AKS-Instanzen zu speichern.
• Globales Azure Front Door-Profil: Azure Front Door dient zum Lastenausgleich und zum Routen von Datenverkehr an eine regionale Azure Application Gateway-Instanz, die sich vor jedem AKS-Cluster befindet. Azure Front Door ermöglicht ein globales Layer-7-Routing, das für diese Architektur benötigt wird.
• Globale Containerregistrierung: Die Containerimages für die Workload werden in einer verwalteten Containerregistrierung gespeichert. In dieser Architektur 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 werden Images automatisch in die ausgewählten Azure-Regionen repliziert. So kann auch dann weiterhin auf die Images zugegriffen werden, wenn es in einer Region zu einem Ausfall kommt.

Entwurfsmuster

Diese Architektur verwendet zwei Cloudentwurfsmuster:

• Geoknoten (geografische Knoten), in denen jede Region jede Anforderung bedienen kann.
• Bereitstellungsstempel, bei denen mehrere unabhängige Kopien einer Anwendung oder Anwendungskomponente aus einer einzigen Quelle, z. B. einer Bereitstellungsvorlage, bereitgestellt werden.

Überlegungen zu Geoknotenmustern

Ziehen Sie bei der Auswahl der Regionen zum Bereitstellen aller AKS-Cluster Regionen in der Nähe des Workloadconsumers oder Ihrer Kunden in Betracht. Erwägen Sie außerdem die regionsübergreifende Replikation. Bei der regionsübergreifenden Replikation werden die gleichen Anwendungen und Daten für den Schutz der Notfallwiederherstellung asynchron in anderen Azure-Regionen repliziert. Da Ihr Cluster auf mehr als zwei Regionen skaliert wird, planen Sie weiterhin die regionsübergreifende Replikation für jedes AKS-Clusterpaar ein.

Innerhalb jeder Region sind Knoten in den AKS-Knotenpools auf mehrere Verfügbarkeitszonen verteilt, um Probleme aufgrund von Zonenausfällen zu vermeiden. Verfügbarkeitszonen werden in einer begrenzten Anzahl von Regionen unterstützt, was die regionale Clusterplatzierung beeinflusst. Weitere Informationen zu AKS und Verfügbarkeitszonen, einschließlich einer Liste der unterstützten Regionen, finden Sie unter AKS-Verfügbarkeitszonen.

Überlegungen zum Muster mit Bereitstellungsstempeln

Wenn Sie eine AKS-Lösung mit mehreren Regionen verwalten, stellen Sie mehrere AKS-Cluster in mehreren Regionen bereit. Jede dieser Cluster wird als Stempel betrachtet. Wenn es zu einem regionalen Ausfall kommt oder Sie mehr Kapazität und/oder regionale Präsenz für Ihre Cluster benötigen, müssen Sie möglicherweise eine neue Stempelinstanz erstellen. Bei der Wahl eines Prozesses zum Erstellen und Verwalten von Bereitstellungsstempeln ist es wichtig, folgende Punkte zu berücksichtigen:

• Wählen Sie die entsprechende Technologie für die Stempeldefinitionen aus, die eine generalisierte Konfiguration ermöglicht. Beispielsweise können Sie Bicep zum Definieren der Infrastruktur als Code verwenden.
• Geben Sie instanzspezifische Werte mithilfe eines Bereitstellungseingabemechanismus an, z. B. über Variablen oder Parameterdateien.
• Wählen Sie Bereitstellungstools aus, die eine flexible, wiederholbare und idempotente Bereitstellung ermöglichen.
• Berücksichtigen Sie in einer Aktiv/Aktiv-Stempelkonfiguration, wie der Datenverkehr auf die einzelnen Stempel aufgeteilt wird. Diese Architektur nutzt Azure Front Door für den globalen Lastenausgleich.
• Berücksichtigen Sie beim Hinzufügen und Entfernen von Stempeln aus der Sammlung Kapazitäts- und Kostenaspekte.
• Überlegen Sie, wie Sie Einblick in die Sammlung erhalten und/oder die Stempelsammlung als einzelne Einheit überwachen können.

Jeder dieser Punkte wird in den folgenden Abschnitten mit spezifischen Anleitungen detailliert beschrieben.

Verwaltung von Fahrzeugflotten

Diese Lösung stellt eine Topologie mit mehreren Clustern und Regionen dar, ohne die Einbindung eines erweiterten Orchestrators, der alle Cluster als Teil einer einheitlichen Flotte behandelt. Wenn die Clusteranzahl zunimmt, sollten Sie die Registrierung der Mitglieder in Azure Kubernetes Fleet Manager in Erwägung ziehen, um eine besser skalierbare Verwaltung der teilnehmenden Cluster zu ermöglichen. Die hier vorgestellte Infrastrukturarchitektur ändert sich durch die Registrierung in Fleet Manager nicht grundlegend, aber die Vorgänge an Tag 2 und ähnliche Aktivitäten profitieren von einer Steuerungsebene, die simultan auf mehrere Cluster abzielen kann.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Clusterbereitstellung und Bootstrapping

Bei der Bereitstellung mehrerer Kubernetes-Cluster in hochverfügbaren und geografisch verteilten Konfigurationen ist es wichtig, die Summe der einzelnen Kubernetes-Cluster als gekoppelte Einheit zu betrachten. Vielleicht möchten Sie codegesteuerte Strategien für die automatische Bereitstellung und Konfiguration entwickeln, um sicherzustellen, dass jede Kubernetes-Instanz möglichst identisch ist. Ziehen Sie Strategien für das Auf- und Abskalieren durch Hinzufügen oder Entfernen weiterer Kubernetes-Cluster in Betracht. Ihr Entwurf sowie Ihr Bereitstellungs- und Konfigurationsplan sollten Ausfälle in Verfügbarkeitszonen, regionale Fehler und andere häufige Szenarien berücksichtigen.

Clusterdefinition

Für die Bereitstellung eines Azure Kubernetes Service-Clusters stehen Ihnen zahlreiche Optionen zur Verfügung. Das Azure-Portal, die Azure CLI und das Azure PowerShell-Modul sind allesamt gute Optionen für die Bereitstellung einzelner oder nicht gekoppelter AKS-Cluster. Diese Methoden können jedoch bei der Arbeit mit vielen eng gekoppelten AKS-Clustern eine Herausforderung darstellen. Bei Verwendung des Azure-Portals besteht beispielsweise die Gefahr von Fehlkonfigurationen aufgrund von ausgelassenen Schritten oder nicht verfügbaren Konfigurationsoptionen. Die Bereitstellung und Konfiguration vieler Cluster über das Portal ist ein zeitaufwendiger Prozess, der die Aufmerksamkeit eines oder mehrerer Techniker erfordert. Wenn Sie die Azure CLI oder Azure PowerShell verwenden, können Sie mithilfe der Befehlszeilentools einen wiederholbaren und automatisierten Prozess erstellen. Die Verantwortung für Aspekte wie Idempotenz, Kontrolle von Bereitstellungsfehlern und Fehlerbehebung liegt jedoch bei Ihnen und den von Ihnen erstellten Skripts.

Bei der Arbeit mit mehreren AKS-Instanzen empfiehlt es sich, die Verwendung einer Infrastructure-as-Code-Lösung in Betracht zu ziehen, z. B. Bicep, Azure Resource Manager-Vorlagen oder Terraform. Infrastructure-as-Code-Lösungen bieten eine automatisierte, skalierbare und idempotente Bereitstellungslösung. Sie können beispielsweise eine Bicep-Datei für die gemeinsamen Dienste der Lösung und eine andere für die AKS-Cluster und andere regionale Dienste verwenden. Bei Verwendung von Infrastructure-as-Code kann ein Bereitstellungsstempel mit generalisierten Konfigurationen (etwa für Netzwerk, Autorisierung und Diagnose) definiert werden. Eine Datei mit Bereitstellungsparametern kann mit regionalen Werten bereitgestellt werden. Mithilfe dieser Konfiguration kann eine einzelne Vorlage genutzt werden, um einen nahezu identischen Stempel in jeder Region bereitzustellen.

Die Entwicklung und Wartung von Infrastructure-as-Code-Ressourcen kann kostspielig sein. In einigen Fällen kann der Aufwand für die Definition der Infrastruktur als Code die Vorteile überwiegen, z. B. wenn Sie über eine sehr kleine (z. B. 2 oder 3) und unveränderliche Anzahl von AKS-Instanzen verfügen. In diesen Fällen ist es akzeptabel, einen zwingenderen Ansatz zu verwenden, z. B. mit Befehlszeilentools oder sogar manuellen Ansätzen mit dem Azure-Portal.

Clusterbereitstellung

Sobald der Clusterstempel definiert wurde, haben Sie viele Möglichkeiten, einzelne oder mehrere Stempelinstanzen einzusetzen. Es wird empfohlen, moderne Continuous Integration-Technologien wie GitHub Actions oder Azure Pipelines zu nutzen. Continuous Integration-basierte Bereitstellungslösungen bieten u. a. die folgenden Vorteile:

• Codebasierte Bereitstellungen, die das Hinzufügen und Entfernen von Stempeln mithilfe von Code ermöglichen
• Integrierte Testfunktionen
• Integrierte Umgebungs- und Stagingfunktionen
• Integrierte Lösungen für die Geheimnisverwaltung
• Integration mit der Quellcodeverwaltung für Anwendungscode sowie Bereitstellungsskripte und -vorlagen
• Bereitstellungsverlauf und Protokollierung
• Funktionen für die Zugriffskontrolle und -prüfung, um zu steuern, wer unter welchen Bedingungen Änderungen vornehmen kann

Da dem globalen Cluster neue Stempel hinzugefügt oder Stempel daraus entfernt werden, muss die Bereitstellungspipeline aktualisiert werden, um konsistent zu bleiben. Ein Ansatz besteht darin, die Ressourcen jeder Region als einzelner Schritt in einem GitHub-Aktionsworkflow bereitzustellen. Diese Konfiguration ist dahingehend einfach, da jede Clusterinstanz innerhalb der Bereitstellungspipeline klar definiert ist. Diese Konfiguration umfasst zusätzlichen Verwaltungsaufwand beim Hinzufügen und Entfernen von Clustern aus der Bereitstellung.

Eine weitere Möglichkeit wäre die Erstellung einer Geschäftslogik zum Erstellen von Clustern basierend auf einer Liste der gewünschten Standorte oder anderer maßgeblicher Datenpunkte. Beispielsweise könnte die Bereitstellungspipeline eine Liste der gewünschten Regionen enthalten. Ein Schritt innerhalb der Pipeline könnte dann diese Liste per Schleife durchlaufen und einen Cluster in jeder Region bereitstellen, die in der Liste gefunden wird. Der Nachteil dieser Konfiguration ist die Komplexität bei der Generalisierung der Bereitstellung und die Tatsache, dass die einzelnen Clusterstempel nicht explizit in der Bereitstellungspipeline beschrieben sind. Der Vorteil dieser Konfiguration ist, dass das Hinzufügen oder Entfernen von Clusterstempeln aus der Pipeline durch eine einfache Aktualisierung der Liste der gewünschten Regionen erfolgt.

Außerdem werden durch das Entfernen eines Cluster-Stempels aus der Bereitstellungspipeline nicht immer die Ressourcen des Stempels außer Betrieb genommen. Abhängig von Ihrer Bereitstellungslösung und -konfiguration ist möglicherweise ein zusätzlicher Schritt erforderlich, um die AKS-Instanzen und andere Azure-Ressourcen ordnungsgemäß außer Betrieb zu nehmen. Erwägen Sie die Verwendung von Bereitstellungsstapeln, um die vollständige Lebenszyklusverwaltung von Azure-Ressourcen zu ermöglichen, einschließlich der Bereinigung, wenn Sie sie nicht mehr benötigen.

Clusterbootstrapping

Nachdem jede Kubernetes-Instanz bzw. jeder Stempel bereitgestellt wurde, müssen Clusterkomponenten wie Eingangsdatencontroller, Identitätslösungen und Workloadkomponenten bereitgestellt und konfiguriert werden. Ziehen Sie außerdem die Anwendung von Sicherheits-, Zugriffs- und Governancerichtlinien im gesamten Cluster in Betracht.

Ähnlich wie bei der Bereitstellung kann es schwierig werden, diese Konfigurationen über mehrere Kubernetes-Instanzen hinweg manuell zu verwalten. Ziehen Sie stattdessen die folgenden Optionen für Konfiguration und Richtlinien im großen Maßstab in Betracht.

GitOps

Anstelle einer manuellen Konfiguration von Kubernetes-Komponenten wird die Verwendung automatisierter Methoden für die Anwendung von Konfigurationen auf einen Kubernetes-Cluster empfohlen, da diese Konfigurationen in ein Quellrepository eingecheckt werden. Dieser Ansatz wird häufig als GitOps bezeichnet, und zu den beliebten GitOps-Lösungen für Kubernetes gehören Flux und Argo CD. So ermöglicht die Flux-Erweiterung für AKS beispielsweise das automatische Bootstrapping der Cluster unmittelbar nach deren Bereitstellung.

GitOps wird im Artikel „Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)“ unter CI/CD für Cluster ausführlicher beschrieben. Die Verwendung eines auf GitOps basierenden Ansatzes für die Konfiguration trägt dazu bei, dass jede Kubernetes-Instanz ähnlich konfiguriert wird, ohne dass ein besonderer Aufwand betrieben werden muss. Ein rationalisierter Konfigurationsprozess wird noch wichtiger, da die Größe Ihrer Flotte wächst.

Azure Policy

Je mehr Kubernetes-Instanzen hinzugefügt werden, desto größer ist der Nutzen einer richtliniengesteuerten Governance, Compliance und Konfiguration. Die Verwendung von Richtlinien, in diesem Fall die Azure-Richtlinie, bietet eine zentrale und skalierbare Methode für die Clustersteuerung. Der Vorteil von AKS-Richtlinien wird im Artikel „Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)“ unter Richtlinienverwaltung ausführlich beschrieben.

Azure-Richtlinie sollte aktiviert werden, wenn die AKS-Cluster erstellt werden. Initiativen sollten im Prüfungsmodus zugewiesen werden, um Verstöße sichtbar zu machen. Sie können auch weitere Richtlinien festlegen, die nicht Teil einer der integrierten Initiativen sind. Diese Richtlinien werden im Modus Verweigern festgelegt. Es gibt beispielsweise eine Richtlinie, die sicherstellt, dass nur genehmigte Containerimages im Cluster ausgeführt werden. Erstellen Sie ggf. eigene benutzerdefinierte Initiativen. Fassen Sie die Richtlinien, die für Ihre Workload gelten, in einer einzigen Zuweisung zusammen.

Der Richtlinienbereich bezieht sich auf das Ziel jeder Richtlinie und Richtlinieninitiative. Sie können Bicep verwenden, um der Ressourcengruppe Richtlinien zuzuweisen, in denen jeder AKS-Cluster bereitgestellt wird. Wenn der Speicherbedarf des globalen Clusters zunimmt, führt dies zu zahlreichen doppelten Richtlinien. Sie können den Geltungsbereich von Richtlinien auch auf ein Azure-Abonnement oder eine Azure-Verwaltungsgruppe festlegen. Mit dieser Methode kann ein einzelner Satz von Richtlinien auf alle AKS-Cluster innerhalb des Geltungsbereichs eines Abonnements oder auf alle Abonnements unterhalb einer Verwaltungsgruppe angewendet werden.

Berücksichtigen Sie beim Entwurf einer Richtlinie für mehrere AKS-Cluster folgende Punkte:

• Wenden Sie Richtlinien an, die global auf alle AKS-Instanzen angewendet werden sollen, können auf eine Verwaltungsgruppe oder ein Abonnement angewendet werden.
• Platzieren Sie jeden regionalen Cluster in einer eigenen Ressourcengruppe, sodass auf die Ressourcengruppe regionsspezifische Richtlinien angewendet werden können.

Unter Ressourcenorganisation finden Sie Informationen, die Sie bei der Entwicklung einer Strategie für die Richtlinienverwaltung unterstützen.

Workloadbereitstellung

Berücksichtigen Sie zusätzlich zur AKS-Instanzkonfiguration die Workload, die in jeder regionalen Instanz oder jedem Stempel bereitgestellt wird. Bereitstellungslösungen oder Pipelines erfordern eine Konfiguration, um die einzelnen regionalen Stempel zu unterstützen. Wenn dem globalen Cluster weitere Stempel hinzugefügt werden, muss der Bereitstellungsprozess erweitert werden oder flexibel genug sein, um die neuen regionalen Instanzen zu unterstützen.

Berücksichtigen Sie bei der Planung der Workloadbereitstellung die folgenden Punkte:

• Generalisieren Sie die Bereitstellung, z. B. mit einem Helm-Chart, um sicherzustellen, dass eine einzelne Bereitstellungskonfiguration für mehrere Clusterstempel verwendet werden kann.
• Verwenden Sie eine einzelne Continuous Deployment-Pipeline, die zur Bereitstellung der Workload auf allen Clusterstempeln konfiguriert ist.
• Geben Sie stempelspezifische Instanzdetails als Bereitstellungsparameter an.
• Überlegen Sie, wie die Anwendungsdiagnoseprotokollierung und die verteilte Ablaufverfolgung für die anwendungsweite Überwachung konfiguriert werden sollen.

Verfügbarkeit und Failover

Eine wichtige Rolle bei der Wahl einer Kubernetes-Architektur mit mehreren Regionen spielt die Verfügbarkeit der Dienste. Wenn ein Dienst oder eine Dienstkomponente in einer Region ausfällt, sollte der Datenverkehr an eine Region umgeleitet werden, in der eine andere Instanz dieses Dienstes noch immer verfügbar ist. Eine Architektur mit mehreren Regionen umfasst viele verschiedene Fehlerstellen. In diesem Abschnitt wird jeder dieser potenziellen Fehlerstellen näher erläutert.

Anwendungs-Pod-Fehler

Ein Kubernetes-Bereitstellungsobjekt wird verwendet, um ein ReplicaSet zu erstellen, das mehrere Replikate eines Pods verwaltet. Wenn einer der Pods nicht verfügbar ist, wird der Datenverkehr zwischen den verbleibenden Replikaten geroutet. Die Kubernetes-Replikatgruppe (ReplicaSet) versucht, den Betrieb der angegebenen Anzahl von Replikaten aufrechtzuerhalten. Wenn eine Instanz ausfällt, sollte eine neue Instanz automatisch erstellt werden. Mit Livetests kann der Zustand von Anwendungen oder Prozessen überprüft werden, die im Pod ausgeführt werden. Wenn der Dienst nicht antwortet, entfernt der Livetest den Pod. Auf diese Weise wird das ReplicaSet gezwungen, eine neue Instanz zu erstellen.

Weitere Informationen finden Sie unter Kubernetes: ReplicaSet.

Fehler bei der Rechenzentrumshardware

Lokalisierte Fehler können gelegentlich auftreten. Beispielsweise ist der Strom für ein einzelnes Rack von Azure-Servern möglicherweise nicht mehr verfügbar. Nutzen Sie Azure-Verfügbarkeitszonen, damit Ihre AKS-Knoten nicht zu einem Single Point of Failure (SPOF) für eine Region werden. Die Verwendung von Verfügbarkeitszonen stellt sicher, dass AKS-Knoten in einer bestimmten Verfügbarkeitszone physisch von denen in einer anderen Verfügbarkeitszone getrennt sind.

Weitere Informationen finden Sie unter Erstellen eines Azure Kubernetes Service-Clusters (AKS), der Verfügbarkeitszonen verwendet.

Ausfall einer Azure-Region

Wenn eine ganze Region ausfällt, stehen die Pods im Cluster nicht mehr zur Verarbeitung von Anforderungen zur Verfügung. In diesem Fall leitet Azure Front Door den gesamten Datenverkehr an die verbleibenden fehlerfreien Regionen weiter. Die Kubernetes-Cluster und -Pods in den fehlerfreien Regionen setzen die Verarbeitung von Anforderungen fort.

Achten Sie in dieser Situation darauf, den erhöhten Datenverkehr bzw. die Anforderungen an den verbleibenden Cluster zu kompensieren. Beachten Sie folgende Punkte:

• Stellen Sie sicher, dass die Netzwerk- und Rechenressourcen richtig dimensioniert sind, um einen plötzlichen Anstieg des Datenverkehrs aufgrund eines Regionsfailovers aufzufangen. Wenn Sie beispielsweise Azure CNI verwenden, stellen Sie sicher, dass Sie über ein Subnetz verfügen, das groß genug ist, um alle Pod-IP-Adressen zu unterstützen, während der Datenverkehr ansteigt.
• 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.

Weitere Informationen finden Sie unter Horizontale automatische Podskalierung und Automatisches Skalieren eines Clusters.

Netzwerktopologie

Ähnlich wie die AKS-Baselinereferenzarchitektur verwendet diese Architektur eine Hub-Spoke-Netzwerktopologie. Berücksichtigen Sie neben den unter Netzwerktopologie angegeben Überlegungen folgende bewährte Methoden:

• Implementieren Sie einen Hub-Spoke-Satz virtueller Netzwerke für jede regionale AKS-Instanz. Vergleichen Sie innerhalb jeder Region jeden Spoke mit dem virtuellen Hub-Netzwerk.
• Routen Sie den gesamten ausgehenden Datenverkehr über eine Azure Firewall-Instanz in jedem regionalen Hubnetzwerk. Verwenden Sie Azure Firewall Manager-Richtlinien, um Firewallrichtlinien regionsübergreifend zu verwalten.
• Befolgen Sie die IP-Dimensionierung in der AKS-Baselinereferenzarchitektur, und lassen Sie mehr IP-Adressen für Vorgänge auf Knoten- und Podebene zu, falls in einer anderen Region ein regionaler Fehler auftritt und der Datenverkehr in die verbleibenden Regionen erheblich zunimmt.

Datenverkehrsverwaltung

Bei der AKS-Baselinereferenzarchitektur wird der Workloaddatenverkehr direkt an eine Azure Application Gateway-Instanz geroutet und anschließend an den Back-End-Lastenausgleich und die AKS-Eingangsressourcen weitergeleitet. Bei Verwendung mehrerer Cluster werden Clientanforderungen über eine Azure Front Door-Instanz geroutet, die den Datenverkehr an die Application Gateway-Instanz weiterleitet.

Laden Sie eine Visio-Datei mit dieser Architektur herunter.

1. Der Benutzer sendet eine Anforderung an einen Domänennamen (z. B. https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net), die in das Azure Front Door-Profil aufgelöst wird. Diese Anforderung wird mit einem Platzhalterzertifikat (*.azurefd.net) verschlüsselt, das für alle Unterdomänen von Azure Front Door ausgegeben wurde. Die Azure Front Door-Instanz validiert die Anforderung anhand der Web Application Firewallrichtlinien, wählt der schnellste Ursprung aus (basierend auf Status und Latenz) und löst die Ursprungs-IP-Adresse (Azure Application Gateway-Instanz) mithilfe von öffentlichem DNS auf.

2. Azure Front Door leitet die Anforderung an die ausgewählte Application Gateway-Instanz weiter, die als Einstiegspunkt für den regionalen Stempel dient. Der Datenverkehr fließt über das Internet. Azure Front Door stellt sicher, dass der Datenverkehr zum Ursprung verschlüsselt ist.

   Sie benötigen eine Methode, um sicherzustellen, dass die Application Gateway-Instanz nur Datenverkehr von der Front Door-Instanz akzeptiert. Ein Ansatz wäre die Verwendung einer Netzwerksicherheitsgruppe in dem Subnetz, in dem sich die Application Gateway-Instanz befindet. Die Regeln können den eingehenden (oder ausgehenden) Datenverkehr basierend auf Eigenschaften wie Quelle, Port und Ziel filtern. Mit der Eigenschaft für die Quelle können Sie ein integriertes Diensttag festlegen, das IP-Adressen für eine Azure-Ressource angibt. Diese Abstraktion erleichtert das Konfigurieren und Verwalten der Regel und das Nachverfolgen von IP-Adressen. Erwägen Sie außerdem die Verwendung des X-Azure-FDID-Headers, den Azure Front Door der Anforderung hinzufügt, bevor sie an den Ursprung gesendet wird, um sicherzustellen, dass die Application Gateway-Instanz nur Datenverkehr von der Front Door-Instanz akzeptiert. Weitere Informationen zu Front Door-Headern finden Sie unter Protokollunterstützung für HTTP-Header in Azure Front Door.

Überlegungen zu freigegebenen Ressourcen

Obwohl der Schwerpunkt dieses Szenarios auf mehreren Kubernetes-Instanzen liegt, die über verschiedene Azure-Regionen verteilt sind, ist es sinnvoll, einige Ressourcen für alle Regionen gemeinsam zu nutzen. Ein Ansatz besteht darin, eine einzelne Bicep-Datei zu verwenden, um alle freigegebenen Ressourcen bereitzustellen, und dann eine andere, um jeden regionalen Stempel bereitzustellen. In diesem Abschnitt wird auf jede dieser gemeinsam genutzten Ressourcen eingegangen, und es werden Überlegungen zur Nutzung der einzelnen Ressourcen über mehrere AKS-Instanzen hinweg angestellt.

Container Registry

Azure Container Registry wird in dieser Architektur verwendet, um Containerimagedienste zur Verfügung zu stellen. Der Cluster zieht Containerimages aus der Registrierung. Beachten Sie die folgenden Punkte, wenn Sie Azure Container Registry in einer Clusterbereitstellung in mehreren Regionen verwenden.

Geografische Verfügbarkeit

Positionieren Sie eine Containerregistrierung in jeder Region, in der ein AKS-Cluster bereitgestellt wird. Dieser Ansatz ermöglicht Netzwerkoperationen mit geringer Latenz und damit schnelle, zuverlässige Bildübertragungen. Es bedeutet auch, dass Sie mehrere Imagedienst-Endpunkte haben, damit die Verfügbarkeit auch dann gewährleistet ist, wenn regionale Dienste ausfallen. Mithilfe der Georeplikationsfunktion von Azure Container Registry können Sie eine Containerregistrierung verwalten, die in mehreren Regionen automatisch repliziert wird.

Erwägen Sie das Erstellen einer einzelnen Registrierung mit Replikaten in jeder Azure-Region, die Cluster enthält. Weitere Informationen zur Azure Container Registry-Replikation finden Sie unter Georeplikation in Azure Container Registry.

Abbildung mit mehreren Azure Container Registry-Replikaten aus dem Azure-Portal.

Clusterzugriff

Jeder AKS-Cluster erfordert Zugriff auf die Containerregistrierung, damit Containerimageebenen abgerufen werden können. Es gibt mehrere Möglichkeiten zum Einrichten des Zugriffs auf die Azure Container Registry. In dieser Architektur wird für jeden Cluster eine verwaltete Identität erstellt, die dann die AcrPull-Rolle in der Containerregistrierung gewährt wird. Weitere Informationen und Empfehlungen zur Verwendung verwalteter Identitäten für den Azure Container Registry-Zugriff finden Sie unter Baselinearchitektur für einen AKS-Cluster.

Diese Konfiguration ist in der Bicep-Datei für den Clusterstempel definiert, sodass bei jeder Bereitstellung eines neuen Clusters der neuen AKS-Instanz Zugriff gewährt wird. Da die Containerregistrierung eine freigegebene Ressource ist, stellen Sie sicher, dass Ihre Bereitstellungen die Ressourcen-ID der Containerregistrierung als Parameter enthalten.

Azure Monitor

Das Azure Monitor Container Insights-Feature ist das empfohlene Tool, um die Leistung und Integrität Ihrer Cluster- und Containerworkloads zu überwachen und zu verstehen. Container Insights verwendet sowohl einen Log Analytics-Arbeitsbereich zum Speichern von Protokolldaten als auch Azure Monitor-Metriken zum Speichern numerischer Zeitreihendaten. Container Insights können auch Prometheus-Metriken erfassen und die Daten entweder an den verwalteten Azure Monitor-Dienst für Prometheus oder Azure Monitor-Protokolle senden. Weitere Informationen finden Sie unter Überwachen und Sammeln von Metriken.

Sie können auch Ihre AKS-Clusterdiagnoseeinstellungen konfigurieren, um Ressourcenprotokolle aus den Komponenten der AKS-Steuerungsebene zu erfassen und zu analysieren und an einen Log Analytics-Arbeitsbereich weiterzuleiten.

Wenn Sie eine Überwachungslösung für eine Multiregion-Architektur entwerfen, ist es wichtig, die Kopplung zwischen den einzelnen Stempeln zu berücksichtigen. Sie können einen einzelnen Protokollanalyse-Arbeitsbereich bereitstellen, der von jedem Kubernetes-Cluster freigegeben wird. Wie bei den anderen gemeinsam genutzten Ressourcen definieren Sie Ihren regionalen Stempel, um Informationen über den einzelnen gobal gemeinsam genutzten Log Analytics-Arbeitsbereich zu beziehen und jeden regionalen Cluster damit zu verbinden. Wenn jeder regionale Cluster Diagnoseprotokolle an diesen einzelnen Log Analytics-Arbeitsbereich sendet, können Sie die Daten zusammen mit Ressourcenmetriken verwenden, um Berichte und Dashboards einfacher zu erstellen, um zu verstehen, wie Ihre gesamte Multi-Region-Lösung ausgeführt wird.

Azure Front Door

Azure Front Door wird zum Lastenausgleich und zum Weiterleiten von Datenverkehr an jeden AKS-Cluster verwendet. Azure Front Door ermöglicht auch globales Layer-7-Routing. Diese Funktionen sind für dieses Szenario erforderlich.

Clusterkonfiguration

Wenn jede regionale AKS-Instanz hinzugefügt wird, muss das Application Gateway, das zusammen mit dem Kubernetes-Cluster bereitgestellt wird, als Ursprung in Azure Front Door registriert werden, wodurch es für das Routing verfügbar wird. Für diesen Vorgang ist eine Aktualisierung Ihrer Infrastructure-as-Code-Ressourcen erforderlich. Alternativ kann dieser Vorgang von der Bereitstellungskonfiguration entkoppelt und mit Tools wie der Azure CLI verwaltet werden.

Zertifikate

Azure Front Door unterstützt keine Ursprünge mit selbstsignierten Zertifikaten, auch nicht in Entwicklungs- oder Testumgebungen. Um HTTPS-Verkehr zu ermöglichen, müssen Sie ein TLS/SSL-Zertifikat erstellen, das von einer Zertifizierungsstelle (CA) signiert ist. Informationen zu weiteren Zertifizierungsstellen, die von Front Door unterstützt werden, finden Sie unter Zulässige Zertifizierungsstellen zum Aktivieren von benutzerdefiniertem HTTPS in Azure Front Door.

Zum Testen oder für Nichtproduktionscluster können Sie die Verwendung von Certbot zum Erstellen eines Let's Encrypt Authority X3-Zertifikats für jedes der Anwendungsgateways in Betracht ziehen.

Verwenden Sie bei der Planung eines Produktionsclusters die bevorzugte Methode Ihrer Organisation zum Erwerb von TLS-Zertifikaten.

Clusterzugriff und -identität

Wie unter Baselinearchitektur für einen AKS-Cluster erläutert, empfiehlt es sich, Microsoft Entra ID als Zugriffsidentitätsanbieter für Ihre Cluster zu verwenden. Die Microsoft Entra-Gruppen können anschließend verwendet werden, um den Zugriff auf Clusterressourcen zu steuern.

Wenn Sie mehrere Cluster verwalten, müssen Sie sich für ein Zugriffsschema entscheiden. Beispiele für Optionen:

• Erstellen Sie eine globale clusterweite Zugriffsgruppe, deren Mitglieder auf alle Objekte in sämtlichen Kubernetes-Instanzen des Clusters zugreifen können. Diese Option erfordert nur einen minimalen Verwaltungsaufwand, gewährt jedoch jedem Gruppenmitglied erhebliche Rechte.
• Erstellen Sie eine individuelle Zugriffsgruppe für jede Kubernetes-Instanz, mit der der Zugriff auf Objekte in einer einzelnen Clusterinstanz gewährt wird. Bei dieser Option erhöht sich der Verwaltungsaufwand, sie bietet jedoch auch einen differenzierteren Clusterzugriff.
• Definieren Sie differenzierte Zugriffssteuerungen für Kubernetes-Objekttypen und Namespaces, und korrelieren Sie die Ergebnisse mit einer Microsoft Entra-Gruppenstruktur. Bei dieser Option erhöht sich der Verwaltungsaufwand erheblich, sie bietet jedoch nicht nur präzisen Zugriff auf jeden Cluster, sondern auch auf die Namespaces und Kubernetes-APIs in jedem Cluster.

Für den administrativen Zugriff sollten Sie eine Microsoft Entra-Gruppe für jede Region erstellen. Gewähren Sie jeder Gruppe vollen Zugriff auf den entsprechenden Clusterstempel in dieser Region. Die Mitglieder jeder Gruppe haben dann administrativen Zugang zu den entsprechenden Clustern.

Weitere Informationen zum Verwalten des AKS-Clusterzugriffs mit Microsoft Entra ID finden Sie unter Integration von AKS und Microsoft Entra.

Daten, Status und Cache

Wenn Sie einen global verteilten Satz mit AKS-Clustern verwenden, berücksichtigen Sie die Architektur der Anwendung, des Prozesses oder anderer Workloads, die möglicherweise über den Cluster ausgeführt werden. Müssen zustandsbasierte Workloads, die über die Cluster verteilt sind, auf einen Zustandsspeicher zugreifen? Wenn ein Prozess aufgrund eines Fehlers an einer anderen Stelle im Cluster neu erstellt wird, kann die Workload bzw. der Prozess dann weiterhin auf einen abhängigen Zustandsspeicher oder eine Lösung für die Zwischenspeicherung zugreifen? Der Status kann auf viele Arten gespeichert werden, aber selbst in einem einzelnen Kubernetes-Cluster ist die Verwaltung komplex. Die Komplexität erhöht sich, wenn mehrere Kubernetes-Cluster hinzugefügt werden. Aus Gründen des regionalen Zugriffs und der Komplexität sollten Sie erwägen, Ihre Anwendungen so zu gestalten, dass sie einen global verteilten Zustandsspeicherdienst verwenden.

Das Design dieser Architektur enthält keine Konfiguration für Zustandsaspekte. Wenn Sie eine einzelne logische Anwendung in mehreren AKS-Clustern ausführen, sollten Sie Ihre Workload so gestalten, dass sie einen global verteilten Datendienst wie Azure Cosmos DB verwendet. Azure Cosmos DB ist ein global verteiltes Datenbanksystem, mit dem Sie Daten aus den lokalen Replikaten Ihrer Datenbank lesen und schreiben können, und der Cosmos DB-Dienst verwaltet die Georeplikation für Sie. Weitere Informationen finden Sie unter Azure Cosmos DB.

Wenn Ihre Workload eine Cachelösung verwendet, stellen Sie sicher, dass Sie Ihre Cachedienste so gestalten, dass sie auch bei Failoverereignissen funktionsfähig bleiben. Stellen Sie sicher, dass die Workload selbst resilient gegenüber einem cachebezogenen Failover ist und dass die Zwischenspeicherungslösungen in allen regionalen AKS-Instanzen vorhanden sind.

Kostenoptimierung

Mithilfe des Azure-Preisrechners können Sie die Kosten für die in der Architektur verwendeten Dienste schätzen. Weitere bewährte Methoden werden im Abschnitt Kostenoptimierung im Microsoft Azure Well-Architected Framework und spezifische Konfigurationsoptionen für die Kostenoptimierung im Artikel Kosten optimieren beschrieben.

Erwägen Sie die Aktivierung AKS-Kostenanalyse für die granulare Kostenzuordnung von Clusterinfrastrukturen durch Kubernetes spezifische Konstrukte.

Nächste Schritte

• Erstellen eines Azure Kubernetes Service-Clusters (AKS), der Verfügbarkeitszonen verwendet
• Azure Kubernetes Fleet Manager
• Georeplikation in Azure Container Registry
• Azure-Regionspaare

Zugehörige Ressourcen

• Azure Well-Architected Framework-Bewertung: Azure Kubernetes Service (AKS)
• Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)
• CI/CD-Pipeline für containerbasierte Workloads
• Integration von AKS und Microsoft Entra
• Dokumentation zu Azure Front Door
• Dokumentation zu Azure Cosmos DB