Ingress configureren met de Kubernetes Gateway API via de add-on voor app-routering voor Azure Kubernetes Service (AKS)

Waarschuwing

Het Kubernetes SIG Network en de Security Response Committee kondigde de aanstaande buitengebruikstelling van het NGINX-project voor inkomend verkeer aan, met een einde aan onderhoud in maart 2026. Er is momenteel geen onmiddellijke actie vereist voor AKS-clusters met behulp van de invoegtoepassing voor toepassingsroutering met NGINX. Microsoft biedt officiële ondersteuning tot en met november 2026 voor kritieke beveiligingspatches voor de application routing-add-on NGINX Ingress-resources.

AKS is afgestemd op upstream Kubernetes door over te stappen op gateway-API als de langetermijnstandaard voor inkomend verkeer en L7-verkeerbeheer. U wordt aangeraden uw migratiepad te plannen op basis van uw huidige installatie:

De invoegtoepassing voor toepassingsroutering ondersteunt de Kubernetes Gateway-API voor inkomend verkeerbeheer. De Kubernetes Gateway API is een set van resources die een gestandaardiseerd, rolgeoriënteerd en uitbreidbaar framework voor verkeersbeheer bieden, ontworpen als opvolger en evolutie van de Ingress API. De implementatie van de toepassingsroutering-gateway-API is dus bedoeld als opvolger van de beheerde NGINX-invoegtoepassing, die is gebaseerd op de verouderde Ingress API en na november 2026 zal geen Azure-ondersteuning meer ontvangen. Als u beheerde NGINX gebruikt, moet u tegen november 2026 migreren naar de gateway-API-implementatie van de toepassingsroutering of een andere ondersteunde implementatie.

Voor productieworkloads is dit model het aanbevolen standaardingressmodel op AKS Automatic. Vanaf AKS versie 1.36 gebruiken nieuwe AKS Automatische clusters standaard Kubernetes Gateway-API via de invoegtoepassing voor toepassingsroutering. Zie Wat is Azure Kubernetes Service (AKS) Automatisch voor achtergrondinformatie over de standaardinstellingen voor automatische AKS-productie?

Vergelijking met de Istio-servicemesh-invoegtoepassing

De Kubernetes Gateway-API-implementatie voor toepassingsroutering implementeert een Istio-besturingsvlak om infrastructuur voor Kubernetes Gateway-API-resources te beheren. Het verschilt echter op de volgende manieren van de invoegtoepassing Istio service mesh voor AKS :

Feature Gateway-API voor toepassingsroutering Invoegtoepassing voor Istio-service-mesh
Naam van gatewayklasse approuting-istio istio
Sidecar injectie en Istio CRD ondersteuning Wordt niet ondersteund. Beheert alleen infrastructuur voor Kubernetes Gateway-API-resources Ondersteund
Revisie en upgrades Niet herzien. In-place bijgewerkt voor zowel minor- als patchupdates Herzien. Bijgewerkt via canary-upgrades voor secundaire versie-updates en in-place voor patchversie-updates

Wanneer gebruikt u de gateway-API voor toepassingsroutering in productie

Gebruik deze implementatie als uw standaardpad voor inkomend verkeer wanneer u wilt:

  • Een productierijpe, beheerde ingress-standaard op AKS Automatic.
  • Kubernetes Gateway-API-systeemeigen HTTP/HTTPS-toegangsbeheerobjecten.
  • Beheerde gatewayinfrastructuur met ingebouwde operationele beveiliging, zoals automatische schaalaanpassing en onderbrekingsbudgetten voor gatewayproxy's.

Overweeg alternatieven wanneer u mogelijkheden buiten de huidige ondersteuning in dit artikel nodig hebt, zoals:

  • Volledig gedrag van de Istio-servicemesh met sidecar-gebaseerd verkeerbeheer en breder gebruik van Istio-CRD's.
  • Functies die momenteel worden vermeld als niet-ondersteund, zoals op TLSRoute gebaseerde SNI-passthrough.

