Blau-Grün-Bereitstellung von AKS-Clustern

Azure Kubernetes Service (AKS)

Azure Application Gateway

Azure Container Registry

Azure Front Door

Azure DNS

Dieser Artikel enthält eine Anleitung zur Implementierung einer blau-grünen Bereitstellungsstrategie, mit der Sie eine neue Version eines Azure Kubernetes Service (AKS)-Clusters testen können, während die aktuelle Version weiterläuft. Nachdem die neue Version überprüft wurde, wird der Benutzerdatenverkehr durch eine Routingänderung zu der neuen Version umgeleitet. Das Bereitstellen auf diese Weise erhöht die Verfügbarkeit beim Vornehmen von Änderungen, einschließlich Upgrades, an AKS-Clustern. In diesem Artikel werden das Design und die Implementierung einer Blau-Grün-Bereitstellung von AKS beschrieben, die verwaltete Azure-Dienste und native Kubernetes-Features verwendet.

Aufbau

In diesem Abschnitt werden Architekturen für die Blau-Grün-Bereitstellung von AKS-Clustern beschrieben. Es gibt zwei Fälle:

Die Anwendungen und APIs sind öffentlich zugänglich.
Die Anwendungen und APIs sind privat zugänglich.

Es gibt auch einen Hybridfall, der hier nicht erläutert wird, in dem es eine Mischung aus öffentlich und privat zugänglichen Anwendungen und APIs im Cluster gibt.

Das folgende Diagramm zeigt die Architektur für den öffentlich zugänglichen Fall:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Azure Front Door und Azure DNS stellen den Routingmechanismus bereit, der den Datenverkehr zwischen den blauen und grünen Clustern umschaltet. Weitere Informationen finden Sie unter Blau-Grün-Bereitstellung mit Azure Front Door. Mithilfe von Azure Front Door ist es möglich, einen vollständigen Wechsel oder einen stärker kontrollierten Wechsel zu implementieren, der auf Gewichtungen basiert. Diese Methode ist die zuverlässigste und effizienteste in einer Azure-Umgebung. Wenn Sie ihr eigenes DNS und einen eigenen Lastenausgleich verwenden möchten, müssen Sie sicher sein, dass sie so konfiguriert sind, dass sie einen sicheren und zuverlässigen Wechsel bereitstellen.

Azure Application Gateway stellt die Front-Ends bereit, die für die öffentlichen Endpunkte bestimmt sind.

Dieses Diagramm zeigt den privat zugänglichen Fall:

Laden Sie eine Visio-Datei dieser Architektur herunter.

In diesem Fall implementiert eine einzelne Azure DNS-Instanz das Umschalten des Datenverkehrs zwischen den blauen und grünen Clustern. Dies erfolgt mithilfe von A- und CNAME-Einträgen. Ausführliche Informationen finden Sie unter T3: Umschalten des Datenverkehrs zum grünen Cluster.

Application Gateway stellt die Front-Ends bereit, die für die privaten Endpunkte bestimmt sind.

Workflow

In einer Blau-Grün-Bereitstellung gibt es fünf Phasen, in denen die aktuelle Version des Clusters auf die neue Version aktualisiert wird. In unserer Beschreibung ist der blaue Cluster die aktuelle Version, und der grüne Cluster ist die neue.

Die Phasen sind:

T0: Der blaue Cluster ist aktiviert.
T1: Bereitstellen des grünen Clusters.
T2: Synchronisieren des Kubernetes-Zustands zwischen den blauen und grünen Clustern.
T3: Umschalten des Datenverkehrs zum grünen Cluster.
T4: Zerstörendes blauen Clusters.

Sobald die neue Version live ist, wird er zum blauen Cluster für die nächste Änderung oder Aktualisierung.

Die blauen und grünen Cluster werden gleichzeitig ausgeführt, aber nur für einen begrenzten Zeitraum, was Kosten und Betriebsaufwand optimiert.

Übergangstrigger

Die Trigger für den Übergang von Phase zu Phase können automatisiert werden. Bis dies erreicht ist, sind einige oder alle davon manuell. Die Trigger beziehen sich auf:

Spezifische Workloadmetriken, Ziele für den Servicelevel (SLOs) und Vereinbarungen zum Servicelevel (SLAs): Diese werden hauptsächlich in Phase T3 verwendet, um den Gesamtzustand des AKS-Clusters zu überprüfen, bevor der Datenverkehr umgeschaltet wird.
Azure-Plattformmetriken: Diese werden verwendet, um den Status und die Integrität der Workloads und des AKS-Clusters zu bewerten. Sie werden bei allen Übergängen verwendet.

