Dela via

Vad är Application Gateway Ingress-kontrollant?

Application Gateway Ingress Controller (AGIC) är ett Kubernetes-program, vilket gör det möjligt för Azure Kubernetes Service-kunder (AKS) att utnyttja Azures interna Application Gateway L7-lastbalanserare för att exponera molnprogramvara på Internet. AGIC övervakar Kubernetes-klustret som det finns på och uppdaterar kontinuerligt en Application Gateway, så att valda tjänster exponeras för Internet.

Ingresskontrollanten körs i en egen podd på kundens AKS. AGIC övervakar en delmängd av Kubernetes-resurser för ändringar. Tillståndet för AKS-klustret översätts till en specifik Application Gateway-konfiguration och tillämpas på Azure Resource Manager (ARM).

Tips

Överväg Application Gateway for Containers för din Kubernetes-ingresslösning. För mer information, se Snabbstart: Använd Application Gateway för container ALB-kontrollern.

Fördelar med Application Gateway-ingresskontrollant

AGIC hjälper till att eliminera behovet av att ha en annan lastbalanserare/offentlig IP-adress framför AKS-klustret och undviker flera hopp i datasökvägen innan begäranden når AKS-klustret. Application Gateway pratar med poddar med hjälp av sin privata IP-adress direkt och kräver inte NodePort- eller KubeProxy-tjänster. Den här funktionen ger också bättre prestanda för dina distributioner.

Ingress Controller stöds uteslutande av Standard_v2 och WAF_v2 SKU:er, vilket också möjliggör fördelar med automatisk skalning. Application Gateway kan reagera som svar på en ökning eller minskning av trafikbelastningen och skala därefter, utan att förbruka några resurser från AKS-klustret.

Genom att använda Application Gateway utöver AGIC kan du även skydda ditt AKS-kluster genom att tillhandahålla TLS-principer och WAF-funktioner (Web Application Firewall).

Azure Application Gateway + AKS

AGIC konfigureras via Kubernetes Ingress-resursen, tillsammans med Service and Deployments/Pods. Den innehåller många funktioner som använder Azures inbyggda Application Gateway L7-lastbalanserare. För att nämna några:

  • URL-routning
  • Cookie-baserad tillhörighet
  • TLS-avslutning
  • TLS från slutpunkt till slutpunkt
  • Stöd för offentliga, privata webbplatser och hybridwebbplatser
  • Integrerad brandvägg för webbaserade program

Skillnad mellan Helm-utplacering och AKS-tillägg

Det finns två sätt att distribuera AGIC för ditt AKS-kluster. Det första sättet är genom Helm; det andra är via AKS som ett tillägg. Den främsta fördelen med att distribuera AGIC som ett AKS-tillägg är att det är enklare än att distribuera via Helm. För en ny installation kan du distribuera en ny Application Gateway och ett nytt AKS-kluster med AGIC aktiverat som ett tillägg på en rad i Azure CLI. Tillägget är också en fullständigt hanterad tjänst som ger ytterligare fördelar, till exempel automatiska uppdateringar och ökat stöd. Båda sätten att distribuera AGIC (Helm och AKS-tillägg) stöds fullt ut av Microsoft. Dessutom möjliggör tillägget bättre integrering med AKS som ett förstklassigt tillägg.

AGIC-tillägget distribueras fortfarande som en podd i kundens AKS-kluster, men det finns några skillnader mellan Helm-distributionsversionen och tilläggsversionen av AGIC. Följande är en lista över skillnader mellan de två versionerna:

  • Helm-distributionsvärden kan inte ändras i AKS-tillägget:
    • verbosityLevel är inställt på 5 som standard
    • usePrivateIp är inställt på false som standard. den här inställningen kan skrivas över av kommentaren use-private-ip
    • shared stöds inte vid tillägg
    • reconcilePeriodSeconds stöds inte vid tillägg
    • armAuth.type stöds inte vid tillägg
  • AGIC som distribueras via Helm stöder ProhibitedTargets, vilket innebär att AGIC kan konfigurera Application Gateway specifikt för AKS-kluster utan att påverka andra befintliga serverdelar. AGIC-tillägget stöder för närvarande inte den här funktionen.
  • Eftersom AGIC-tillägget är en hanterad tjänst uppdateras kunderna automatiskt till den senaste versionen av AGIC-tillägget, till skillnad från AGIC som distribueras via Helm där kunden måste uppdatera AGIC manuellt.

