Migrieren von einem Application Gateway-Eingangsdatencontroller (Application Gateway Ingress Controller, AGIC) zu Application Gateway für Container

Application Gateway-Eingangsdatencontroller (Application Gateway Ingress Controller, AGIC) und Application Gateway für Container sind zwei Lösungen, die den Anwendungslastenausgleich für Azure Kubernetes Service (AKS)-Dienste ermöglichen. Im Jahr 2018 wurde für Application Gateway der Application Gateway-Eingangscontroller eingeführt, der Kubernetes-Eingangskonfigurationen in Application Gateway-Konfigurationen übersetzte. Im Laufe der Zeit hat Kubernetes die Anforderungen an Skalierung und Leistung priorisiert und eine Nachfolger-API für den Dateneingang eingeführt: die Gateway-API. Dies hat zur Einführung von Application Gateway für Container geführt.

Application Gateway für Container ist die nächste Entwicklungsstufe des Application Gateway-Eingangsdatencontrollers und bietet u. a. folgende Vorteile:

• Höhere Leistung mit nahezu echtzeitbasierten Updates zum Hinzufügen oder Verschieben von Pods, Routen und Tests
• Datenverkehrsaufteilung/Gewichtetes Roundrobin
• Kubernetes-Gateway und Ingress-API
• Konfiguration über Azure oder Kubernetes

Mit den bereitgestellten Verbesserungen empfehlen wir Ihnen, den Übergang vom Application Gateway-Dateneingangscontroller zu Application Gateway für Container zu beginnen.

Migrationsziele

Die Migration zu Application Gateway für Container wurde für drei Ziele entwickelt:

• Ermöglichen eines inkrementellen Migrationsansatzes
• Ermöglichen einer End-to-End-Überprüfung vor der Migration
• Sicherstellen, dass keine Downtimes auftreten

Dieser Artikel enthält eine Übersicht über die Migrationsstrategie. Sehen Sie sich die folgende Abbildung an:

Im dargestellten Beispiel sind Application Gateway für Container und der Application Gateway-Eingangsdatencontroller beides Dienst-Back-End-Ziele mit eindeutigen Front-Ends. Nach der Bestätigung, dass Application Gateway für Container erwartungsgemäß funktioniert, kann der Datenverkehr ausschließlich an das Application Gateway für Container-Front-End geleitet werden, und die Konfiguration mit dem Application Gateway-Eingangsdatencontroller kann eingestellt werden.

Featureabhängigkeiten und Zuordnungen

Vor der Migration ist es wichtig, alle Abhängigkeiten vom Application Gateway-Eingangsdatencontroller zu identifizieren, die möglicherweise in Application Gateway für Container noch nicht verfügbar sind. Workloads mit Abhängigkeiten von diesen Features sollten später in Ihrer Migrationsstrategie priorisiert werden, wenn diese Funktionen in Application Gateway für Container entsperrt werden.

Zu den Abhängigkeiten gehören:

• Web Application Firewall (WAF)
• Private IP-Adresse
• Andere Ports als 80 und 443
• Konfigurierbare Anforderungstimeoutwerte

Hier ist eine zusammengefasste Liste der AGIC-Anmerkungen und ob Application Gateway für Container diese Funktionen entweder in die Gateway-oder Ingress-API übersetzt hat.