Netzwerkermittelbarkeit der Cluster

Sie können Netzwerkermittelbarkeit für die Cluster auf folgende Weise bereitstellen:

DNS-Einträge, die auf die Cluster verweisen. Zum Beispiel:
- aks-blue.contoso.com verweist auf die private oder öffentliche IP-Adresse des blauen Clusters.
- aks-green.contoso.com verweist auf die private oder öffentliche IP-Adresse des grünen Clusters.
Anschließend können Sie diese Hostnamen direkt oder in der Back-End-Pool-Konfiguration des Anwendungsgateways verwenden, das sich vor jedem Cluster befindet.
DNS-Einträge, die auf die Anwendungsgateways verweisen. Zum Beispiel:
- aks-blue.contoso.com verweist auf die private oder öffentliche IP-Adresse des Anwendungsgateways, dessen Back-End-Pool die private oder öffentliche IP-Adresse des blauen Clusters ist.
- aks-green.contoso.com verweist auf die private oder öffentliche IP-Adresse des Anwendungsgateways, dessen Back-End-Pool die private oder öffentliche IP-Adresse des grünen Clusters ist.

T0: Der blaue Cluster ist aktiviert

Die Erste Phase, T0, ist, dass der blaue Cluster live ist. In dieser Phase wird die neue Version des Clusters für die Bereitstellung vorbereitet.

Die Triggerbedingung für die Phase T1 ist die Freigabe einer neuen Version des Clusters, des grünen Clusters.

T1: Bereitstellen des grünen Clusters

In dieser Phase beginnt die Bereitstellung des neuen grünen Clusters. Der blaue Cluster bleibt aktiviert, und der Livedatenverkehr wird weiterhin an ihn weitergeleitet.

Der Trigger für den Übergang zur Phase T2 ist die Überprüfung des grünen AKS-Clusters auf Plattformebene. Die Überprüfung verwendet Azure Monitor-Metriken und CLI-Befehle, um die Integrität der Bereitstellung zu überprüfen. Weitere Informationen finden Sie unter Überwachen von Azure Kubernetes Service (AKS) mit Monitor und in der Referenz zur Überwachung von AKS-Daten.

Die AKS-Überwachung kann in verschiedene Ebenen unterteilt werden, wie im folgenden Diagramm dargestellt:

Die Integrität des Clusters wird auf den Ebenen 1 und 2 ausgewertet sowie in einem Teil von Ebene 3. Für Ebene 1 können Sie die native Multiclusteransicht von Monitor verwenden, um die Integrität zu überprüfen, wie hier gezeigt:

Stellen Sie auf Ebene 2 sicher, dass der Kubernetes-API-Server und Kubelet ordnungsgemäß funktionieren. Sie können die Kubelet-Arbeitsmappe in Monitor verwenden, insbesondere die beiden Raster der Arbeitsmappe, in denen wichtige Betriebsstatistiken der Knoten angezeigt werden:

Im Raster „Übersicht nach Knoten“ werden alle Vorgänge, alle Fehler und die erfolgreichen Vorgänge für jeden Knoten in Prozent und als Trend zusammengefasst.
Im Raster „Übersicht nach Vorgangstyp“ werden für jeden Vorgangstyp die Anzahl aller Vorgänge, aller Fehler und der erfolgreichen Vorgänge in Prozent und als Trend bereitgestellt.

Ebene 3 ist für die Kubernetes-Objekte und -Anwendungen vorgesehen, die standardmäßig in AKS bereitgestellt werden, z. B. omsagent, kube-proxy usw. Für diese Überprüfung können Sie die Insights-Ansicht von Monitor verwenden, um den Status der AKS-Bereitstellungen zu überprüfen:

Alternativ können Sie die dedizierte Arbeitsmappe verwenden, die in Bereitstellungs- und HPA-Metriken mit Containererkenntnissen dokumentiert ist. Ein Beispiel:

Nach erfolgreicher Überprüfung können Sie zur Phase T2 wechseln.

T2: Synchronisieren des Kubernetes-Zustands zwischen den blauen und grünen Clustern

In dieser Phase werden Anwendungen, Operatoren und Kubernetes-Ressourcen noch nicht im grünen Cluster bereitgestellt, oder zumindest nicht alle von ihnen sind anwendbar und bereitgestellt, wenn der AKS-Cluster bereitgestellt wird. Das endgültige Ziel dieser Phase ist, dass der grüne Cluster am Ende der Synchronisierung mit dem blauen Cluster abwärtskompatibel ist. Ist dies der Fall, ist es möglich, den Status des neuen Clusters zu überprüfen, bevor der Datenverkehr auf den grünen Cluster umgeschaltet wird.