Beperkingen

  • U kunt de implementatie van de gateway-API voor toepassingsroutering en de invoegtoepassing Istio-service-mesh niet tegelijk inschakelen. U moet er eerst een uitschakelen en de andere inschakelen in een afzonderlijke bewerking. Wanneer u overstapt van de invoegtoepassing istio-service-mesh naar de api-implementatie van de toepassingsrouteringsgateway, moet u de Istio GatewayClass en Istio CRD's verwijderen nadat u de Istio-invoegtoepassing hebt uitgeschakeld. De Istio-invoegtoepassing installeert CRD's (zoals virtualservices.networking.istio.io, destinationrules.networking.istio.ioen andere in de networking.istio.io, security.istio.ioen telemetry.istio.ioextensions.istio.io API-groepen) die niet worden verwijderd wanneer de invoegtoepassing is uitgeschakeld. Als deze CRD's op het cluster blijven staan, zal het controlevlak van de toepassingsrouterings Gateway API Istio niet starten. Voer de volgende opdracht uit om ze te verwijderen:

    kubectl delete crd $(kubectl get crd -o name | grep -E 'istio\.io')
    kubectl delete gatewayclass istio
    

    Opmerking

    Als u bestaande aangepaste Istio-resources (zoals VirtualServices of DestinationRules) hebt, worden deze resources ook verwijderd als u de CRD's verwijdert. Zorg ervoor dat u ze niet meer nodig hebt voordat u doorgaat.

  • De implementatie van de gateway-API voor toepassingsroutering maakt gebruik van dezelfde acceptatielijst voor resourceaanpassing als de Istio-invoegtoepassing voor het valideren van ConfigMap-aanpassingen voor Gateway resources. Door invoegtoepassingen beheerde webhooks blokkeren aanpassingen die niet in de acceptatielijst staan.

  • Het configureren van HTTPS-ingresstoegang tot HTTPS-services (bijvoorbeeld SNI-passthrough (Server Name Indication)) via de TLSRoute-resource wordt momenteel niet ondersteund. Ondersteuning voor de TLSRoute resource is beschikbaar zodra AKS ondersteuning voor Istio 1.30 toevoegt, waarna uw toepassingsrouteringsvlak automatisch wordt bijgewerkt naar die versie.

  • Uitgaand verkeerbeheer via de gateway-API-implementatie voor toepassingsroutering wordt niet ondersteund.

  • Het injecteren van sidecars die niet door Microsoft worden beheerd (bijvoorbeeld aangepaste telemetrie, logregistratie of beveiligingsagenten) in de Istio-gatewayproxypods die worden beheerd door de invoegtoepassing voor toepassingsroutering wordt niet officieel ondersteund. Als u ervoor kiest om uw eigen sidecar in een beheerde proxypod te injecteren, biedt Microsoft alleen best effort-ondersteuning voor eventuele problemen die u ondervindt.

  • Logboekregistratie voor envoy-toegang is standaard ingeschakeld voor gatewayproxypods, maar de logboekindeling, het bereik en de provider kunnen niet worden aangepast via de Istio-API Telemetry . Als u aanpassingen wilt doen, gebruikt u in plaats daarvan ingress van Gateway API op de add-on Istio-servicemesh.

Vereiste voorwaarden

Azure CLI-versie bijwerken

U moet versie azure-cli of hoger gebruiken2.86.0. Voer az --version uit om uw azure-cli-versie te vinden en voer az upgrade uit om te upgraden.

Beheerde Gateway API-CRD’s inschakelen

Schakel de installatie van de Managed Gateway-API in. Het gebruik van zelfbeheerde GATEWAY-API-CRD's met de invoegtoepassing voor toepassingsroutering wordt niet ondersteund.

AKS Automatisch standaardgedrag (AKS 1.36 en hoger)

Op nieuwe automatische AKS-clusters met AKS 1.36 of hoger is de Kubernetes Gateway-API standaard ingeschakeld via de invoegtoepassing voor toepassingsroutering.

Normaal gesproken hoeft u de opdracht voor het inschakelen van functies niet uit te voeren, tenzij u:

  • Een bestaand cluster gebruiken.
  • Een eerdere versie van AKS gebruiken.
  • Schakel de functie opnieuw in nadat deze is uitgeschakeld.

De implementatie van de gateway-API voor toepassingsroutering inschakelen

Opmerking

Als u een nieuw automatisch AKS-cluster op AKS 1.36 of hoger maakt, is deze functie standaard ingeschakeld. Gebruik de opdrachten in deze sectie voor AKS Standard-clusters, eerdere versies of bestaande clusters waarvoor de functie nog niet is ingeschakeld.

Inschakelen tijdens het maken van het cluster

Voer de volgende opdracht uit om de gateway-API-implementatie voor toepassingsroutering in te schakelen tijdens het maken van een AKS Standard-cluster:

# Set environment variables
export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>

