Freigeben über

Was ist der Application Gateway-Eingangscontroller?

Der Application Gateway Ingress Controller (AGIC) ist eine Kubernetes-Anwendung, mit der Azure Kubernetes Service (AKS) Cluster das systemeigene Azure Application Gateway L7 Load Balancer verwenden können, um Workloads für das Internet verfügbar zu machen. AGIC überwacht den Kubernetes-Cluster, auf dem es gehostet wird, und aktualisiert kontinuierlich ein Application Gateway, sodass ausgewählte Dienste im Internet verfügbar gemacht werden.

Der Ingress-Controller wird in seinem eigenen Pod auf Ihrem AKS-Cluster ausgeführt. AGIC überwacht eine Teilmenge der Kubernetes-Ressourcen auf Änderungen. Der Status des AKS-Clusters wird in anwendungsgatewayspezifische Konfiguration übersetzt und auf Azure Resource Manager (ARM) angewendet.

In diesem Artikel erfahren Sie mehr über die Vorteile von AGIC, Bereitstellungsoptionen (Helm- und AKS-Add-On) und unterstützten Containernetzwerkkonfigurationen.

Tipp

Ziehen Sie Application Gateway für Container für Ihre Kubernetes-Eingangslösung in Betracht. Weitere Informationen finden Sie unter Schnellstart: Bereitstellen des ALB-Controllers von Application Gateway für Container.

Vorteile des Application Gateway-Eingangscontrollers

AGIC hilft dabei, die Notwendigkeit eines anderen Lastenausgleichs oder einer öffentlichen IP-Adresse vor dem AKS-Cluster zu vermeiden. Der Datenpfad vermeidet mehrere Zwischenschritte, bevor Anforderungen den AKS-Cluster erreichen. Das Anwendungsgateway kommuniziert mit Pods mithilfe ihrer privaten IP-Adresse direkt und erfordert keine NodePort- oder KubeProxy-Dienste. Diese Fähigkeit bringt auch eine bessere Leistung für Ihre Bereitstellungen.

Der Ingress-Controller wird ausschließlich von Standard_v2 und WAF_v2 SKUs unterstützt, die auch die Vorteile der automatischen Skalierung ermöglichen. Application Gateway kann als Reaktion auf eine Erhöhung oder Verringerung der Datenverkehrslast reagieren und eine entsprechende Skalierung ausführen, ohne Ressourcen aus Ihrem AKS-Cluster zu verbrauchen.

Die Verwendung des Anwendungsgateways zusätzlich zu AGIC trägt auch zum Schutz Ihres AKS-Clusters bei, indem TLS-Richtlinien- und Web Application Firewall-Funktionen (WAF) bereitgestellt werden.

Diagramm, das Datenverkehr zeigt, der über das Anwendungsgateway über das Internet in einen AKS-Cluster mit AGIC fließt.

AGIC wird über die Kubernetes Ingress-Ressource zusammen mit Service und Deployments/Pods konfiguriert. Mit dem systemeigenen Azure Application Gateway L7 Load Balancer bietet AGIC die folgenden Features:

  • URL-Routing
  • Cookiebasierte Affinität
  • TLS-Terminierung
  • End-to-End-TLS
  • Unterstützung für öffentliche, private und Hybridwebsites
  • Integrierte Web Application Firewall

Warnung

Standardmäßig übernimmt AGIC den vollständigen Besitz des Anwendungsgateways, mit dem es verknüpft ist. AGIC überschreibt alle vorhandenen Anwendungsgatewaykonfigurationen, die in Kubernetes Ingress-Ressourcen nicht definiert sind. Alle Listener, Back-End-Pools, Regeln oder andere Einstellungen, die zuvor auf dem Anwendungsgateway konfiguriert wurden, werden entfernt oder ersetzt, wenn AGIC aktiviert ist. Bevor Sie AGIC für ein vorhandenes Anwendungsgateway aktivieren, sichern Sie Ihre Anwendungsgateway-Konfiguration, indem Sie die Vorlage aus dem Azure-Portal exportieren. Weitere Informationen finden Sie unter Sichern der Anwendungsgateway-Bereitstellung.

Wenn AGIC mit vorhandenen Anwendungsgatewaykonfigurationen koexistieren muss, lesen Sie das Einrichten einer gemeinsamen Anwendungsgateway-Bereitstellung (nur Helm).

Unterschied zwischen Helm-Bereitstellung und AKS-Add-on

Sie können AGIC für Ihren AKS-Cluster bereitstellen, indem Sie entweder Helm oder AKS als Add-On verwenden. Der Hauptvorteil der Bereitstellung von AGIC als AKS-Add-On ist, dass dies wesentlich einfacher ist als die Bereitstellung mittels Helm. Für ein neues Setup können Sie ein neues Anwendungsgateway und einen neuen AKS-Cluster mit AGIC bereitstellen, der als Add-On in einer Zeile in Azure CLI aktiviert ist. Das Add-On ist außerdem ein vollständig verwalteter Dienst, der zusätzliche Vorteile bietet wie automatische Updates und verbesserten Support. Beide Bereitstellungsmethoden für AGIC (Helm- und AKS-Add-On) werden von Microsoft vollständig unterstützt. Darüber hinaus ermöglicht das Add-On eine bessere Integration in AKS als erstklassiges Add-On.