Es gibt verschiedene Möglichkeiten, den Kubernetes-Zustand zwischen Clustern zu synchronisieren:

Erneute Bereitstellung mittels Continuous Integration und Continuous Delivery (CI/CD). In der Regel ist es ausreichend, dieselben CI/CD-Pipelines zu verwenden, die für die normale Bereitstellung der Apps verwendet werden. Gängige Tools hierfür sind: GitHub Actions, Azure DevOps und Jenkins.
GitOps mit Lösungen, die auf der Website der Cloud Native Computing Foundation (CNCF) beworben werden , z. B. Flux und ArgoCD.
Eine angepasste Lösung, die die Kubernetes-Konfigurationen und -Ressourcen in einem Datenspeicher speichert. In der Regel basieren diese Lösungen auf Kubernetes-Manifest-Generatoren, die mit Metadatendefinitionen beginnen und dann die generierten Kubernetes-Manifeste in einem Datenspeicher wie Azure Cosmos DB speichern. Hierbei handelt es sich in der Regel um benutzerdefinierte Lösungen, die auf dem Anwendungsbeschreibungs-Framework basieren, das verwendet wird.

Das folgende Diagramm zeigt den Prozess der Synchronisierung des Kubernetes-Zustands:

In der Regel ist die Bereitstellung neuer Anwendungen während der Synchronisierung im Livecluster nicht zulässig. Dieser Zeitraum beginnt mit der Synchronisierung und endet, wenn der Wechsel zum grünen Cluster abgeschlossen ist. Die Möglichkeit zum Deaktivieren von Bereitstellungen in Kubernetes kann variieren. Zwei mögliche Lösungen sind:

Deaktivieren der Bereitstellungspipelines.
Deaktivieren des Kubernetes-Dienstkontos, das Bereitstellungen ausführt.

Es ist möglich, die Deaktivierung des Dienstkontos mithilfe des Open Policy Agent (OPA) zu automatisieren. Es ist noch nicht möglich, hierfür native AKS-Features zu verwenden, da sie noch in der Vorschau sind.

Der Synchronisierungszeitraum kann vermieden werden, indem erweiterte Mechanismen verwendet werden, die den Kubernetes-Zustand in mehreren Clustern verwalten.

Nach Abschluss der Synchronisierung ist die Überprüfung des Clusters und der Anwendungen erforderlich. Dies schließt Folgendes ein:

Eine Überprüfung der Überwachungs- und Protokollierungsplattformen, um die Integrität des Clusters zu überprüfen. Sie können erwägen, das auszuführen, was Sie in der Phase T1: Bereitstellen des grünen Clusters tun.
Funktionstests der Anwendung, basierend auf der Toolkette, die derzeit verwendet wird.

Wir empfehlen, dass Sie außerdem eine Auslastungstestsitzung durchführen, um die Leistung der grünen Clusteranwendungen mit einer Leistungsbaseline zu vergleichen. Sie können Ihr bevorzugtes Tool oder Azure Load Testing verwenden.

Normalerweise wird der grüne Cluster am Anwendungsgateway oder über den externen Lastenausgleich mit einer internen URL verfügbar gemacht, die für externe Benutzer nicht sichtbar ist.

Nachdem der neue Cluster überprüft wurde, können Sie mit der nächsten Phase fortfahren, um den Datenverkehr zum neuen Cluster umzuschalten.

T3: Umschalten des Datenverkehrs zum grünen Cluster

Nachdem die Synchronisierung abgeschlossen und der grüne Cluster auf Plattform- und Anwendungsebene überprüft wurde, ist er bereit, um zum primären Cluster höhergestuft zu werden und mit dem Empfang des Livedatenverkehrs zu beginnen. Das Umschalten erfolgt auf Netzwerkebene. Häufig sind die Workloads zustandslos. Wenn die Workloads jedoch zustandsbehaftet sind, muss eine zusätzliche Lösung implementiert werden, um den Zustand und die Zwischenspeicherung während des Umschaltens aufrechtzuerhalten.

Nachfolgend sehen Sie ein Diagramm, das den Zielzustand nach Anwendung des Umschaltens zeigt:

Die in diesem Artikel beschriebenen Methoden implementieren vollständige Umschaltungen: 100 % des Datenverkehrs werden an den neuen Cluster weitergeleitet. Dies liegt daran, dass das Routing auf DNS-Ebene mit der Zuweisung eines A- oder CNAME-Eintrags angewendet wird, der so aktualisiert wird, dass er auf den grünen Cluster verweist, und es gibt ein Anwendungsgateway für jeden Cluster.