# Enable the application routing Gateway API implementation during AKS Standard cluster creation
az aks create --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --enable-app-routing-istio

Inschakelen voor een bestaand cluster

Voer de volgende opdracht uit om de implementatie van de gateway-API voor toepassingsroutering in te schakelen voor een bestaand cluster:

# Set environment variables
export CLUSTER=<cluster-name>
export RESOURCE_GROUP=<resource-group-name>

# Enable the application routing Gateway API implementation for an existing cluster
az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --enable-app-routing-istio

Je zou istiod pods in de aks-istio-system namespace moeten zien.

kubectl get pods -n aks-istio-system
NAME                      READY   STATUS    RESTARTS   AGE
istiod-12a3bc45de-fghi6   1/1     Running   0          3m15s
istiod-78j9kl01mn-opqrs   1/1     Running   0          3m

U ziet ook dat de ValidatingWebhookConfiguration implementatie wordt uitgevoerd:

kubectl get validatingwebhookconfiguration
NAME                                        WEBHOOKS   AGE
aks-node-validating-webhook                 1          117m
azure-service-mesh-ccp-validating-webhook   1          4m2s

Als u de installatie van de Managed Gateway-API hebt ingeschakeld, ziet u ook dat de ConfigMap-aanpassing van de Istio-gateway wordt gemaakt:

kubectl get cm -n aks-istio-system
NAME                                  DATA   AGE
...
istio-gateway-class-defaults          2      43s
...

Inkomend verkeer configureren met behulp van een Kubernetes-gateway

Voorbeeldtoepassing implementeren

Implementeer eerst de voorbeeldtoepassing httpbin in de default naamruimte:

export ISTIO_RELEASE="release-1.27"
kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_RELEASE/samples/httpbin/httpbin.yaml

Kubernetes Gateway en HTTPRoute maken

Implementeer vervolgens een API-gatewayconfiguratie in de default naamruimte met de gatewayClassName ingesteld op approuting-istio.

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: httpbin-gateway
spec:
  gatewayClassName: approuting-istio
  listeners:
  - name: http
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin
spec:
  parentRefs:
  - name: httpbin-gateway
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
EOF

Opmerking

In het bovenstaande voorbeeld wordt een externe load balancer-service voor inkomend verkeer gemaakt die toegankelijk is van buiten het cluster. U kunt aantekeningen toevoegen om een interne load balancer te maken en andere load balancer-instellingen aan te passen.

Opmerking

Standaard zal het Istio-besturingsvlak de GatewayClass naam approuting-istio toevoegen aan de naam van de resources die het voor de Gateway voorziet. U kunt uw Gateway resource annoteren met gateway.istio.io/name-override om de naam van de ingerichte resources te wijzigen. De resourcenamen moeten kleiner zijn dan 63 tekens en moeten een geldige DNS-naam zijn.

Controleer of een Deployment, Service, HorizontalPodAutoscaler en PodDisruptionBudget worden aangemaakt voor httpbin-gateway:

kubectl get deployment httpbin-gateway-approuting-istio
NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
httpbin-gateway-approuting-istio   2/2     2            2           6m41s
kubectl get service httpbin-gateway-approuting-istio
NAME                               TYPE           CLUSTER-IP   EXTERNAL-IP      PORT(S)                        AGE
httpbin-gateway-approuting-istio   LoadBalancer   10.0.54.96   <external-ip>    15021:30580/TCP,80:32693/TCP   7m13s
kubectl get hpa httpbin-gateway-approuting-istio
NAME                               REFERENCE                                     TARGETS       MINPODS   MAXPODS   REPLICAS   AGE
httpbin-gateway-approuting-istio   Deployment/httpbin-gateway-approuting-istio   cpu: 3%/80%   2         5         2          8m13s
kubectl get pdb httpbin-gateway-approuting-istio
NAME                               MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
httpbin-gateway-approuting-istio   1               N/A               1                     9m1s

Aanvraag verzenden naar voorbeeldtoepassing

Probeer ten slotte een curl aanvraag naar de httpbin toepassing te verzenden. Stel eerst de INGRESS_HOST omgevingsvariabele in:

kubectl wait --for=condition=programmed gateways.gateway.networking.k8s.io httpbin-gateway
export INGRESS_HOST=$(kubectl get gateways.gateway.networking.k8s.io httpbin-gateway -ojsonpath='{.status.addresses[0].value}')

Verzend vervolgens een HTTP-aanvraag naar httpbin:

curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

U zou een HTTP 200 antwoord moeten zien.

Opmerking

Als u inkomend verkeer wilt beveiligen met de implementatie van de gateway-API voor toepassingsroutering en wilt integreren met Azure DNS voor hostnaambeheer, raadpleegt u Azure DNS en TLS configureren met de implementatie van de gateway-API voor toepassingsroutering voor de geautomatiseerde werkstroom die wordt mogelijk gemaakt door de operator voor toepassingsroutering. Voor een handmatige TLS-beëindigingswerkstroom die niet afhankelijk is van de integratie van de operator, raadpleegt u Inkomend verkeer beveiligen met de implementatie van de gateway-API voor toepassingsroutering.

Logboekregistratie van toegang

De implementatie van de gateway-API voor toepassingsroutering maakt logboekregistratie van Envoy-toegang standaard mogelijk voor alle beheerde Gateway proxypods. Toegangslogboeken worden weggeschreven naar de standaarduitvoer van de proxycontainer in de standaardtekstindeling van Envoy. U kunt de logboeken weergeven met behulp van kubectl logs:

kubectl logs deployment/<your-gateway-name>-approuting-istio

Elke aanvraag die door de gateway wordt verwerkt, produceert een logboekregel met details zoals de HTTP-methode, het pad, de antwoordcode, de upstream-service en de aanvraag- en antwoordgrootte. Deze details maken het gemakkelijker om inkomend verkeer te observeren en routeringsproblemen op te lossen zonder extra configuratie.

Versiebeheer en upgrades

De implementatie van de Gateway-API voor toepassingsroutering implementeert en upgradet het Istio-besturingsvlak op basis van de Kubernetes-versie van het AKS-cluster voor zowel secundaire als patchversie-upgrades. Dit in-place model is afgestemd op de standaardinstellingen voor automatische productie van AKS, waarbij platformlevenscyclusbeheer is ontworpen om handmatige bewerkingen te verminderen.

De Istio-versie is de maximaal ondersteunde Secundaire Versie van Istio die compatibel is met de AKS-versie van uw cluster. Als u bijvoorbeeld AKS-versie 1.34 gebruikt, is de hoogst ondersteunde Istio-minorversie die kan worden geïnstalleerd (vanaf maart 2026) 1.28. Houd er rekening mee dat de maximaal ondersteunde Istio-versie voor een bepaalde Kubernetes-versie kan verschillen tussen Long-Term LTS-clusters (Support) en niet-LTS-clusters.

Raadpleeg de releasekalender van de service mesh-invoegtoepassing om de hoogst ondersteunde Istio-minorversie voor uw AKS Kubernetes-versie te vinden. Hoewel de implementatie van de Gateway API voor applicatieroutering geen revisies kent, komt de mineurversie van het Istio control plane overeen met de opgegeven revisie van de service-mesh-add-on (bijvoorbeeld: voor service-mesh-add-on asm-1-28 is de mineurversie van het Istio control plane voor applicatieroutering 1.28). U kunt ook de secundaire versie van Istio bekijken door de patchversie in de installatiekopieën van de istiod-implementatie te controleren:

kubectl get deployment istiod -n aks-istio-system -o=jsonpath="{.spec.template.spec.containers[*].image}"

Verbeteringen

Patch- en secundaire versie-upgrades van het Istio-besturingsvlak voor de implementatie van de Gateway-API voor toepassingsroutering worden uitgevoerd. Upgrades van patchversies worden automatisch geactiveerd als onderdeel van AKS-releases. Upgrades van kleine versies kunnen automatisch of handmatig worden geactiveerd, afhankelijk van de AKS Kubernetes-versie en de timing van de releases van kleine versies van Istio. Er worden kleine versie-upgrades uitgevoerd in de volgende scenario's:

  • Het AKS-cluster wordt geüpgraded naar een nieuwe versie waarvoor een hogere maximaal ondersteunde Istio-versie is vastgezet. Het Istio-besturingsvlak wordt bijgewerkt naar de hogere secundaire versie als onderdeel van de upgrade van het AKS-cluster.
  • Er wordt een nieuwe Istio-versie uitgebracht voor AKS en wordt de maximaal ondersteunde Istio-versie voor de AKS-clusterversie. Na de implementatie naar uw regio wordt het Besturingsvlak van Istio in uw cluster automatisch bijgewerkt naar de nieuwe secundaire versie. Als u nieuwe Versies van Istio wilt bijhouden en wilt zien wanneer de nieuwe versie in uw regio wordt uitgebracht, volgt u de opmerkingen bij de AKS-release en de AKS-releasetracker.

