Application Gateway voor Containers-onderdelen

Dit artikel bevat gedetailleerde beschrijvingen en vereisten voor onderdelen van Application Gateway for Containers. Hierin wordt uitgelegd hoe Application Gateway for Containers binnenkomende aanvragen accepteert en deze doorstuurt naar een back-enddoel. Zie Wat is Application Gateway voor containers voor een algemeen overzicht van Application Gateway for Containers.

Kernonderdelen

• Een Application Gateway for Containers-resource is een bovenliggende Azure-resource waarmee het besturingsvlak wordt geïmplementeerd.
• Het besturingsvlak organiseert de proxyconfiguratie op basis van de intentie van de klant.
• Application Gateway for Containers heeft twee onderliggende resources: koppelingen en front-ends.
  • Onderliggende resources behoren uitsluitend tot hun bovenliggende Application Gateway voor containers en kunnen niet worden gedeeld met andere Application Gateway for Containers-resources.

Frontends voor Application Gateway voor Containers

• Een front-endresource van de Application Gateway for Containers is een onderliggende Azure-resource van de bovenliggende Application Gateway for Containers-resource.
• Een Application Gateway for Containers-frontend definieert het toegangspunt dat door klantverkeer wordt gebruikt voor een specifieke Application Gateway for Containers.
  • U kunt een front-end niet koppelen aan meer dan één Application Gateway for Containers.
  • U kunt een CNAME-record maken met behulp van de unieke FQDN die elke front-end biedt.
  • Privé-IP-adressen worden momenteel niet ondersteund.
• Eén Application Gateway for Containers kan meer dan één front-end ondersteunen.

Toepassingsgateway voor containerassociaties

• Een koppelingsresource van Application Gateway for Containers is een onderliggende Azure-resource van de hoofresource Application Gateway for Containers.
• Een Application Gateway voor Containers-koppeling definieert een verbindingspunt in een virtueel netwerk. Een koppeling is een 1:1-toewijzing van een koppelingsresource aan een gedelegeerd Azure-subnet.
• Application Gateway for Containers is ontworpen om meer dan één koppeling mogelijk te maken.
  • Op dit moment is het huidige aantal koppelingen beperkt tot 1.
• Tijdens het maken van een koppeling wordt het onderliggende gegevensvlak ingericht en verbonden met een subnet binnen het gedefinieerde subnet van het virtuele netwerk.
• Elke koppeling moet ervan uitgaan dat ten minste 256 adressen beschikbaar zijn in het subnet op het moment van inrichten.
  • Een minimaal /24-subnetmasker voor elke implementatie (ervan uitgaande dat er geen resources eerder zijn ingericht in het subnet).
    • Als u van plan bent om meerdere Application Gateway for Containers-resources te implementeren die hetzelfde subnet delen, berekent u de vereiste adressen als n×256, waarbij n gelijk is aan het aantal Application Gateway for Containers-resources. Hierbij wordt ervan uitgegaan dat elk één koppeling bevat.
  • Alle resources die gekoppeld zijn aan de Application Gateway voor Containers moeten zich in dezelfde regio bevinden als de bovenliggende resource van de Application Gateway voor Containers.

Netwerkbeveiligingsgroepen in het koppelingssubnet