Hier sehen Sie ein Beispiel für die Konfiguration für das Umschalten privat zugänglicher Endpunkte. Die vorgeschlagene Lösung verwendet A-Einträge, um die Umschaltung zu vollziehen. Aus Sicht des DNS und der IP-Adressenzuordnung ist die Situation wie folgt vor dem Umschalten:

A-Eintrag aks.priv.contoso.com verweist auf die private IP-Adresse des blauen Anwendungsgateways.
A-Eintrag aks-blue.priv.contoso.com verweist auf die private IP-Adresse des blauen Anwendungsgateways.
A-Eintrag aks-green.priv.contoso.com verweist auf die private IP-Adresse des grünen Anwendungsgateways.

Durch die Umschaltung erfolgt eine Neukonfiguration auf Folgendes:

A-Eintrag aks.priv.contoso.com verweist auf die private IP-Adresse des grünen Anwendungsgateways.
A-Eintrag aks-blue.priv.contoso.com verweist auf die private IP-Adresse des blauen Anwendungsgateways.
A-Eintrag aks-green.priv.contoso.com verweist auf die private IP-Adresse des grünen Anwendungsgateways.

Die Benutzer der Cluster sehen die Umschaltung nach der Gültigkeitsdauer (Time-to-Live, TTL) und der DNS-Weitergabe der Einträge.

Für öffentlich zugängliche Endpunkte verwendet der empfohlene Ansatz Azure Front Door und Azure DNS. Die Konfiguration vor dem Umschalten ist wie folgt:

CNAME-Eintrag official-aks.contoso.com verweist auf einen Datensatz der automatisch generierten Azure Front Door-Domäne. Weitere Informationen finden Sie im Tutorial: Hinzufügen einer benutzerdefinierten Domäne für Ihre „Front Door“.
A-Eintrag aks.contoso.com verweist auf die öffentliche IP-Adresse des blauen Anwendungsgateways.
Die Azure Front Door-Ursprungskonfiguration verweist auf den aks.contoso.com-Hostnamen. Weitere Informationen zum Konfigurieren der Back-End-Pools finden Sie unter Ursprünge und Ursprungsgruppen in Azure Front Door.
- A-Eintrag aks-blue.contoso.com verweist auf die öffentliche IP-Adresse des blauen Anwendungsgateways.
- A-Eintrag aks-green.contoso.com verweist auf die öffentliche IP-Adresse des grünen Anwendungsgateways.

Durch die Umschaltung erfolgt eine Neukonfiguration auf Folgendes:

CNAME-Eintrag official-aks.contoso.com verweist auf einen Datensatz der automatisch generierten Azure Front Door-Domäne.
A-Eintrag aks.contoso.com verweist auf die öffentliche IP-Adresse des grünen Anwendungsgateways.
Die Azure Front Door-Ursprungskonfiguration verweist auf den aks.contoso.com-Hostnamen.
- A-Eintrag aks-blue.contoso.com verweist auf die öffentliche IP-Adresse des blauen Anwendungsgateways.
- A-Eintrag aks-green.contoso.com verweist auf die öffentliche IP-Adresse des grünen Anwendungsgateways.

Alternative Methoden für das Umschalten, z. B. teilweise Wechsel für Canary-Releases, sind mit zusätzlichen Azure-Diensten wie Azure Front Door oder Traffic Manager möglich. Eine Implementierung einer Blau-Grün-Datenverkehrsumschaltung auf Azure Front Door-Ebene finden Sie unter Blau-Grün-Bereitstellung mit Azure Front Door.

Wie im Beispiel beschrieben, basiert diese Methode aus Sicht des Netzwerks auf der Definition von vier Hostnamen:

Offizieller öffentlicher Hostname: Der offizielle öffentliche Hostname, der von Endbenutzern und Consumern verwendet wird.
Clusterhostname: Der offizielle Hostname, der von den Consumern der Workloads verwendet wird, die in den Clustern gehostet werden.
Hostname des blauen Clusters: Der dedizierte Hostname für den blauen Cluster.
Hostname des grünen Clusters: Der dedizierte Hostname für den grünen Cluster.

Der Clusterhostname ist der Name, der auf der Anwendungsgatewayebene konfiguriert wird, um den eingehenden Datenverkehr zu verwalten. Der Hostname ist auch Teil der AKS-Eingangskonfiguration, um Transport Layer Security (TLS) ordnungsgemäß zu verwalten. Dieser Host wird nur für Livetransaktionen und -anforderungen verwendet.

