Dela via


Application Gateway för containerkomponenter

Den här artikeln innehåller detaljerade beskrivningar och krav för komponenter i Application Gateway för containrar. Här finns information om hur Application Gateway för containrar accepterar inkommande begäranden och dirigerar dem till ett bakomliggande mål. För en allmän översikt över Application Gateway för containrar, se Vad är Application Gateway för containrar.

Kärnkomponenter

  • En Application Gateway for Containers-resurs är en överordnad Azure-resurs som distribuerar kontrollplanet.
  • Kontrollplanet ansvarar för att samordna proxykonfigurationen baserat på kundens avsikt.
  • Application Gateway för containrar har två underordnade resurser; kopplingar och klientdelar.
    • Underordnade resurser är exklusiva för sina respektive överordnade Application Gateway för containrar och får inte refereras av en annan Application Gateway för containrar.

Application Gateway för containrar-klientdelar

  • En Application Gateway for Containers-frontend är en underordnad Azure-resurs till den överordnade resursen Application Gateway for Containers.
  • En Application Gateway for Containers-frontend definierar den startpunkt där klienttrafik ska tas emot av en viss Application Gateway for Containers.
    • En frontend kan inte associeras till mer än en Application Gateway for Containers.
    • Varje frontend tillhandahåller ett unikt FQDN som kan refereras till av en kunds CNAME-postering.
    • Privata IP-adresser stöds för närvarande inte.
  • En enda Application Gateway för containrar kan ha stöd för fler än en framsida.

Application Gateway för containerassociationer

  • En Application Gateway for Containers-associationsresurs är en underordnad Azure-resurs för den överordnade resursen Application Gateway for Containers.
  • En Application Gateway for Containers-association definierar en anslutningspunkt till ett virtuellt nätverk. En association är en 1:1-mappning av en associationsresurs till ett Azure-undernät som har delegerats.
  • Application Gateway för containrar är utformad för att möjliggöra fler än en koppling.
    • För närvarande är det aktuella antalet associationer begränsat till 1.
  • När en association skapas etableras det underliggande dataplanet och ansluts till ett undernät i det definierade virtuella nätverkets undernät.
  • Varje association bör anta att minst 256 adresser är tillgängliga i undernätet vid tidpunkten för etableringen.
    • En subnätsmask på minst /24 för varje distribution (förutsatt att inga resurser tidigare har tilldelats i undernätet).
      • Om n antal Application Gateway för containrar tilldelas, med antagandet att varje Application Gateway för containrar har en koppling, och avsikten är att dela samma undernät, bör de tillgängliga nödvändiga adresserna vara n*256.
    • Alla Application Gateway for Containers-associationsresurser ska matcha samma region som den överordnade resursen Application Gateway for Containers.

Application Gateway för containrar ALB-styrenhet

  • En Application Gateway for Containers ALB-styrenhet är en Kubernetes-distribution som samordnar konfigurationen och distributionen av Application Gateway för containrar genom att titta på Kubernetes både anpassade resurser och resurskonfigurationer, till exempel, men inte begränsat till, Ingress, Gateway och ApplicationLoadBalancer. Den använder både ARM/Application Gateway for Containers-konfigurations-API:er för att sprida konfigurationen till Azure-distributionen för Application Gateway for Containers.
  • ALB-styrenheten distribueras/installeras via Helm.
  • ALB-kontrollanten består av två körande pods.
    • alb-controller-podden ansvarar för att orkestrera kundens avsikt till Application Gateway för containrars belastningsutjämningskonfiguration.
    • alb-controller-bootstrap pod ansvarar för hantering av CRD:er.

Säkerhetspolicy för Application Gateway for Containers

  • En säkerhetsprincip för Application Gateway för containerapplikationer definierar säkerhetskonfigurationer, som till exempel WAF, som ALB-controllerna ska använda.
  • Mer än en säkerhetsprincip kan refereras av en enda Application Gateway for Containers-resurs.
  • För närvarande är waf den enda säkerhetsprinciptypen som erbjuds för brandväggsfunktioner för webbprogram.
  • Säkerhetsprincipen waf är en en-till-en-mappning mellan säkerhetsprincipresursen och en brandväggsprincip för webbaserade program.
    • Endast en brandväggsprincip för webbprogram kan refereras till i valfritt antal säkerhetsprinciper för en definierad Application Gateway for Containers-resurs.

Azure/allmänna begrepp

Privat IP-adress

  • En privat IP-adress definieras inte uttryckligen som en Azure Resource Manager-resurs. En privat IP-adress refererar till en specifik värdadress i ett visst virtuellt nätverks undernät.

Delegering av undernät

  • Microsoft.ServiceNetworking/trafficControllers är namnområdet som antagits av Application Gateway för containrar och kan delegeras till ett virtuellt nätverks undernät.
  • När delegering sker sker inte etablering av Application Gateway for Containers-resurser, och det finns inte heller någon exklusiv mappning till en Application Gateway for Containers-associationsresurs.
  • Valfritt antal undernät kan ha en delegering av undernät som är densamma eller som skiljer sig från Application Gateway för containrar. När det har definierats kan inga andra resurser, förutom den definierade tjänsten, etableras i undernätet om de inte uttryckligen definieras av tjänstens implementering.