Szenario	AGIC-Anmerkung	Gateway-API-Implementierung	Ingress-API-Implementierung
Pfadüberschreibung zum Back-End-Ziel	appgw.ingress.kubernetes.io/backend-path-prefix	URL-Rewrite für Gateway-API	URL-Rewrite für Ingress-API
Pfadüberschreibung zum Back-End-Ziel	appgw.ingress.kubernetes.io/backend-hostname	URL-Rewrite für Gateway-API	URL-Rewrite für Ingress-API
Pfadüberschreibung zum Back-End-Ziel	appgw.ingress.kubernetes.io/backend-protocol	URL-Rewrite für Gateway-API	URL-Rewrite für Ingress-API
HTTP-zu-HTTPS-Umleitung	appgw.ingress.kubernetes.io/ssl-redirect	URL-Umleitung für Gateway-API	URL-Umleitung für Ingress-API
Front-End-TLS-Zertifikat	appgw.ingress.kubernetes.io/appgw-ssl-certificate	Unterstützt	Unterstützt
Frontend-TLS-Richtlinie / SSL-Profil	appgw.ingress.kubernetes.io/appgw-ssl-profile	Front-End-TLS-Richtlinie in Gateway-API	Nicht unterstützt
Einrichten der Back-End-Kettenvertrauensstellung für Zertifikate	appgw.ingress.kubernetes.io/appgw-trusted-root-certificate	Unterstützt	Unterstützt
Verbindungsausgleich	appgw.ingress.kubernetes.io/connection-draining	Nicht konfigurierbar	Nicht konfigurierbar
Verbindungsausgleich	appgw.ingress.kubernetes.io/connection-draining-timeout	Nicht konfigurierbar	Nicht konfigurierbar
Sitzungsaffinität / persistente Sitzungen	appgw.ingress.kubernetes.io/cookie-based-affinity	Sitzungsaffinität in Gateway-API	Sitzungsaffinität in Ingress-API
Anforderungstimeout	appgw.ingress.kubernetes.io/request-timeout	Nicht konfigurierbar	Nicht konfigurierbar
Front-End-Port außer 80 und 443	appgw.ingress.kubernetes.io/override-frontend-port	Nicht unterstützt	Nicht unterstützt
Privates Front-End	appgw.ingress.kubernetes.io/use-private-ip	Nicht unterstützt	Nicht unterstützt
WAF	appgw.ingress.kubernetes.io/waf-policy-for-path	Nicht unterstützt	Nicht unterstützt
Benutzerdefinierter Integritätstest	appgw.ingress.kubernetes.io/health-probe-hostname	HealthCheckPolicy	HealthCheckPolicy
Benutzerdefinierter Integritätstest	appgw.ingress.kubernetes.io/health-probe-port	HealthCheckPolicy	HealthCheckPolicy
Benutzerdefinierter Integritätstest	appgw.ingress.kubernetes.io/health-probe-path	HealthCheckPolicy	HealthCheckPolicy
Benutzerdefinierter Integritätstest	appgw.ingress.kubernetes.io/health-probe-status-codes	HealthCheckPolicy	HealthCheckPolicy
Benutzerdefinierter Integritätstest	appgw.ingress.kubernetes.io/health-probe-interval	HealthCheckPolicy	HealthCheckPolicy
Benutzerdefinierter Integritätstest	appgw.ingress.kubernetes.io/health-probe-timeout	HealthCheckPolicy	HealthCheckPolicy
Benutzerdefinierter Integritätstest	appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold	HealthCheckPolicy	HealthCheckPolicy
Header-Umschreiben	appgw.ingress.kubernetes.io/rewrite-rule-set	Header-Umschreiben in Gateway-API	Header-Umschreiben in Ingress-API
Header-Umschreiben	appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource	Header-Umschreiben in Gateway-API	Header-Umschreiben in Ingress-API
Header-Umschreiben	appgw.ingress.kubernetes.io/hostname-extension	Header-Umschreiben in Gateway-API	Header-Umschreiben in Ingress-API

Migrationserfahrung und was Sie erwarten können

Die Migration vom Application Gateway-Eingangsdatencontroller zu Application Gateway für Container ist ein vierstufiger Prozess:

Schritt 1: Deinstallieren von Application Gateway für Container und ALB-Controller
Schritt 2: Übersetzen von eingehendem AGIC-Datenverkehr in eingehenden Application Gateway für Container-Datenverkehr
Schritt 3: Durchführen von End-to-End-Tests für Application Gateway für Container
Schritt 4: Weiterleiten von Datenverkehr von AGIC zu Application Gateway für Container

Die Schritte 2 bis 4 werden für jeden Dienst wiederholt, den Sie migrieren möchten.

Schritt 1: Installieren des ALB-Controllers

Der erste Schritt der Migration besteht darin, sicherzustellen, dass der ALB-Controller für Application Gateway für Container installiert ist und ausgeführt wird. Überprüfen Sie, ob sowohl der Application Gateway-Eingangsdatencontroller als auch der ALB-Controller für Application Gateway für Container parallel auf demselben Cluster ausgeführt werden können.

Anweisungen zum Bereitstellen des ALB-Controllers finden Sie im Artikel zum Installieren des ALB-Controllers für Application Gateway für Container.

Schritt 2: Übersetzen des Eingangs