Wenn Azure Front Door auch Teil der Bereitstellung ist, ist es von der Umschaltung nicht betroffen, da es nur den offiziellen Clusterhostnamen verwaltet. Es stellt die ordnungsgemäße Abstraktion für die Anwendungsbenutzer bereit. Sie sind von der Umschaltung nicht betroffen, da der DNS-CNAME-Eintrag immer auf Azure Front Door verweist.

Die Hostnamen der blauen und grünen Cluster werden hauptsächlich verwendet, um die Cluster zu testen und zu überprüfen. Zu diesen Zwecken werden die Hostnamen auf Anwendungsgatewayebene mit dedizierten Endpunkten sowie auf der AKS-Eingangscontrollerebene verfügbar gemacht, um TLS ordnungsgemäß zu verwalten.

In dieser Phase basiert die Validierung auf den Infrastruktur- und App-Überwachungsmetriken sowie auf offiziellen SLO und SLA, sofern verfügbar. Wenn die Überprüfung erfolgreich verläuft, gehen Sie zur letzten Phase über, um den blauen Cluster zu zerstören.

T4: Zerstören des blauen Clusters

Die erfolgreiche Umschaltung des Datenverkehrs bringt uns erfolgreich zur letzten Phase, in der immer noch Validierungen und Überwachung stattfinden, um sicherzustellen, dass der grüne Cluster wie erwartet mit Livedatenverkehr funktioniert. Die Überprüfung und Überwachung decken sowohl Plattform- als auch Anwendungsebene ab.

Nach Abschluss dieser Überprüfung kann der blaue Cluster zerstört werden. Die Zerstörung ist ein Schritt, der dringend empfohlen wird, um Kosten zu reduzieren und die von Azure, insbesondere von AKS, bereitgestellten Flexibilität adäquat zu nutzen.

Im Folgenden sehen Sie die Situation, nachdem der blaue Cluster zerstört wurde:

Komponenten

Application Gateway ist ein Lastenausgleich für Webdatenverkehr auf Schicht 7, mit dem Sie eingehenden Datenverkehr für Ihre Webanwendungen verwalten können. In dieser Lösung wird es als Gateway für HTTP-Datenverkehr für den Zugriff auf die AKS-Cluster verwendet.
Azure Kubernetes Service (AKS) ist ein Managed Kubernetes-Dienst, den Sie für die Bereitstellung und Verwaltung von containerisierten Anwendungen nutzen können. Diese Anwendungsplattform ist die Standardkomponente dieses Musters.
Azure Container Registry ist ein verwalteter Dienst, der zum Speichern und Verwalten von Containerimages und zugehörigen Artefakten verwendet wird. In dieser Lösung werden Containerimages und Artefakte, wie Helm-Diagramme, in den AKS-Clustern gespeichert und verteilt.
Azure Monitor ist eine Überwachungslösung für die Sammlung, Analyse und Reaktion auf die Überwachung von Daten aus Ihren Cloudumgebungen und lokalen Umgebungen. Sie stellt die wichtigsten Überwachungsfeatures bereit, die zum Ausführen der Blau-Grün-Bereitstellung erforderlich sind. Die Lösung wird aufgrund ihrer Integration in AKS und der Fähigkeit zur Bereitstellung von Protokollierungs-, Überwachungs- und Warnfunktionen, die zum Verwalten der Phasenübergänge genutzt werden können, in dieser Architektur verwendet.
Azure Key Vault hilft bei der Lösung der Probleme in den folgenden Bereichen: Geheimnisverwaltung, Schlüsselverwaltung und Zertifikatverwaltung. Es wird verwendet, um die für diese Lösung erforderlichen Geheimnisse und Zertifikate auf Plattform- und Anwendungsebene zu speichern und zu verwalten.
Azure Front Door ist ein globales Load Balancer- und Anwendungsendpunkt-Verwaltungssystem. Es wird in dieser Lösung als öffentlicher Endpunkt für HTTP-Anwendungen verwendet, die auf AKS gehostet werden. In dieser Lösung trägt es die entscheidende Verantwortung für die Verwaltung der Datenverkehrsumschaltung zwischen den blauen und grünen Application Gateways.
Azure DNS ist ein Hostingdienst für DNS-Domänen, der eine Namensauflösung mittels Microsoft Azure-Infrastruktur bietet. Es verwaltet die Hostnamen, die in der Lösung für blaue und grüne Cluster verwendet werden, und spielt eine wichtige Rolle bei den Datenverkehrsumschaltungen, insbesondere für private Endpunkte.

Alternativen

