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. Informationen dazu, wie Application Gateway für Container die eingehenden Anforderungen akzeptieren und sie an ein Back-End-Ziel routen wird, sind vorhanden. 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 ist für die Orchestrierung der Proxy-Konfiguration auf der Grundlage der Kundenabsicht verantwortlich.
• Das Application Gateway für Container verfügt über zwei untergeordnete Ressourcen; Zuordnungen und Frontends
  • Untergeordnete Ressourcen gelten ausschließlich für das übergeordnete Application Gateway für Container und werden möglicherweise nicht von der zusätzlichen Application Gateway for Containers-Ressource referenziert

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 for Containers-Frontend definiert, dass der Einstiegspunkt-Clientdatenverkehr von einem bestimmten Application Gateway for Containers empfangen werden soll
  • Ein Frontend kann nicht mehreren Application Gateways für Container zugeordnet werden.
  • Jedes Frontend stellt einen eindeutigen FQDN bereit, auf den durch den CNAME-Eintrag eines Kunden verwiesen werden kann.
  • Private IP-Adressen werden derzeit nicht unterstützt.
• Ein einzelnes Application Gateway 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 Zuordnung von 1:1 einer Zuordnungsressource zu einem Azure-Subnetz, das delegiert wurde.
• Application Gateway für Container ist so konzipiert, dass mehrere Zuordnungen zulässig sind.
  • Derzeit ist die aktuelle Anzahl von Zuordnungen auf 1 beschränkt.
• 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.
  • Mindestens /24 Subnetzmaske für jede Bereitstellung (vorausgesetzt, es wurden keine Ressourcen zuvor im Subnetz bereitgestellt).
    • Wenn eine Anzahl von Application Gateways für Container bereitgestellt wird, wobei davon ausgegangen wird, dass jedes Application Gateway für Container eine Zuordnung enthält und die Absicht besteht, dasselbe Subnetz zu teilen, sollten die verfügbaren erforderlichen Adressen n*256 sein.
  • 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. Sie verwendet ARM- / Application Gateway für Container -Konfigurations-APIs, um die Konfiguration an die Application Gateway für Container-Bereitstellung zu verteilen.
• ALB Controller wird über Helm bereitgestellt / installiert.
• ALB Controller besteht aus zwei laufenden Pods.
  • Der Alb-Controller-Pod ist für die Orchestrierung der Kundenabsicht zur Application Gateway für Container-Lastausgleichskonfiguration verantwortlich.
  • Alb-Controller-Bootstrap-Pod ist verantwortlich für die Verwaltung von CRDs.

Azure / allgemeine Konzepte

Private IP-Adresse

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

Subnetzdelegierung

• Microsoft.ServiceNetworking/trafficControllers ist der Namespace, der vom Anwendungsgateway für Container angenommen wird und möglicherweise an das Subnetz eines virtuellen Netzwerks delegiert wird.
• Bei der Delegierung erfolgt keine Bereitstellung von Application Gateway für Container-Ressourcen und 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 keine anderen Ressourcen außer dem definierten Dienst in das Subnetz bereitgestellt werden, es sei denn, dies wird 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.
• Für jeden Azure Load Balancer Controller ist eine vom Benutzer verwaltete Identität erforderlich, um Änderungen am Application Gateway 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.

Hinweis

Die Rolle AppGw für Container Configuration Manager verfügt über Datenaktionsberechtigungen, über die die Rollen Besitzer und Mitwirkender nicht verfügen. Es ist wichtig, dass ordnungsgemäße Berechtigungen delegiert werden, um Probleme mit ALB Controller zu verhindern, die Änderungen am Application Gateway für Container-Dienst vornehmen.

So akzeptiert Application Gateway für Container eine Anforderung

Jedes Application Gateway für Container stellt einen generierten vollqualifizierten Domänennamen bereit, der von Azure verwaltet wird. Der FQDN kann so verwendet werden, wie er ist, oder Kunden können den FQDN mit einem CNAME-Eintrag maskieren.

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

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 vollständig das HTTP/2-Protokoll für die Kommunikation vom Client zum Frontend. Die Kommunikation vom Anwendungsgateway für Container an das Back-End-Ziel verwendet das HTTP/1.1-Protokoll. 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.

Änderungen an der Anforderung

Application Gateway for Containers fügt drei zusätzliche Header in alle Anforderungen ein, bevor Anforderungen von Application Gateway for Containers an ein Backend-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 Anfrage über einen Proxy kommt, wird die empfangene Adresse durch Kommata getrennt an den Header-Wert angehängt. Beispiel: 1.2.3.4,5.6.7.8; wobei 1.2.3.4 die Client-IP-Adresse des Proxys vor Application Gateway für Container und 5.6.7.8 die Adresse des Proxys ist, der den Verkehr an Application Gateway für Container weiterleitet.

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

x-request-id ist eine eindeutige GUID, die vom Anwendungsgateway für Container für jede Clientanforderung generiert und in der weitergeleiteten Anforderung an das Back-End-Ziel angegeben wird. Die GUID besteht aus 32 alphanumerischen Zeichen, getrennt durch Gedankenstriche (z. B. d23387ab-e629-458a-9c93-6108d374bc75). Diese Guid kann verwendet werden, um eine von Application Gateway für Container empfangene und initiierte Anfrage mit einem in den Zugriffsprotokollen definierten Back-End-Ziel zu korrelieren.

Anforderungstimeouts

Das Application Gateway for Containers erzwingt die folgenden Timeouts, da Anforderungen zwischen Client, Application Gateway für Container und Back-End initiiert und verwaltet werden.

Timeout	Duration	Beschreibung
Anforderungstimeout	60 Sekunden	Zeit, für die das Application Gateway für Container auf die Back-End-Zielantwort wartet.
HTTP-Leerlauftimeout	5 Minuten	Leerlauftimeout vor dem Schließen einer HTTP-Verbindung.
Stream-Leerlauftimeout	5 Minuten	Leerlauftimeout vor dem Schließen eines einzelnen Datenstroms, der von einer HTTP-Verbindung übertragen wird.
Upstream Connect Timeout	5 Sekunden	Zeit zum Herstellen einer Verbindung mit dem Back-End-Ziel.