Application Gateway für Container hat die Implementierung so ausgerichtet, dass nativ die Ingress- oder Gateway-API verwendet wird, sofern möglich. In Fällen, in denen zusätzliche Funktionen erforderlich sind, aber nicht von der API bereitgestellt werden, werden benutzerdefinierte Ressourcen anstelle von Anmerkungen angewendet.

Eine Liste der AGIC-Anmerkungen und deren entsprechende Implementierung in der Ingress- oder Gateway-API finden Sie im Abschnitt Anmerkungen dieses Artikels.

Schritt 3: Durchführen der End-to-End-Überprüfung

Clientdatenverkehr geht auf einer Front-End-Ressource von Application Gateway für Container ein. Jedes Front-End verfügt über Kardinalität zu einer Gateway- oder Ingress-Ressource. Nachdem die Konfiguration in Ihren Gateway- oder Ingress-Ressourcen definiert wurde, identifizieren Sie das richtige Front-End.

Überprüfen Sie die Ingress- und Gateway-Einrichtung mithilfe einer Hostdatei oder eines DNS-Eintrags, um den Fluss des Datenverkehrs zu Application Gateway für Container zu testen. Stellen Sie sicher, dass der Datenverkehr vom Client zum Back-End über Application Gateway für Container fließen kann und dass alle Anforderungen und Antworten die erwarteten Header, Umleitungen und Routingbedingungen aufweisen.

Schritt 4: Weiterleiten von Datenverkehr zu Application Gateway für Container

Nachdem Sie die End-to-End-Tests abgeschlossen haben, leiten Sie den Datenverkehr an Application Gateway für Container weiter. Aktualisieren Sie öffentliche DNS-Einträge, sodass sie auf den Front-End-A-Eintrag von Application Gateway für Container verweisen. In den meisten Fällen erfolgt dies in Form eines CNAME-Eintrags oder, bei Angabe eines Apex-Domänennamens, eines Alias-Eintrags. Planen Sie Zeit ein, damit der Datenverkehr auf natürliche Weise zum Application Gateway für Container-Front-End fließen kann.

Tipp

• Identifizieren Sie vor der Migration die Gültigkeitsdauer (Time to Live, TTL) des DNS-Eintrags, der derzeit Datenverkehr zum Front-End von Application Gateway verarbeitet. Stellen Sie sicher, dass die Zeit, die in Application Gateway für den Verbindungsausgleich konfiguriert wurde, verstrichen ist, um zu gewährleisten, dass alle Clients den neuen DNS-Eintrag für Application Gateway für Container aufgelöst haben, bevor die Ingress/Gateway-Konfiguration auf AGIC eingestellt wird.
• Erwägen Sie, die Migration während einer Zeit mit wenig Datenverkehr durchzuführen, um die Überprüfung zu erleichtern.
• Wenn die Migration nicht wie erwartet funktioniert, setzen Sie den DNS-Eintrag so zurück, dass er auf das Application Gateway-Front-End verweist, und wiederholen Sie den Prozess.

Schritt 5: Kennzeichnen des Application Gateway-Eingangsdatencontrollers als veraltet

Nachdem alle Dienste migriert wurden, können Sie den Application Gateway-Eingangsdatencontroller als veraltet kennzeichnen.

Entfernen von Eingangsressourcen

Entfernen Sie jede Ingress-Ressource, die auf den Application Gateway-Eingangsdatencontroller mit der Anmerkung kubernetes.io/ingress.class: azure/application-gateway verweist oder ingressClassName als azure-application-gateway definiert.

kubectl delete ingress your-ingress-name -n your-ingress-namespace

AGIC-Add-On

Wenn Sie das AGIC-Add-On verwenden, können Sie es löschen, indem Sie Folgendes ausführen:

az aks disable-addons -n <AKS-cluster-name> -g <AKS-resource-group-name> -a ingress-appgw

Helm-Bereitstellungen

Wenn AGIC über Helm bereitgestellt wurde, können Sie den Controller deinstallieren, indem Sie Folgendes ausführen:

helm uninstall ingress-azure

Bereinigen von Azure-Ressourcen

Nachdem der Eingangscontroller entfernt wurde, müssen Sie die Application Gateway-Ressource löschen.

Hinweis

Wenn das Aks-Add-On im Kontext des Verweises auf ein zuvor bereitgestelltes Anwendungsgateway in Azure bereitgestellt wurde, müssen Sie die Application Gateway-Ressource manuell löschen.

Anmerkungen