Obwohl Sie das AGIC-Add-On als Pod in Ihrem AKS-Cluster bereitstellen, gibt es einige Unterschiede zwischen der Helm-Bereitstellungsversion und der Add-On-Version von AGIC. In der folgenden Liste werden die Unterschiede hervorgehoben:

  • Sie können die Helm-Bereitstellungswerte für das AKS-Add-On nicht ändern:
    • verbosityLevel ist standardmäßig auf 5 eingestellt
    • usePrivateIpist standardmäßig auf "false" festgelegt; Diese Einstellung mithilfe der "use-private-ip"-Anmerkung überschreiben
    • shared wird für Add-On nicht unterstützt
    • reconcilePeriodSeconds wird für Add-On nicht unterstützt
    • armAuth.type wird für Add-On nicht unterstützt
  • AGIC, das über Helm bereitgestellt wird, unterstützt ProhibitedTargets, was bedeutet, dass AGIC das Application Gateway speziell für AKS-Cluster konfigurieren kann, ohne dabei andere vorhandene Back-Ends zu beeinträchtigen. Diese Funktion wird vom AGIC-Add-On zurzeit nicht unterstützt.
  • Da AGIC-Add-On ein verwalteter Dienst ist, erhalten Sie automatisch Updates für die neueste Version des AGIC-Add-Ons. Wenn Sie AGIC über Helm bereitstellen, müssen Sie AGIC dagegen manuell aktualisieren.

Hinweis

Sie können nur ein AGIC-Add-On pro AKS-Cluster bereitstellen, und jedes AGIC-Add-On kann derzeit nur auf ein Anwendungsgateway abzielen. Verwenden Sie AGIC, das über Helm bereitgestellt wird, für Bereitstellungen, die mehr als eine AGIC pro Cluster oder mehrere AGICs für ein Anwendungsgateway erfordern.

Sowohl das Helm- als auch das AGIC-Add-On unterstützen den ExternalName-Dienst nicht.

Containernetztechnologie und AGIC

Der Application Gateway-Eingangsdatencontroller unterstützt die folgenden AKS-Netzwerkangebote:

  • Kubenet
  • CNI
  • CNI-Überlagerung

Azure CNI und Azure CNI Overlay sind die beiden empfohlenen Optionen für den Application Gateway Ingress Controller. Berücksichtigen Sie beim Auswählen eines Netzwerkmodells die Anwendungsfälle für jedes CNI-Plug-In und den Typ des verwendeten Netzwerkmodells:

CNI-Plug-In Netzwerkmodell Highlights der Anwendungsfälle
Azure CNI Overlay Überlagerung - Optimal für die IP-Erhaltung virtueller Netzwerke
– Maximale Knotenanzahl, die vom API-Server und 250 Pods pro Knoten unterstützt wird
– Einfachere Konfiguration
– Kein direkter externer Pod-IP-Zugriff
Azure CNI Pod Subnet Flach – Direkter externer Podzugriff
- Modi für eine effiziente IP-Nutzung des virtuellen Netzwerks oder unterstützung für große Cluster
Azure CNI Node Subnet Flach – Direkter externer Podzugriff
– Einfachere Konfiguration
– Begrenzte Skalierung
- Ineffiziente Verwendung virtueller Netzwerk-IPs

Wenn Sie Das Anwendungsgateway für Container in einem Cluster bereitstellen, der CNI-Überlagerung oder CNI aktiviert hat, erkennt Das Anwendungsgateway für Container automatisch die beabsichtigte Netzwerkkonfiguration. Sie müssen keine Gateway- oder Ingress-API-Konfiguration ändern, um CNI-Überlagerung oder CNI anzugeben.

Wenn Sie Azure CNI Overlay verwenden, beachten Sie die folgenden Einschränkungen:

  • AGIC-Controller: Sie müssen Version v1.9.1 oder höher ausführen, um CNI-Überlagerung nutzen zu können.
  • Subnetzgröße: Das Application Gateway-Subnetz muss ein maximales /24-Präfix sein. Pro Subnetz wird nur eine Bereitstellung unterstützt.
  • Subnetzdelegierung: Das Application Gateway-Subnetz muss über Subnetzdelegierung für Microsoft.Network/applicationGateways verfügen.
  • Regionales virtuelles Netzwerkpeering: Sie können Application Gateway und AKS-Clusterknoten nicht in virtuellen Netzwerken in derselben Region bereitstellen.
  • Globales virtuelles Netzwerkpeering: Sie können Application Gateway und AKS-Clusterknoten nicht in virtuellen Netzwerken in einer anderen Region bereitstellen.
  • Azure CNI Overlay mit Application Gateway Ingress Controller wird in der Azure Government Cloud oder in Microsoft Azure, das von 21Vianet betrieben wird (Azure in China), nicht unterstützt.

Hinweis

Der Application Gateway Ingress Controller erkennt automatisch das Upgrade des AKS-Clusters von Kubenet oder CNI auf CNI Overlay. Planen Sie das Upgrade während eines Wartungsfensters, da Verkehrsunterbrechungen auftreten können. Der Controller benötigt möglicherweise einige Minuten nach einem Upgrade des Clusters, um die Unterstützung für CNI-Overlay zu erkennen und zu konfigurieren.

Warnung

Stellen Sie sicher, dass das Anwendungsgateway-Subnetz vor dem Upgrade ein /24 oder ein kleineres Subnetz ist. Das Upgrade von CNI auf CNI Overlay mit einem größeren Subnetz (z. B. "/23") führt zu einem Ausfall und erfordert, dass Sie das Anwendungsgateway-Subnetz mit einer unterstützten Subnetzgröße neu erstellen.

Nächste Schritte

  • Last updated on