Es gibt alternative Methoden für die Implementierung der Datenverkehrsumschaltungen, die mehr Kontrolle bieten können. Beispielsweise ist es möglich, eine teilweise Umschaltung mithilfe von Datenverkehrsregeln vorzunehmen, die auf einem oder mehreren der folgenden Aspekte basieren:
- Prozentsatz des eingehenden Datenverkehrs
- HTTP-Header
- Cookies
Eine weitere Alternative, die größeren Schutz vor Problemen bietet, die durch Änderungen verursacht werden, besteht darin, ringbasierte Bereitstellungen vorzunehmen. Anstatt nur blaue und grüne Cluster zu verwenden, ist es möglich, mehr Cluster einzusetzen, sogenannte „Ringe“. Jeder Ring ist groß genug für die Anzahl der Benutzer, die Zugriff auf die neue Version von AKS haben. Wie bei der hier beschriebenen Blau-Grün-Bereitstellung können die Ringe entfernt werden, um die richtige Kostenoptimierung und -kontrolle zu erzielen.
Mögliche Alternativen zu Application Gateway sind NGINX und HAProxy.
Eine mögliche Alternative zu Container Registry ist Harbor.
Unter bestimmten Umständen ist es möglich, anstelle von Azure Front Door und Azure DNS andere Lastenausgleichs- und DNS-Dienste zu verwenden, um die Datenverkehrsumschaltung vorzunehmen.
Diese Lösung basiert auf den eingehenden Standardcontroller-Kubernetes-APIs. Wenn Ihre Lösung stattdessen von der Gateway-API profitieren würde, verwenden Sie das Application Gateway für Container. Es kann helfen, den Lastenausgleich zu verwalten und den eingehenden Datenverkehr zwischen dem Application Gateway und den Pods zu behandeln. Das Application Gateway für Container steuert die Einstellungen der Application Gateways.

Szenariodetails

Die Hauptvorteile der Lösung sind:

Minimierte Ausfallzeiten während der Bereitstellung.
Geplante Rollbackstrategie.
Verbesserte/r Kontrolle und Betrieb während Release und Bereitstellung von AKS-Änderungen und -Upgrades.
Testen der Notwendigkeit zur Ausführung von Notfallwiederherstellungsverfahren (DR).

Die wichtigsten Grundsätze und grundlegenden Aspekte einer Blau-Grün-Bereitstellung werden in den folgenden Artikeln behandelt:

Aus Sicht von Automatisierung und CI/CD kann die Lösung auf mehrere Arten implementiert werden. Unsere Empfehlung:

Bicep oder Terraform für IaC.
Azure Pipelines oder GitHub Actions für CI/CD.

Mögliche Anwendungsfälle

Die Blau-Grün-Bereitstellung ermöglicht es, Änderungen an Clustern vorzunehmen, ohne dass sich diese auf die ausgeführten Anwendungen und Workloads auswirken. Beispiele für Änderungen sind:

Betriebsänderungen
Aktivieren neuer AKS-Features.
Änderungen an gemeinsam genutzten Ressourcen in den Clustern.
Aktualisieren der Kubernetes-Version.
Ändern von Kubernetes-Ressourcen und -Objekten wie dem Eingangsgateway, dem Service Mesh (Dienstnetz), Operatoren, Netzwerkrichtlinien usw.
Ausführen eines Rollbacks auf die vorherige Version eines AKS-Clusters, der noch bereitgestellt ist, ohne die im Cluster ausgeführten Workloads zu beeinträchtigen.

Ü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.