Die folgenden Anmerkungen des Application Gateway-Eingangsdatencontrollers und die entsprechende Implementierung in Application Gateway für Container lauten wie folgt.

Pfadüberschreibung zum Back-End-Ziel

AGIC-Anmerkungen

• appgw.ingress.kubernetes.io/backend-path-prefix
• appgw.ingress.kubernetes.io/backend-hostname
• appgw.ingress.kubernetes.io/backend-protocol

Implementierung von Application Gateway für Container

Verwenden Sie für Anforderungen, die den Back-End-Zielpfad umschreiben, die URL-Umschreibungsfunktionen von Application Gateway für Container.

URL-Rewrite für Gateway-API

In der Gateway-API müssen Sie eine HTTPRoute-Ressource definieren, die über einen Filter für den URLRewrite-Pfad verfügt.

URL-Rewrite für Ingress-API

In der Ingress-API müssen Sie eine IngressExtension-Ressource und eine Umschreibung mit ReplacePrefixMatch definieren.

Umleiten

AGIC-Anmerkungen

• appgw.ingress.kubernetes.io/ssl-redirect

Implementierung von Application Gateway für Container

Verwenden Sie für Anforderungen, die von Port 80 zu 443 für HTTPS umgeleitet werden sollen, die URL-Umleitungsunterstützung in Application Gateway für Container.

URL-Umleitung für Gateway-API

In der Gateway-API müssen Sie eine Gatewayressource definieren, die sowohl auf Port 80 als auch auf 443 lauscht. Darüber hinaus werden zwei HTTPRoute-Ressourcen erstellt, eine zum Überwachen und Verarbeiten von Datenverkehr auf 443 und eine andere, um die Umleitung für den Datenverkehr auszulösen, der auf Port 80 empfangen wurde.

URL-Umleitung für Ingress-API

In der Ingress-API müssen Sie eine IngressExtension-Ressource mit einer Regel definieren, die eine requestRedirect mit einem scheme-Wert von https definiert. Insgesamt müssen zwei Ingress-Ressourcen definiert werden, eine für die Überwachung von Port 80 auf die HTTP-Anforderung, um eine Umleitung auszulösen, und eine für die Überwachung von Port 443 für die Verarbeitung von HTTPS-Anforderungen.

SSL-Zertifikate in der Gateway-API

Verweisen Sie in der Gateway-API auf das Zertifikat ihrer Gatewayressource.

tls:
  mode: Terminate
  certificateRefs:
  - kind : Secret
    group: ""
    name: listener-tls-secret

SSL-Zertifikate in der Ingress-API

Verwenden Sie in der Ingress-API die TLS-Eigenschaft, z. B.

tls:
- hosts:
    - example.com
    secretName: listener-tls-secret

Front-End-TLS-Zertifikat

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/appgw-ssl-certificate

Implementierung von Application Gateway für Container

Direktes Hochladen und Verweisen auf ein Zertifikat in Azure Key Vault sind nicht verfügbar.

Geheime Schlüssel sollten im AKS-Geheimnisspeicher gespeichert und anhand des Namens referenziert werden.

Einrichten der Back-End-Kettenvertrauensstellung für Zertifikate

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/appgw-trusted-root-certificate

Implementierung von Application Gateway für Container

In der Gateway- und der Ingress-API können Sie die benutzerdefinierte Back-EndTLSPolicy-Ressource verwenden, um Ihre eigene Zertifizierungsstelle zu definieren und damit die Kettenvertrauensstellung für das vom Back-End-Dienst verwendete Zertifikat herzustellen.

Frontend-TLS-Richtlinie / SSL-Profil

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/appgw-ssl-profile

Implementierung von Application Gateway für Container

Application Gateway für Container ermöglicht es Kunden, auf vordefinierte TLS-Richtlinien zu verweisen, um den Umfang der vom Client ausgehandelten Verschlüsselungen mit dem Front-End von Application Gateway für Container zu steuern.

Front-End-TLS-Richtlinie in Gateway-API

Um dieses Feature zu nutzen, müssen Sie die Gateway-API verwenden. Weitere Details zur TLS-Richtlinie finden Sie hier.

Hinweis

Die vordefinierten Richtliniennamen und Verschlüsselungssammlungen unterscheiden sich vom Application Gateway-Eingangsdatencontroller. Weitere Informationen finden Sie in der Tabelle der vordefinierten TLS-Richtlinien.

