In dieser Referenzarchitektur 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.
Eine Referenzimplementierung dieser Architektur ist auf GitHub verfügbar.
Komponenten
In der AKS-Referenzarchitektur mit mehreren Regionen werden zahlreiche Komponenten und Azure-Dienste verwendet. Nachfolgend 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.
- Mehrere Cluster/mehrere Regionen 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.
- Hub-Spoke-Netzwerk pro Region 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üsselspeicher Azure Key Vault wird in jeder Region zum Speichern vertraulicher Werte und Schlüssel bereitgestellt, die spezifisch für die AKS-Instanz und unterstützende Dienste in dieser Region sind.
- Azure Front Door 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 Referenzarchitektur benötigt wird.
- Log Analytics Regionale Log Analytics-Instanzen 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.
- 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 Referenzarchitektur verwendet zwei Cloudentwurfsmuster: Das Muster mit geografischen Knoten („Geodes“), bei dem jede Region jede Anforderung bearbeiten kann, und das Muster mit Bereitstellungsstempeln, bei dem mehrere unabhängige Kopien einer Anwendung oder Anwendungskomponente aus einer einzelnen Quelle (Bereitstellungsvorlage) bereitgestellt werden.
Überlegungen zum Muster mit geografischen Knoten
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
Beim Verwalten eines AKS-Clusters mit mehreren Regionen werden mehrere AKS-Instanzen regionsübergreifend bereitgestellt. Jede dieser Instanzen wird als Stempel betrachtet. Wenn es zu einem regionalen Ausfall kommt oder Sie mehr Kapazität und/oder regionale Präsenz für Ihren 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, z. B. Infrastruktur als Code (Infrastructure-as-Code, IaC)
- 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.
- Berücksichtigen Sie beim Hinzufügen und Entfernen von Stempeln aus der Sammlung Kapazitäts- und Kostenaspekte.
- Überlegen Sie, wie Sie Einblick in die Stempelsammlung erhalten und/oder die Stempelsammlung als einzelne Einheit überwachen können.
Jeder dieser Punkte wird in den folgenden Abschnitten dieser Referenzarchitektur 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. Es empfiehlt sich, Strategien für das Auf- und Abskalieren durch Hinzufügen oder Entfernen weiterer Kubernetes-Instanzen in Betracht zu ziehen. Sie möchten, dass Ihr Entwurf, Ihr Bereitstellungs- und Konfigurationsplan regionale Ausfälle oder andere gängige 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. Außerdem ist die Bereitstellung und Konfiguration vieler Cluster über das Portal ein zeitaufwendiger Prozess, der die Aufmerksamkeit eines oder mehrerer Techniker erfordert. Sie können 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 vielen AKS-Instanzen empfiehlt es sich, die Verwendung einer Infrastructure-as-Code-Lösung in Betracht zu ziehen, z. B. Azure Resource Manager-Vorlagen, Bicep-Vorlagen oder Terraform-Konfigurationen. Infrastructure-as-Code-Lösungen bieten eine automatisierte, skalierbare und idempotente Bereitstellungslösung. Diese Referenzarchitektur enthält eine ARM-Vorlage für die gemeinsamen Dienste der Lösungen und eine weitere für die AKS-Cluster und regionalen Dienste. 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, z. B. wenn eine statische/feste Anzahl von AKS-Instanzen bereitgestellt wird, kann der Infrastructure-as-Code-Overhead die Vorteile überwiegen. In diesen Situationen ist ein eher imperativer Ansatz, z. B. mit Befehlszeilentools, oder sogar ein manueller Ansatz akzeptabel.
Clusterbereitstellung
Sobald die Clusterstempeldefinition erfolgt ist, 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 in die Verwaltung von Code-/Bereitstellungsquellen
- Bereitstellungsverlauf und Protokollierung
Da dem globalen Cluster neue Stempel hinzugefügt oder Stempel daraus entfernt werden, muss die Bereitstellungspipeline aktualisiert werden, um konsistent zu bleiben. In der Referenzimplementierung wird jede Region als einzelner Schritt innerhalb eines GitHub-Aktionsworkflows bereitgestellt. (Ein Beispiel finden Sie hier.) Diese Konfiguration ist dahingehend einfach, dass 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 Verwendung von Logik 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 stellt das Entfernen eines Clusterstempels aus der Bereitstellungspipeline nicht unbedingt sicher, dass er auch außer Betrieb genommen wird. Abhängig von Ihrer Bereitstellungslösung und -konfiguration ist möglicherweise ein zusätzlicher Schritt erforderlich, um sicherzustellen, dass die AKS-Instanzen ordnungsgemäß außer Betrieb genommen wurden.
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 sollten Sie die Verwendung automatisierter Methoden für die Anwendung von Konfigurationen auf einen Kubernetes-Cluster erwägen, 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. Bei dieser Implementierung wird die Flux-Erweiterung für AKS verwendet, um das Bootstrapping der Cluster automatisch und unmittelbar nach der Bereitstellung der Cluster zu ermöglichen.
GitOps wird im Artikel „Baselinearchitektur für einen AKS-Cluster (Azure Kubernetes Service)“ unter CI/CD für Cluster ausführlicher beschrieben. Wichtig ist hier, dass die Verwendung eines auf GitOps basierenden Ansatzes für die Konfiguration dazu beiträgt, dass jede Kubernetes-Instanz ähnlich konfiguriert wird, ohne dass ein besonderer Aufwand betrieben werden muss. Dies wird noch wichtiger, wenn die Größe Ihrer Flotte zunimmt.
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.
In dieser Referenzimplementierung wird Azure Policy beim Erstellen des AKS-Clusters aktiviert und die restriktive Initiative im Überwachungsmodus zugewiesen, um Erkenntnisse zur Nichtkonformität zu gewinnen. Außerdem werden durch die Implementierung weitere Richtlinien festgelegt, die nicht Teil integrierter 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. Die mit dieser Architektur verbundene Referenzimplementierung verwendet eine ARM-Vorlage, um der Ressourcengruppe, in der jeder AKS-Cluster eingesetzt wird, Richtlinien zuzuweisen. 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 und/oder auf alle Abonnements unterhalb einer Verwaltungsgruppe angewendet werden.
Berücksichtigen Sie beim Entwurf einer Richtlinie für mehrere AKS-Cluster folgende Punkte:
- Richtlinien, die global auf alle AKS-Instanzen angewendet werden sollen, können auf eine Verwaltungsgruppe oder ein Abonnement angewendet werden.
- Wenn Sie jeden regionalen Cluster in einer eigenen Ressourcengruppe platzieren, können auf die Ressourcengruppe regionsspezifische Richtlinien angewendet werden.
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 dieser Dienst verfügbar ist. Eine Architektur mit mehreren Regionen umfasst viele verschiedene Fehlerstellen. In diesem Abschnitt wird jeder dieser potenziellen Fehlerstellen näher erläutert.
Anwendungspods (regional)
Ein Kubernetes-Bereitstellungsobjekt wird verwendet, um mehrere Replikate eines Pods (ReplicaSet) zu erstellen. Wenn eines der Podreplikate nicht verfügbar ist, wird der Datenverkehr zwischen den verbleibenden Replikaten geroutet. Die Kubernetes-Replikatgruppe (ReplicaSet) versucht, die angegebene Anzahl von Replikaten in Betrieb zu halten. Wenn eine Instanz ausfällt, sollte eine neue Instanz erstellt werden. Und schließlich kann anhand von Livetests 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.
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.
Achten Sie in dieser Situation darauf, den erhöhten Datenverkehr bzw. die Anforderungen an den verbleibenden Cluster zu kompensieren. Folgende Aspekte müssen beachtet werden:
- 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 CNI sicher, dass das verwendete Subnetz alle Pod-IP-Adressen bei einer hohen Datenverkehrslast unterstützen kann.
- Verwenden Sie die horizontale automatische Podskalierung (Horizontal Pod Autoscaler, HPA), 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.
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. 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.
Kubernetes-Knotenpools (global)
Bei einem Ausfall einer vollständigen Region leitet Azure Front Door den Datenverkehr an die verbleibenden und fehlerfreien Regionen weiter. Achten Sie wieder darauf, den erhöhten Datenverkehr bzw. die Anforderungen an den verbleibenden Cluster zu kompensieren.
Weitere Informationen finden Sie unter Azure Front Door.
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 eine Hub-Spoke-Konfiguration für jede regionale AKS-Instanz, bei der ein Peering zwischen den virtuellen Hub-Spoke-Netzwerken eingerichtet wird.
- 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.
- Folgen Sie den unter Planen der IP-Adressen angegebenen Empfehlungen zur Dimensionierung des IP-Adressraums, und planen Sie zusätzliche IP-Adressen für den Betrieb von Knoten und Pods im Falle eines regionalen Ausfalls ein.
Datenverkehrsverwaltung
Bei der AKS-Baselinereferenzarchitektur wird der Workloaddatenverkehr direkt an eine Azure Application Gateway-Instanz geroutet und anschließend an den Back-End-Lastenausgleich bzw. 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.
Der Benutzer sendet eine Anforderung an einen Domänennamen (z.B.
https://contoso-web.azurefd.net), die in die Azure Front Door-Instanz 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 WAF-Richtlinien, wählt das schnellste Back-End aus (basierend auf Status und Latenz) und löst die Back-End-IP-Adresse (Azure Application Gateway-Instanz) mithilfe von öffentlichem DNS auf.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 und wird durch Azure Front Door verschlüsselt. 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 von Front Door an das Back-End gesendeten Headers
X-Azure-FDID, 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 dieser Referenzarchitektur auf mehreren Kubernetes-Instanzen liegt, die über verschiedene Azure-Regionen verteilt sind, ist es sinnvoll, einige Ressourcen für alle Instanzen gemeinsam zu nutzen. Die AKS-Referenzimplementierung für mehrere Regionen verwendet eine einzige ARM-Vorlage für die Bereitstellung aller gemeinsamen Ressourcen und eine weitere für die Bereitstellung der einzelnen regionalen Stempel. 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 Referenzarchitektur verwendet, um Containerimagedienste (Pull) zur Verfügung zu stellen. Beachten Sie die folgenden Punkte, wenn Sie Azure Container Registry in einer Clusterbereitstellung in mehreren Regionen verwenden.
Geografische Verfügbarkeit
Die Platzierung einer Containerregistrierung in jeder Region, in der ein AKS-Cluster bereitgestellt wird, ermöglicht netzwerknahe Vorgänge und damit schnelle, zuverlässige Übertragungen auf Imageebene. Verwenden Sie mehrere Imagedienst-Endpunkte, damit die Verfügbarkeit auch dann gewährleistet ist, wenn regionale Dienste ausfallen. Mithilfe der Georeplikationsfunktion von Azure Container Registry können Sie eine Container Registry-Instanz verwalten, die in mehreren Regionen repliziert wird.
Die AKS-Referenzimplementierung für mehrere Regionen umfasst eine einzelne Container Registry-Instanz und Replikate dieser Instanz in jeder Clusterregion. Weitere Informationen zur Azure Container Registry-Replikation finden Sie unter Georeplikation in Azure Container Registry.
Abbildung: Anzeige mehrerer ACR-Replikate innerhalb des Azure-Portals
Clusterzugriff
Jede AKS-Instanz benötigt Zugriff, um Images per Pull aus Azure Container Registry abzurufen. Es gibt mehrere Möglichkeiten, den Zugriff auf Azure Container Registry einzurichten. Diese Referenzarchitektur verwendet für jeden Cluster eine verwaltete Azure-Identität, der anschließend die AcrPull-Rolle für die Container Registry-Instanz zugewiesen wird. Weitere Informationen und Empfehlungen zur Verwendung verwalteter Identitäten für den Container Registry-Zugriff finden Sie unter Integrieren von Azure Active Directory für den Cluster.
Diese Konfiguration ist in der ARM-Vorlage für den Clusterstempel definiert, sodass bei jeder Bereitstellung eines neuen Clusters der neuen AKS-Instanz Zugriff gewährt wird. Da es sich bei Container Registry um eine gemeinsam genutzte Ressource handelt, müssen Sie sicherstellen, dass Ihre Bereitstellungsvorlage für die Stempel die erforderlichen Details – in diesem Fall die Ressourcen-ID für Container Registry – verarbeiten und nutzen kann.
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.
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.
Weitere Informationen finden Sie unter AKS-Baselinereferenzarchitektur.
Bei der Überwachung einer regionsübergreifenden Implementierung wie dieser Referenzarchitektur ist es wichtig, die Kopplung zwischen den einzelnen Stempeln zu berücksichtigen. In diesem Fall sollten Sie jeden Stempel als Komponente einer einzelnen Einheit (regionaler Cluster) betrachten. Die AKS-Referenzimplementierung in mehreren Regionen verwendet einen einzelnen Log Analytics-Arbeitsbereich, der von den Kubernetes-Clustern gemeinsam genutzt wird. Wie bei den anderen gemeinsam genutzten Ressourcen definieren Sie Ihren regionalen Stempel, um Informationen über den einzelnen Log Analytics-Arbeitsbereich zu beziehen und jeden Cluster damit zu verbinden.
Da nun jeder regionale Cluster Diagnoseprotokolle an einen einzigen Log Analytics-Arbeitsbereich sendet, können diese Daten zusammen mit den Ressourcenmetriken zur einfacheren Erstellung von Berichten und Dashboards genutzt werden, die einen Gesamtüberblick über den globalen Cluster liefern.
Azure Front Door
Azure Front Door wird zum Lastenausgleich und zum Weiterleiten von Datenverkehr an jeden AKS-Cluster verwendet. Azure Front Door ermöglicht ein globales Layer-7-Routing, das für diese Referenzarchitektur benötigt wird.
Clusterkonfiguration
Wenn regionale AKS-Instanzen hinzugefügt werden, muss die zusammen mit dem Kubernetes-Cluster bereitgestellte Application Gateway-Instanz als Front Door-Back-End registriert werden, um ein ordnungsgemäßes Routing zu gewährleisten. 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. Die Bereitstellungspipeline der Referenzimplementierung verwendet für diesen Vorgang einen eigenen Azure CLI-Schritt.
Zertifikate
Front Door unterstützt selbst in Dev/Test-Umgebungen keine selbstsignierten Zertifikate. Um HTTPS-Verkehr zu ermöglichen, müssen Sie ein TLS/SSL-Zertifikat erstellen, das von einer Zertifizierungsstelle (CA) signiert ist. Die Referenzimplementierungen verwenden Certbot, um ein Let's Encrypt Authority X3-Zertifikat zu erstellen. Verwenden Sie bei der Planung eines Produktionsclusters die bevorzugte Methode Ihrer Organisation zum Erwerb von TLS-Zertifikaten.
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.
Clusterzugriff und -identität
Wie unter Baselinearchitektur für einen AKS-Cluster erläutert, empfiehlt es sich, Microsoft Entra ID als Zugriffsidentitätsanbieter des Clusters 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 Azure Directory-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.
Bei der enthaltenen Referenzimplementierung werden zwei Microsoft Entra-Gruppen für den Administratorzugriff erstellt. Diese Gruppen werden zum Zeitpunkt der Bereitstellung des Clusterstempels mithilfe der Bereitstellungsparameterdatei angegeben. Mitglieder jeder Gruppe haben Vollzugriff auf den entsprechenden Clusterstempel.
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 Cluster mit AKS-Instanzen verwenden, berücksichtigen Sie die Architektur der Anwendung, des Prozesses oder anderer Workloads, die möglicherweise über den Cluster ausgeführt werden. Muss eine zustandsbasierte Workload, die über den Cluster verteilt ist, 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? Ein Zustand kann auf unterschiedliche Weise erreicht werden, in einem einzelnen Kubernetes-Cluster kann dies jedoch komplex sein. Die Komplexität erhöht sich, wenn mehrere Kubernetes-Clusterinstanzen 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.
Die Referenzimplementierung mit mehreren Clustern enthält keine Demonstration oder Konfiguration für Zustandsaspekte. Wenn Sie Anwendungen in AKS-Clusterinstanzen 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, das Ihnen ermöglicht, Daten aus den lokalen Replikaten Ihrer Datenbank zu lesen und in diese zu schreiben. Weitere Informationen finden Sie unter Azure Cosmos DB.
Wenn Ihre Workload eine Zwischenspeicherungslösung nutzt, stellen Sie sicher, dass sie so gestaltet ist, dass die Cachedienste funktionsfähig bleiben. Stellen Sie hierzu 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