Eine Blau-Grün-Bereitstellung kann vollständig automatisiert werden, z. B. eine Zero-Touch-Bereitstellung. In der Regel verfügt eine Anfangsimplementierung über manuelle Trigger zur Aktivierung der Phasen. Auf dem Weg und mit den richtigen Reife- und Überwachungsfeatures ist es möglich, die Trigger zu automatisieren. Dies bedeutet, dass es automatisierte Tests und spezifische Metriken, SLA und SLO, gibt, um die Trigger zu automatisieren.
Es ist wichtig, dedizierte Hostnamen für die blauen und grünen Cluster zu haben und auch dedizierte Endpunktkonfigurationen auf den Gateways und Lastenausgleichsmodulen, die sich vor den Clustern befinden. Dies ist von kritischer Bedeutung, um die Zuverlässigkeit und Gültigkeit der Bereitstellung des neuen Clusters zu verbessern. Auf diese Weise erfolgt die Überprüfung der Bereitstellung mit derselben Architektur und denselben Konfigurationen wie denen eines Standardproduktionsclusters.
Stellen Sie sich eine Situation vor, in der die AKS-Cluster freigegebene Ressourcen für mehrere Anwendungen sind, die von verschiedenen Geschäftseinheiten verwaltet werden. In solchen Fällen ist es üblich, dass die AKS-Plattform selbst von einem dedizierten Team verwaltet wird, das für den gesamten Betrieb und Lebenszyklus der Cluster verantwortlich ist, und dass es Endpunkte in den Clustern für Administrations- und Betriebszwecke gibt. Wir empfehlen, dass diese Endpunkte über einen dedizierten Eingangsdatencontroller in den AKS-Clustern verfügen, um eine saubere Trennung der Belange sowie Zuverlässigkeit zu gewährleisten.
Eine Blau-Grün-Bereitstellung ist nützlich für die Implementierung und das Testen von Geschäftskontinuitäts- und Notfallwiederherstellungslösungen (BC/DR) für AKS und verwandte Workloads. Sie stellt insbesondere die grundlegenden Strukturen zum Verwalten mehrerer Cluster bereit, einschließlich Fällen, in denen die Cluster auf mehrere Regionen verteilt sind.
Der Erfolg einer Blau-Grün-Bereitstellung basiert auf der Anwendung aller Aspekte der Implementierung wie Automatisierung, Überwachung und Validierung, nicht nur auf der AKS-Plattform, sondern auch in den Workloads und Apps, die auf der Plattform bereitgestellt werden. Diese Vorgehensweise hilft Ihnen dabei, maximal von der Blau-Grün-Bereitstellung zu profitieren.
In der vorgeschlagenen Lösung gibt es zwei Application Gateways pro Szenario, öffentlich und privat, also insgesamt vier. Diese Entscheidung besteht darin, die Blau-Grün-Bereitstellung auf der Azure Application Gateway-Ebene anzuwenden, um Ausfallzeiten zu vermeiden, die durch fehlkonfigurierte Gateways verursacht werden. Der größte Nachteil dieser Entscheidung sind die Kosten, da es vier Application Gateway-Instanzen gibt. Sie werden nur in dem Zeitraum parallel ausgeführt, in dem relevante Änderungen an den Application Gateway-Konfigurationen vorhanden sind, z. B. WAF-Richtlinien oder eine Skalierungskonfiguration. Für eine weitere Kostenoptimierung können Sie sich für ein einzelnes Application Gateway pro Szenario entscheiden, was insgesamt zwei Application Gateways bedeutet. Dies erfordert, dass Sie die blaue/grüne Logik in das Application Gateway statt in Azure Front Door verschieben. Azure Front Door wird also nicht zwingend kontrolliert, sondern das Application Gateway.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass die Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Eine Blau-Grün-Bereitstellung hat einen direkten und positiven Effekt auf die Verfügbarkeit der AKS-Plattform und -Workloads. Insbesondere erhöht sie die Verfügbarkeit während der Bereitstellung von AKS-Plattformänderungen. Wenn Benutzersitzungen gut verwaltet werden, kommt es nur zu wenigen Ausfallzeiten.
Die Blau-Grün-Bereitstellung bietet während der Bereitstellung hohe Zuverlässigkeit, da standardmäßig die Möglichkeit besteht, ein Rollback auf die vorherige Version des AKS-Clusters auszuführen, wenn in der neuen Clusterversion etwas schief läuft.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Das Prinzip der Blau-Grün-Bereitstellung wird in Azure aufgrund der nativen Elastizität, die von der Cloud bereitgestellt wird, weit verbreitet eingesetzt. Dies ermöglicht es, Kosten hinsichtlich Betrieb und Ressourcenverbrauch zu optimieren. Die meisten Einsparungen ergeben sich aus dem Entfernen des Clusters, der nach der erfolgreichen Bereitstellung einer neuen Version des Clusters nicht mehr benötigt wird.
Wenn eine neue Version bereitgestellt wird, ist es normale, sowohl die blauen als auch die grünen Cluster im selben Subnetz zu hosten, um weiterhin dieselbe Kostenbaseline zu haben. Alle Netzwerkverbindungen und der Zugriff auf die Ressourcen und Dienste sind für die beiden Cluster identisch, und alle Azure-Dienste und -Ressourcen bleiben gleich.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Eine Blau-Grün-Bereitstellung, ordnungsgemäß implementiert, bietet Automatisierung, Continuous Delivery und resiliente Bereitstellung.
Eine der wichtigsten Aspekte der Continuous Delivery besteht darin, dass sie iterativ Inkremente von Plattform- und Workloadänderungen liefert. Mit der Blau-Grün-Bereitstellung von AKS erreichen Sie Continuous Delivery auf Plattformebene, auf kontrollierte und sichere Weise.
Resilienz ist grundlegend für die Blau-Grün-Bereitstellung, da sie die Option zum Rollback auf den vorherigen Cluster enthält.
Die Blau-Grün-Bereitstellung bietet die geeignete Automatisierungsstufe, um den Aufwand im Zusammenhang mit der Geschäftskontinuitätsstrategie zu verringern.
Die Überwachung der Plattform und der Apps ist für eine erfolgreiche Implementierung von entscheidender Bedeutung. Die Plattform kann die nativen Azure-Überwachungsfunktionen verwenden. Für die Apps muss die Überwachung entworfen und implementiert werden.

