Komponenten von Application Gateway für Container

Dieser Artikel enthält ausführliche Beschreibungen und Anforderungen für Komponenten des Application Gateway für Container. Es wird erläutert, wie das Application Gateway for Containers eingehende Anforderungen akzeptiert und an ein Backend-Ziel weiterleitet. Eine allgemeine Übersicht über das Application Gateway für Container finden Sie unter Was ist Application Gateway for Containers.

Kernkomponenten

• Eine Application Gateway for Containers-Ressource ist eine übergeordnete Azure-Ressource, welche die Steuerungsebene bereitstellt
• Die Steuerungsebene koordiniert die Proxykonfiguration basierend auf Kundenabsicht.
• Application Gateway für Container verfügt über zwei untergeordnete Ressourcen: Zuordnungen und Front-Ends
  • Untergeordnete Ressourcen gehören ausschließlich zum übergeordneten Application Gateway für Container und können nicht mit anderen Application Gateway für Container-Ressourcen geteilt werden.

Application Gateway für Container-Frontends

• Eine Application Gateway for Containers-Frontend-Ressource ist eine untergeordnete Azure-Ressource des Application Gateway for Containers für die übergeordnete Ressource
• Ein Application Gateway für Container-Front-End definiert den Einstiegspunkt für Clientdatenverkehr für ein bestimmtes Application Gateway für Container.
  • Sie können ein Frontend nicht mehr als einem Anwendungsgateway für Container zuordnen.
  • Sie können einen CNAME-Eintrag erstellen, indem Sie den eindeutigen FQDN verwenden, den jedes Frontend bereitstellt.
  • Private IP-Adressen werden derzeit nicht unterstützt.
• Ein einzelnes Anwendungsgateway für Container kann mehrere Frontends unterstützen.

Application Gateway für Container-Zuordnungen

• Eine Application Gateway for Containers-Zuordnungsressource ist eine untergeordnete Azure-Ressource des Application Gateway for Containers für die übergeordnete Ressource
• Ein Application Gateway für Container definiert einen Verbindungspunkt in einem virtuellen Netzwerk. Eine Zuordnung ist eine 1:1-Zuordnung einer Zuordnungsressource zu einem delegierten Azure-Subnetz.
• Das Anwendungsgateway für Container ist so konzipiert, dass mehrere Zuordnungen zulässig sind.
  • Derzeit ist die aktuelle Anzahl von Zuordnungen auf 1 begrenzt.
• Während der Erstellung einer Zuordnung wird die zugrunde liegende Datenebene bereitgestellt und mit einem Subnetz im Subnetz des definierten virtuellen Netzwerks verbunden.
• Jede Zuordnung sollte davon ausgehen, dass mindestens 256 Adressen zum Zeitpunkt der Bereitstellung im Subnetz verfügbar sind.
  • Mindestzahl von /24-Subnetzmasken für jede Bereitstellung (wenn zuvor keine Ressourcen im Subnetz bereitgestellt wurden).
    • Wenn Sie beabsichtigen, mehrere Anwendungsgateway für Containerressourcen bereitzustellen, die dasselbe Subnetz gemeinsam verwenden, berechnen Sie die erforderlichen Adressen als n×256, wobei n der Anzahl der Anwendungsgateway für Containerressourcen entspricht. Dabei wird angenommen, dass jeder eine Verknüpfung enthält.
  • Alle Zuordnungsressourcen des Application Gateway für Container sollten mit derselben Region übereinstimmen wie das Application Gateway für Container der übergeordneten Ressource.

Application Gateway für Container ALB-Controller

• Ein Application Gateway für Container ALB-Controller ist eine Kubernetes-Bereitstellung, die die Konfiguration und Bereitstellung von Application Gateway für Container koordiniert, indem Kubernetes sowohl benutzerdefinierte Ressourcen als auch Ressourcenkonfigurationen überwacht, z. B. Ingress, Gateway und ApplicationLoadBalancer. Die Lösung verwendet sowohl ARM- als auch Application Gateway für Container-Konfigurations-APIs, um die Konfiguration zur Application Gateway für Container-Bereitstellung auf Azure zu propagieren.
• Bereitstellen oder Installieren von ALB Controller mit Helm.
• ALB Controller besteht aus zwei laufenden Pods.
  • Der Pod alb-controller orchestriert die Kundenabsicht für die Konfiguration des Application Gateway für Container-Lastenausgleichs.
  • alb-controller-bootstrap pod verwaltet CRDs.

Sicherheitsrichtlinie des Anwendungsgateways für Container

• Eine Application Gateway für Container-Sicherheitsrichtlinie definiert Sicherheitskonfigurationen, wie z. B. WAF, für den ALB-Controller, der verwendet werden soll.
• Ein einzelnes Anwendungsgateway für Containerressourcen kann auf mehrere Sicherheitsrichtlinien verweisen.
• Derzeit wird einzig der Sicherheitsrichtlinientyp waf für Webanwendungs-Firewall-Funktionen angeboten.
• Die waf-Sicherheitsrichtlinie ist eine 1:1-Zuordnung zwischen der Sicherheitsrichtlinienressource und einer Web Application Firewall-Richtlinie.
  • Sie können nur auf eine Webanwendungsfirewallrichtlinie in einer beliebigen Anzahl von Sicherheitsrichtlinien für ein definiertes Anwendungsgateway für Containerressourcen verweisen.