Front-End-TLS-Richtlinie in Ingress-API

Die benutzerdefinierte TLS-Richtlinie wird derzeit von Application Gateway für Container nicht unterstützt.

Sitzungsaffinität

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/cookie-based-affinity

Implementierung von Application Gateway für Container

Application Gateway für Container unterstützt die Sitzungsaffinität über Cookies sowohl für die Gateway- als auch für die Ingress-API.

Sitzungsaffinität in Gateway-API

Definieren Sie in der Gateway-API eine RoutePolicy-Ressource mit Eigenschaften im Zusammenhang mit sessionAffinity.

Sitzungsaffinität in Ingress-API

Definieren Sie in der Ingress-API eine IngressExtension-Ressource mit Eigenschaften im Zusammenhang mit sessionAffinity.

Weitere Details zum Konfigurieren von Application Gateway für Container mit Sitzungsaffinität finden Sie hier: Sitzungsaffinität.

Privates Front-End

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/use-private-ip

Implementierung von Application Gateway für Container

Ein privates IP-Front-End wird derzeit von Application Gateway für Container nicht unterstützt.

WAF

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/waf-policy-for-path

Implementierung von Application Gateway für Container

WAF wird von Application Gateaway für Container nicht unterstützt.

Benutzerdefinierte Integritätstests

AGIC-Anmerkungen

• appgw.ingress.kubernetes.io/health-probe-hostname
• appgw.ingress.kubernetes.io/health-probe-port
• appgw.ingress.kubernetes.io/health-probe-path
• appgw.ingress.kubernetes.io/health-probe-status-codes
• appgw.ingress.kubernetes.io/health-probe-interval
• appgw.ingress.kubernetes.io/health-probe-timeout
• appgw.ingress.kubernetes.io/health-probe-unhealthy-threshold

Implementierung von Application Gateway für Container

HealthCheckPolicy

Für die Gateway- und die Ingress-API ist die Entsprechung eine neue HealthCheckPolicy-Ressource. Weitere Details finden Sie im Dokument zu benutzerdefinierten Integritätstests.

Erneutes Generieren von Headern

AGIC-Anmerkungen

• appgw.ingress.kubernetes.io/rewrite-rule-set
• appgw.ingress.kubernetes.io/rewrite-rule-set-custom-resource
• appgw.ingress.kubernetes.io/hostname-extension

Implementierung von Application Gateway für Container

Header-Umschreiben in Gateway-API

In der Gateway-API definieren Sie eine RequestHeaderModifer-Übereinstimmung und einen Filter, um die Anforderung umzuschreiben.

Header-Umschreiben in Ingress-API

Definieren Sie in der Ingress-API eine IngressExtension-Ressource mit einer Umschreibungsregel.

Verbindungsausgleich

AGIC-Anmerkungen

• appgw.ingress.kubernetes.io/connection-draining
• appgw.ingress.kubernetes.io/connection-draining-timeout

Implementierung von Application Gateway für Container

Der Verbindungsausgleich ist standardmäßig für alle Bereitstellungen von Application Gateway für Container aktiviert und kann nicht konfiguriert werden.

Szenarien:

• Abskalierung: Wenn durch die automatische Skalierung abskaliert wird, werden Verbindungen 5 Minuten lang entladen. Nach 5 Minuten werden die Verbindungen geschlossen, und die Clients müssen eine neue Verbindung initiieren.
• Fehlerhafter Integritätstest: Wenn ein fehlerhafter Integritätstest erkannt wird, werden die Verbindungen beibehalten, bis der Client die Verbindung trennt.
• Pod wird aus dem Back-End entfernt: Wenn ein Pod in AKS entfernt wird, behält Application Gateway für Container weiterhin offene Verbindungen bei, bis der Client die Verbindung trennt.

Anforderungstimeout

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/request-timeout

Implementierung von Application Gateway für Container

Anforderungstimeouts können in Application Gateway für Container nicht konfiguriert werden. Eine Liste der Standardtimeoutwerte finden Sie hier.

Frontend-Portüberschreibung

AGIC-Anmerkung

• appgw.ingress.kubernetes.io/override-frontend-port

Implementierung von Application Gateway für Container

Application Gateway für Container unterstützt nur Ports 80 und 443. Ports 80 und/oder 443 werden in jeder Gateway- oder Eingangsressource definiert.