Verkeersonderbrekingen kunnen optreden tijdens het upgradeproces. Om onderbrekingen tijdens upgrades tot een minimum te beperken, implementeert de add-on voor toepassingsroutering een Horizontal Pod Autoscaler (HPA) met minimaal twee replica's en een PodDisruptionBudget (PDB) met een minimale beschikbaarheid van één voor elke Gateway. U kunt deze resources aanpassen om deze instellingen te wijzigen.

Resourceaanpassingen

Aanpassing van de horizontale Pod Autoscaling (HPA) in de control plane

De implementatie van de Gateway-API voor toepassingsroutering ondersteunt aanpassing van het Istio-besturingsvlak Horizontal Pod Autoscaler (HPA). De istiod HPA-resource heeft de volgende standaardconfiguraties:

  • Minimumaantal replicas: twee
  • Maximum aantal replica's: vijf
  • CPU-gebruik: 80%

Opmerking

Om conflicten met de Gateway API-implementatie voor applicatieroutering van PodDisruptionBudget te voorkomen, staat deze niet toe dat minReplicas wordt ingesteld op minder dan de initiële standaardwaarde van 2.

De HPA-configuratie kan worden gewijzigd via patches en directe bewerkingen. Voorbeeld:

kubectl patch hpa istiod -n aks-istio-system --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

Aanpassing van gatewaybronnen

De implementatie van de gateway-API voor toepassingsroutering ondersteunt het aanpassen van de Gateway resources via aantekeningen en ConfigMaps. Toepassingsroutering maakt gebruik van dezelfde toegestane lijst voor resourceaanpassing als de Istio-service-mesh-add-on voor het aanpassen van Gateway-API-resources. Volg de stappen in de Api-documenten voor de Istio-invoegtoepassing om resources te configureren die zijn gegenereerd voor de Gateways en om te zien welke velden onder de acceptatielijst vallen.

Opmerking

De istio-gateway-class-defaults ConfigMap wordt ingericht en afgestemd door AKS wanneer de Managed Gateway API-CRD's en de gateway-API-implementatie voor toepassingsroutering samen worden ingeschakeld. Als u de istio-gateway-class-defaults ConfigMap eerder zelf in de aks-istio-system naamruimte hebt gemaakt, moet u het zelfbeheerde ConfigMap-exemplaar verwijderen voordat u de MANAGED Gateway-API-CRD's inschakelt om conflicten met afstemming van de door AKS beheerde ConfigMap te voorkomen.

Opmerking

De implementatie van de gateway-API voor toepassingsroutering voegt Azure Load Balancer aantekeningen toe aan de Gateway service om statustests te configureren voor de standaardinstelling externalTrafficPolicy 'Cluster'. Als u instelt spec.externalTrafficPolicy op 'Lokaal', moet u de volgende aantekeningen in de GatewayClass-niveau ConfigMap of de configuratiemap per gateway ongedaan maken:

 service: |
    spec:
       externalTrafficPolicy: Local
    metadata:
      annotations:
        service.beta.kubernetes.io/port_80_health-probe_port:
        service.beta.kubernetes.io/port_80_health-probe_protocol:
        service.beta.kubernetes.io/port_80_health-probe_request-path:

De implementatie van de gateway-API voor toepassingsroutering uitschakelen

Voer de volgende opdracht uit om de implementatie van de gateway-API voor toepassingsroutering uit te schakelen:

az aks update --resource-group ${RESOURCE_GROUP} --name ${CLUSTER} --disable-app-routing-istio

De hulpbronnen opschonen

Voer de volgende opdrachten uit om de Gateway en HTTPRoute resources te verwijderen:

kubectl delete gateways.gateway.networking.k8s.io httpbin-gateway
kubectl delete httproute httpbin

Als u een ConfigMap hebt gemaakt om uw Gatewayconfiguratie aan te passen, voert u de volgende opdracht uit om de ConfigMap te verwijderen:

kubectl delete configmap gw-options

Als u een SecretProviderClass en een geheim hebt gemaakt dat moet worden gebruikt voor TLS-beëindiging, verwijdert u de volgende resources:

kubectl delete secret httpbin-credential
kubectl delete pod secrets-store-sync-httpbin
kubectl delete secretproviderclass httpbin-credential-spc