Bereitstellen dieses Szenarios

Ein implementiertes Beispiel für eine in diesem Leitfaden beschriebene Blau-Grün-Bereitstellung finden Sie unter Beschleuniger für AKS-Zielzonen.

Diese Referenzimplementierung basiert auf Application Gateway und dem Application Gateway-Eingangsdatencontroller (AGIC). Jeder Cluster verfügt über ein eigenes Anwendungsgateway und die Datenverkehrsumschaltung erfolgt über DNS, insbesondere über die Konfiguration von CNAME.

Wichtig

Für unternehmenskritische Workloads ist es wichtig, Blau-Grün-Bereitstellungen, wie in diesem Leitfaden beschrieben, mit Bereitstellungsautomatisierung und kontinuierlicher Validierung zu kombinieren, um Bereitstellungen ohne Downtime zu erreichen. Weitere Informationen und Anleitungen finden Sie in der unternehmenskritischen Entwurfsmethodik.

Überlegungen zu Regionen

Sie können die blauen und grünen Cluster für separate Regionen oder in derselben Region bereitstellen. Die Entwurfs- und Betriebsprinzipien sind von dieser Wahl nicht betroffen. Bestimmte Arten zusätzlicher Netzwerkkonfigurationen können davon jedoch betroffen sein, z. B.:

Ein dediziertes virtuelles Netzwerk und Subnetz für AKS und das Anwendungsgateway.
Verbindung mit Unterstützungsdiensten wie Monitor, Containerregistrierung und Key Vault.
Azure Front Door-Sichtbarkeit des Anwendungsgateways.

Es gibt Voraussetzungen für die Bereitstellung in derselben Region:

Die Größe der virtuellen Netzwerke und Subnetze muss auf das Hosten von zwei Clustern ausgelegt sein.
Das Azure-Abonnement muss ausreichende Kapazität für die beiden Cluster bereitstellen.

Bereitstellung des Eingangsdatencontrollers und externer Lastenausgleichsmodule

Es gibt verschiedene Ansätze zur Bereitstellung des Eingangsdatencontrollers und externer Lastenausgleichsmodule:

Sie können einen einzelnen Eingangsdatencontroller mit einem dedizierten externen Lastausgleich einsetzen, wie bei der Referenzimplementierung der in diesem Leitfaden beschriebenen Architektur. AGIC ist eine Kubernetes-Anwendung, die es ermöglicht, den Application Gateway L7 Load Balancer zu verwenden, um Cloudsoftware im Internet verfügbar zu machen. In bestimmten Szenarien gibt es Administratorendpunkte in den AKS-Clustern zusätzlich zu den Anwendungsendpunkten. Die Administratorendpunkte dienen zum Ausführen von operativen Aufgaben an den Anwendungen oder für Konfigurationsaufgaben wie das Aktualisieren von Konfigurationszuordnungen, Geheimnissen, Netzwerkrichtlinien und Manifesten.
Sie können über einen einzelnen externen Lastenausgleich verfügen, der mehrere Eingangsdatencontroller bedient, die auf demselben Cluster oder auf mehreren Clustern bereitgestellt sind. Dieser Ansatz wird von der Referenzimplementierung nicht abgedeckt. In diesem Szenario empfehlen wir, separate Anwendungsgateways für öffentlich zugängliche und für privat zugängliche Endpunkte zu haben.
Die daraus resultierende Architektur, die in diesem Leitfaden vorgeschlagen und dargestellt wird, basiert auf einem Standard-Eingangsdatencontroller, der als Teil des AKS-Clusters eingesetzt wird, wie NGINX und Envoy based ones. In der Referenzimplementierung verwenden wir AGIC, was bedeutet, dass es eine direkte Verbindung zwischen dem Anwendungsgateway und den AKS-Pods gibt, doch dies wirkt sich nicht auf die Blau-Grün-Architektur insgesamt aus.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Vincenzo Morra | SAO Incubation Architect

Andere Mitwirkende:

Oscar Pla Alvarez | Domain Solution Architect

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Freigeben über

Blau-Grün-Bereitstellung von AKS-Clustern