Azure / allgemeine Konzepte

Private IP-Adresse

• Eine private IP-Adresse ist nicht explizit als Azure Resource Manager-Ressource definiert. Eine private IP-Adresse bezieht sich auf eine bestimmte Hostadresse innerhalb des Subnetzes eines bestimmten virtuellen Netzwerks.

Subnetzdelegierung

• Microsoft.ServiceNetworking/trafficControllers ist der Namespace, der vom Anwendungsgateway für Container übernommen wird, und Sie können ihn an das Subnetz eines virtuellen Netzwerks delegieren.
• Wenn Sie delegieren, stellen Sie keine Application Gateway für Container-Ressourcen bereit. Es gibt auch keine exklusive Zuordnung zu einer Application Gateway für Container-Zuordnungsressource.
• Eine beliebige Anzahl von Subnetzen kann eine Subnetzdelegierung aufweisen, die dem Anwendungsgateway für Container entspricht oder anders ist. Nach der Definition können Sie keine anderen Ressourcen im Subnetz bereitstellen, es sei denn, dies ist explizit durch die Implementierung des Diensts definiert.

Benutzerseitig zugewiesene verwaltete Identität

• Verwaltete Identitäten für Azure-Ressourcen machen die Verwaltung von Anmeldeinformationen im Code überflüssig.
• Sie benötigen eine vom Benutzer zugewiesene verwaltete Identität für jeden Azure Load Balancer Controller, um Änderungen am Anwendungsgateway für Container vorzunehmen.
• AppGw für Container Configuration Manager ist eine integrierte RBAC-Rolle, mit der ALB Controller auf die Ressource Application Gateway für Container zugreifen und diese konfigurieren kann.

So akzeptiert Application Gateway für Container eine Anforderung

Jedes Anwendungsgateway für Container-Frontend stellt einen generierten vollqualifizierten Domänennamen bereit, der von Azure verwaltet wird. Sie können den FQDN wie er ist verwenden oder ihn mit einem CNAME-Eintrag maskieren.

Bevor ein Client eine Anforderung an das Anwendungsgateway für Container sendet, löst der Client einen CNAME auf, der auf den FQDN des Frontends verweist, oder der Client löst den vom Anwendungsgateway für Container bereitgestellten FQDN direkt mithilfe eines DNS-Servers auf.

Der DNS-Resolver übersetzt den DNS-Eintrag in eine IP-Adresse.

Wenn der Client die Anforderung initiiert, wird der angegebene DNS-Name als Hostheader an das Application Gateway für Container im definierten Frontend übergeben.

Ein Satz von Routingregeln bewertet, wie die Anfrage für diesen Hostnamen an ein definiertes Backend-Ziel weitergeleitet werden soll.

So leitet Application Gateway für Container eine Anforderung weiter

HTTP/2-Anforderungen

Das Anwendungsgateway für Container unterstützt sowohl HTTP/2- als auch HTTP/1.1-Protokolle für die Kommunikation zwischen dem Client und dem Frontend. Die HTTP/2-Einstellung ist immer aktiviert und kann nicht geändert werden. Wenn Clients HTTP/1.1 für die Kommunikation an das Frontend des Anwendungsgateways für Container verwenden möchten, können sie weiterhin entsprechend verhandeln.

Die Kommunikation zwischen Dem Anwendungsgateway für Container und dem Back-End-Ziel erfolgt immer über HTTP/1.1, mit Ausnahme von gRPC, das HTTP/2 verwendet.

Änderungen an der Anforderung

Application Gateway für Container fügt drei zusätzliche Header an alle Anforderungen an, bevor Anforderungen für ein Back-End-Ziel initiiert werden:

• x-forwarded-for
• X-Forwarded-Proto
• x-request-id

x-forwarded-for ist die Client-IP-Adresse des ursprünglichen Anforderers. Wenn die Anforderung über einen Proxy erfolgt, hängt der Headerwert die empfangene Adresse an, kommatrennt. Beispiel: 1.2.3.4,5.6.7.8; Dabei ist 1.2.3.4 die Client-IP-Adresse für den Proxy vor dem Anwendungsgateway für Container, und 5.6.7.8 ist die Adresse des Proxys, der den Datenverkehr an das Anwendungsgateway für Container weiterleitet.

x-forwarded-proto gibt das Protokoll zurück, das vom Application Gateway für Container vom Client empfangen wird. Der Wert ist entweder http oder https.

x-request-id ist eine eindeutige GUID, die Application Gateway für Container für jede Clientanforderung generiert und in der weitergeleiteten Anforderung an das Back-End-Ziel angezeigt wird. Die GUID besteht aus 32 alphanumerischen Zeichen, getrennt durch Gedankenstriche (z. B. aaaa0000-bb11-2222-33cc-444444dddddd). Sie können diese GUID verwenden, um eine Anforderung, die Application Gateway für Container empfängt und einleitet, mit einem Back-End-Ziel zu korrelieren wie in Zugriffsprotokollen definiert.

Anforderungstimeouts

Application Gateway für Container setzt die folgenden Timeouts durch, während Anforderungen zwischen Client, Application Gateway für Container und Back-End eingeleitet und verwaltet werden.