Kommentar

Kunder kan bara distribuera ett AGIC-tillägg per AKS-kluster, och varje AGIC-tillägg kan för närvarande bara rikta in sig på en Application Gateway. För distributioner som kräver mer än en AGIC per kluster eller flera AGIC:er som riktar sig mot en Application Gateway fortsätter du att använda AGIC som distribuerats via Helm.

Containernätverk och AGIC

Application Gateway Ingress Controller stöder följande AKS-nätverkserbjudanden:

  • Kubenet
  • CNI
  • CNI-överlägg

Azure CNI och Azure CNI Overlay är de två rekommenderade alternativen för Application Gateway Ingress Controller. När du väljer en nätverksmodell bör du överväga användningsfallen för varje CNI-plugin-program och vilken typ av nätverksmodell som används:

CNI-plugin Nätverksmodell Höjdpunkter för användningsfall
Azure CNI Overlay Överlagring - Bäst för VNET IP-bevarande
– Maximalt antal noder som stöds av API Server + 250 poddar per nod
– Enklare konfiguration
-Ingen direkt extern pod-IP-åtkomst
Azure CNI Pod-undernät Lägenhet – Direkt åtkomst till extern pod
– Sätt för effektiv användning av IP i virtuella nätverk eller stöd för stora klusterskalor (förhandsversion)
Azure CNI Node-undernät Lägenhet – Direkt åtkomst till extern pod
– Enklare konfiguration
– Begränsad skala
– Ineffektiv användning av virtuella nätverks-IP-adresser

När du etablerar Application Gateway för containrar i ett kluster som har CNI Overlay eller CNI aktiverat identifierar Application Gateway for Containers automatiskt den avsedda nätverkskonfigurationen. Det behövs inga ändringar i gateway- eller ingress-API-konfigurationen för att ange CNI-överlägg eller CNI.

Med Azure CNI Overlay bör du överväga följande begränsningar:

  • AGIC-kontrollant: Du måste köra version 1.8.0 eller senare för att kunna dra nytta av CNI Overlay.
  • Undernätsstorlek: Application Gateway-undernätet måste vara ett maximalt /24-prefix. endast en distribution stöds per undernät.
  • Regional VNet-peering: Application Gateway som distribueras i ett virtuellt nätverk i region A och AKS-klusternoderna i ett virtuellt nätverk i region A stöds inte.
  • Global VNet-peering: Application Gateway som distribueras i ett virtuellt nätverk i region A och AKS-klusternoderna i ett virtuellt nätverk i region B stöds inte.
  • Azure CNI Overlay med Application Gateway Ingress Controller stöds inte i Azure Government-molnet eller Microsoft Azure som drivs av 21Vianet (Azure i Kina).

Kommentar

Uppgradering av AKS-klustret från Kubnet eller CNI till CNI Overlay identifieras automatiskt av Application Gateway Ingress Controller. Vi rekommenderar att du schemalägger uppgraderingen under ett underhållsperiod eftersom trafikstörningar kan uppstå. Kontrollanten kan ta några minuter efter klusteruppgradering för att identifiera och konfigurera stöd för CNI Overlay.

Varning

Kontrollera att Application Gateway-undernätet är ett /24 eller mindre undernät innan du uppgraderar. Uppgradering från CNI till CNI Overlay med ett större undernät (dvs. /23) leder till ett avbrott och kräver att Application Gateway-undernätet återskapas med en undernätsstorlek som stöds.

Nästa steg