Voor koppelingen die zijn gemaakt op of na 23 april 2026, worden Network Security Groups (NSG's) volledig ondersteund in het Application Gateway voor Containers-koppelingssubnet. Dit omvat zowel regels voor inkomend als uitgaand verkeer.

Voor koppelingen die vóór 23 april 2026 zijn gemaakt, kunnen binnenkomende NSG-regels worden geconfigureerd; Inkomend verkeer op poorten 80 en 443 is echter altijd toegestaan, ongeacht de geconfigureerde regels.

Regels voor 'Alles weigeren' worden ondersteund in het subnet van de koppeling. Zonder expliciete uitzonderingen toestaan, kunnen deze regels echter van invloed zijn op zowel inkomend als uitgaand verkeer:

• Als u alle binnenkomende regels weigert , wordt verkeer op poort 80 en 443 geblokkeerd, tenzij expliciete regels voor toestaan zijn gedefinieerd, waardoor de toegang tot de front-end wordt geblokkeerd.
• Het weigeren van alle uitgaande regels kan het uitgaand verkeer van de proxy naar het AKS-cluster blokkeren, tenzij de vereiste uitgaande uitzonderingen zijn geconfigureerd.

Application Gateway voor Containers ALB Controller

• Een ALB-controller voor Application Gateway for Containers is een Kubernetes-implementatie die de configuratie en implementatie van Application Gateway for Containers coördineert door zowel aangepaste Kubernetes-resources als resourceconfiguraties te bewaken, zoals maar niet beperkt tot Ingress, Gateway en ApplicationLoadBalancer. Het maakt gebruik van zowel ARM- als Application Gateway for Containers-configuratie-API's om de configuratie door te geven aan de Application Gateway for Containers Azure-implementatie.
• Implementeer of installeer de ALB-controller met Helm.
• De ALB Controller bestaat uit twee werkende pods.
  • De alb-controller pod orkestreert de intentie van de klant naar de load balancing configuratie van Application Gateway voor containers.
  • alb-controller-bootstrap pod beheert CRD's.

Beveiligingsbeleid voor Application Gateway voor Containers

• Een beveiligingsbeleid voor Application Gateway for Containers definieert beveiligingsconfiguraties, zoals WAF, voor gebruik door de ALB-controller.
• Eén Application Gateway for Containers-resource kan verwijzen naar meer dan één beveiligingsbeleid.
• Op dit moment is waf het enige type beveiligingsbeleid dat wordt aangeboden voor web application firewall-mogelijkheden.
• Het waf beveiligingsbeleid is een één-op-één koppeling tussen de beveiligingsbeleidresource en een Web Application Firewall-beleid.
  • U kunt slechts naar één web application firewall-beleid verwijzen in een willekeurig aantal beveiligingsbeleidsregels voor een gedefinieerde Application Gateway for Containers-resource.

Applicatiegateway voor containers AKS beheerd add-on

De AKS-invoegtoepassing voor Application Gateway for Containers biedt een beheerde implementatie-ervaring door AKS voor de ALB-controller, waardoor u geen helm-grafiek handmatig hoeft te implementeren.

Enkele voordelen van het gebruik van de beheerde invoegtoepassing ten opzichte van een helm-gebaseerde implementatie zijn:

• Beheerde updates: U hoeft Helm-grafieken niet handmatig bij te werken; updates worden beheerd door AKS.
• Geautomatiseerd identiteitsbeheer: De invoegtoepassing maakt en configureert automatisch de beheerde identiteit (applicationloadbalancer-<cluster-name>) met de vereiste machtigingen.
• Vereenvoudigde subnetconfiguratie: Er wordt automatisch een toegewezen subnet (aks-appgateway) ingericht met de juiste delegatie.
• Verminderde configuratiecomplexiteit: U hoeft geen federatieve referenties of roltoewijzingen handmatig in te stellen.
• Automatische ondersteuning voor AKS: Implementatie van invoegtoepassingen is vereist bij het gebruik van automatische AKS-clusters.

Azure/algemene concepten

Privé IP-adres

• Een privé-IP-adres is niet expliciet gedefinieerd als een Azure Resource Manager-resource. Een privé-IP-adres verwijst naar een specifiek hostadres binnen het subnet van een bepaald virtueel netwerk.

Delegatie van subnet

• Microsoft.ServiceNetworking/trafficControllers is de naamruimte die wordt gebruikt door Application Gateway for Containers en u kunt deze delegeren aan het subnet van een virtueel netwerk.
• Wanneer u delegeert, richt u geen Application Gateway voor Containers-resources in, en er is ook geen exclusieve toewijzing aan een Application Gateway voor Containers-koppelingsresource.
• Een willekeurig aantal subnetten kan een subnetdelegering hebben die hetzelfde is of verschilt van Application Gateway for Containers. Zodra dit is gedefinieerd, kunt u geen andere resources inrichten in het subnet, tenzij dit expliciet is gedefinieerd door de implementatie van de service.

Door de gebruiker toegewezen beheerde identiteit

• Beheerde identiteiten voor Azure-resources elimineren de noodzaak om referenties in code te beheren.
• U hebt een door de gebruiker toegewezen beheerde identiteit nodig voor elke Azure Load Balancer-controller om wijzigingen aan te brengen in Application Gateway for Containers.
• AppGw for Containers Configuration Manager is een ingebouwde RBAC-rol waarmee DE ALB-controller toegang heeft tot de Application Gateway for Containers-resource en deze kan configureren.

Hoe Application Gateway for Containers een aanvraag accepteert

Elke front-end voor Application Gateway for Containers biedt een gegenereerde volledig gekwalificeerde domeinnaam die wordt beheerd door Azure. U kunt de FQDN-as-is gebruiken of maskeren met een CNAME-record.

Voordat een client een aanvraag naar Application Gateway for Containers verzendt, lost de client een CNAME op die verwijst naar de FQDN van de front-end, of de client lost de FQDN die wordt geleverd door Application Gateway for Containers rechtstreeks op met behulp van een DNS-server.

De DNS-resolver vertaalt de DNS-record naar een IP-adres.

Wanneer de client de aanvraag initieert, wordt de opgegeven DNS-naam als hostheader doorgegeven aan Application Gateway for Containers op de gedefinieerde front-end.

Een set routeringsregels evalueert hoe de aanvraag voor die hostnaam moet worden geïnitieerd naar een gedefinieerd back-enddoel.

Hoe Application Gateway for Containers een aanvraag routeert

HTTP/2-aanvragen

Application Gateway for Containers ondersteunt zowel HTTP/2- als HTTP/1.1-protocollen voor communicatie tussen de client en de front-end. De HTTP/2-instelling is altijd ingeschakeld en kan niet worden gewijzigd. Als clients liever HTTP/1.1 gebruiken voor hun communicatie met de front-end van Application Gateway for Containers, kunnen ze dienovereenkomstig blijven onderhandelen.

Communicatie tussen Application Gateway for Containers en het back-enddoel is altijd via HTTP/1.1, met uitzondering van gRPC, die gebruikmaakt van HTTP/2.

Wijzigingen in de aanvraag

Application Gateway for Containers voegt drie extra headers toe aan alle aanvragen voordat aanvragen naar een back-enddoel worden gestart:

• x-forwarded-for
• x-forwarded-proto
• x-request-id

x-forwarded-for is het cliënt IP-adres van de oorspronkelijke aanvrager. Als de aanvraag via een proxy wordt verzonden, voegt de headerwaarde het adres toe dat deze ontvangt, door komma's gescheiden. Bijvoorbeeld: 1.2.3.4,5.6.7.8; waarbij 1.2.3.4 het IP-adres van de client is voor de proxy vóór Application Gateway for Containers, en 5.6.7.8 het adres is van het doorsturen van proxyverkeer naar Application Gateway for Containers.

x-forwarded-proto retourneert het protocol dat Application Gateway for Containers van de client ontvangt. De waarde is http of https.

x-request-id is een unieke guid die Application Gateway for Containers genereert voor elke clientaanvraag en die wordt weergegeven in de doorgestuurde aanvraag naar het back-enddoel. De guid bestaat uit 32 alfanumerieke tekens, gescheiden door streepjes (bijvoorbeeld: aaaa0000-bb11-2222-33cc-444444dddddd). U kunt deze GUID gebruiken om een aanvraag te correleren die Application Gateway for Containers ontvangt en initieert naar een back-enddoel, zoals gedefinieerd in toegangslogboeken.

Time-outs aanvragen

Application Gateway for Containers dwingt de volgende time-outs af tijdens het initiëren en onderhouden van aanvragen tussen de client, Application Gateway for Containers en de back-end.

Connectiviteit

De volgende connectiviteitsvereisten zijn nodig voor een geslaagde werking van Application Gateway for Containers.

Uitgaande connectiviteit van de ALB-controller

Binnenkomende connectiviteit van ALB-controller

Frontendconnectiviteit

Elke front-end voor Application Gateway for Containers heeft het formaat van *.fzXX.alb.azure.com, waarbij XX numerieke cijfers 0-99 zijn. Front-ends kunnen alleen luisteren op poort 443 en 80.