Användartilldelad hanterad identitet

  • Hanterade identiteter för Azure-resurser eliminerar behovet av att hantera autentiseringsuppgifter i kod.
  • En användarhanterad identitet krävs för att varje Azure Load Balancer-kontrollant ska kunna göra ändringar i Application Gateway för containrar.
  • AppGw for Containers Configuration Manager är en inbyggd RBAC-roll som gör att ALB Controller kan komma åt och konfigurera Application Gateway for Containers-resursen.

Anmärkning

Rollen AppGw for Containers Configuration Manager har dataåtgärdsbehörigheter som rollerna Ägare och Deltagare inte har. Det är viktigt att rätt behörigheter delegeras för att förhindra problem med att ALB-kontrollanten gör ändringar i Application Gateway för containrar.

Hur Application Gateway för containrar accepterar en begäran

Varje Application Gateway for Containers-klientdel innehåller ett genererat fullständigt kvalificerat domännamn som hanteras av Azure. FQDN kan användas som det är, eller så kan kunder välja att maskera FQDN med en CNAME-record.

Innan en klient skickar en begäran till Application Gateway för containrar, löser klienten en CNAME som pekar på frontens FQDN; eller så kan klienten direkt lösa FQDN som tillhandahålls av Application Gateway för containrar med hjälp av en DNS-server.

DNS-matcharen omvandlar DNS-posten till en IP-adress.

När klienten initierar begäran skickas det angivna DNS-namnet som värdhuvud till Application Gateway för containrar på den definierade klientdelen.

En uppsättning routningsregler utvärderar hur begäran om värdnamnet ska initieras till ett definierat backend-mål.

Hur en applikationsgateway för containerhantering dirigerar en förfrågan

HTTP/2-begäranden

Application Gateway för containrar stöder både HTTP/2 och HTTP/1.1 protokoll för kommunikation mellan klienten och frontend. HTTP/2-inställningen är alltid aktiverad och kan inte ändras. Om klienter föredrar att använda HTTP/1.1 för sin kommunikation till klientdelen av Application Gateway för containrar kan de fortsätta att förhandla i enlighet med detta.

Kommunikationen mellan Application Gateway för containrar och målservern sker alltid via HTTP/1.1, förutom gRPC, som använder HTTP/2.

Ändringar i begäran

Application Gateway för containrar infogar tre extra rubriker på alla begäranden innan de initieras från Application Gateway för containrar till en målenhet.

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

x-forwarded-for är den ursprungliga beställarens klient-IP-adress. Om begäran kommer via en proxy läggs adresserna som tas emot till i rubrikvärdet, avgränsade med komma. I exempel: 1.2.3.4,5.6.7.8; där 1.2.3.4 är klientens IP-adress till proxyn framför Application Gateway för containrar, och 5.6.7.8 är adressen till proxyn som vidarebefordrar trafik till Application Gateway för containrar.

x-forwarded-proto returnerar protokollet som tas emot av Application Gateway för containrar från klienten. Värdet är antingen http eller https.

x-request-id är ett unikt GUID som genereras av Application Gateway för containrar för varje klientbegäran och som visas i den vidarebefordrade begäran till backendmålet. En guid består av 32 alfanumeriska tecken, avgränsade med bindestreck (till exempel: aaaa0000-bb11-2222-33cc-444444dddddd). Detta GUID kan användas för att korrelera en begäran som tas emot av Application Gateway för containrar och som initieras mot ett backend-mål som definieras i åtkomstloggarna.

Tidsgränser för begäranden

Application Gateway för containrar tillämpar följande tidsgränser när begäranden initieras och underhålls mellan klienten, Application Gateway för containrar och backend-systemet.

Tidsavbrott Varaktighet beskrivning
Tidsgräns för förfrågan 60 sekunder Väntetid för vilken Application Gateway för containrar väntar på backend-målsvaret.
Tidsgräns för HTTP-inaktivitet 5 minuter timeout för inaktivitet innan en HTTP-anslutning stängs.
Tidsgräns för inaktiv ström 5 minuter timeout för inaktivitet innan du stänger en enskild dataström som utförs av en HTTP-anslutning.
Timeout för uppströmsanslutning 5 sekunder tid att etablera en anslutning till backendmål.

Anmärkning

Tidsgränsen för begäran framtvingar strikt att begäran slutförs under den definierade tiden, oavsett om data strömmas aktivt eller om begäran har börjat vara inaktiv. Om du till exempel hanterar stora filnedladdningar och du förväntar dig att tranfer tar mer än 60 sekunder på grund av storlek eller långsamma överföringshastigheter kan du överväga att öka tidsgränsvärdet för begäran eller ställa in det på 0.