Konfigurera ingress med Kubernetes Gateway-API:et via tillägget för programroutning för Azure Kubernetes Service (AKS)

Tillägget för programroutning stöder Kubernetes Gateway-API:et för hantering av inkommande trafik. Kubernetes Gateway-API:et är en uppsättning resurser som tillhandahåller ett standardiserat, rollorienterat och utökningsbart ramverk för trafikhantering som är utformat för att vara en efterföljande och utveckling av ingress-API:et. Implementeringen av API:et för programdirigeringsgateway syftar därför till att fungera som en efterföljare till det hanterade NGINX-tillägget , som baseras på det äldre INGRESS-API:et och slutar ta emot Azure-support från Azure efter november 2026. Om du använder hanterad NGINX måste du migrera till implementeringen av gateway-API:et för programroutning eller en annan implementering som stöds senast i november 2026.

För produktionsarbetsbelastningar är den här modellen den rekommenderade standardingressmodellen på AKS Automatic. Från och med AKS version 1.36 använder nya AKS-automatiska kluster Kubernetes Gateway-API via tillägget för programroutning som standard. Bakgrund om standardvärden för automatisk AKS-produktion finns i Vad är Azure Kubernetes Service (AKS) Automatisk?

Jämförelse med tillägget Istio service mesh

Api-implementeringen av Kubernetes Gateway API för programroutning distribuerar en Istio-kontrollplan för att hantera infrastruktur för Kubernetes Gateway API-resurser. Det skiljer sig dock från tillägget för AKS:s Istio-tjänstnät på följande sätt:

Feature API för applikationsdirigeringsgateway Tillägg för Istio-tjänstnät
Namn på gatewayklass approuting-istio istio
Stöd för sidovagnsinjektion och Istio CRD Stöds inte. Hanterar endast infrastruktur för Kubernetes Gateway API-resurser Stöds
Revision och uppgraderingar Inte reviderad. Uppgraderad på plats för både delversions- och korrigeringsversionsuppdateringar Har reviderats. Uppgraderas via kanarieuppgraderingar för mindre versionsuppdateringar och på plats för uppdateringar av patch-versioner.

När du ska använda gateway-API:et för programroutning i produktion

Använd den här implementeringen som standardväg för ingress när du vill:

  • Ett produktionsklart, hanterat ingress-standardval i AKS Automatic.
  • HTTP/HTTPS-ingress för Kubernetes med inbyggt stöd för Gateway API.
  • Hanterad gateway-infrastruktur med inbyggda skyddsmekanismer för drift, såsom autoskalning och störningsbudgetar för gateway-proxyservrar.

Överväg alternativ när du behöver funktioner utanför aktuell support i den här artikeln, till exempel:

  • Trafikhantering i servicenät
  • Funktioner som anges i Begränsningar.

Begränsningar

  • Du kan inte konfigurera storleksgränser för begärandehuvud och brödtext, Lua-skript eller lokala och globala hastighetsbegränsningar genom den här implementeringen. Gateway API har inga standardfält för de här funktionerna, och implementeringen av App Routing Gateway API har inte stöd för EnvoyFilter.

    Om du behöver de här funktionerna när du migrerar från ingress-nginx bör du överväga gateway-API-ingress med tillägget Istio Service Mesh. Du kan använda Gateway, HTTPRoute och andra Gateway API-resurser utan att injicera sidecars i dina arbetsbelastningar och tillämpa en gateway-avgränsad EnvoyFilter för att konfigurera dem. Problem som orsakas av EnvoyFilter konfigurationen finns utanför Azure support. Om du väljer tjänstnätstillägget Istio måste du påbörja och slutföra canary-uppgraderingar vid mindre revisionsuppdateringar, även om du bara använder det för ingress.

    Testa varje ersättning för en nginx-anteckning eller kodfragment mot Din Istio-revision. Envoys buffertfilter framtvingar till exempel en storleksgräns för brödtexten genom att lagra hela begärandetexten i minnet innan det vidarebefordras. Det skrivs inte till disk.

  • Du kan inte aktivera Gateway API-implementeringen för programdirigering och tillägget Istio service mesh samtidigt. Du måste inaktivera den ena först och aktivera den andra i en separat åtgärd. När du övergår från Istio service mesh-tillägget till implementeringen av Gateway API:et för programroutning måste du ta bort Istio GatewayClass och Istio CRDs efter att du har inaktiverat Istio-tillägget. Istio-tillägget installerar CRD:er (till exempel virtualservices.networking.istio.io, destinationrules.networking.istio.iooch andra i networking.istio.iogrupperna , security.istio.io, telemetry.istio.iooch extensions.istio.io API) som inte tas bort när tillägget är inaktiverat. Om dessa CRD:er finns kvar i klustret, startar inte kontrollplanet för Istio-applikationsdirigerings-gatewayens API. Kör följande kommando för att ta bort dem:

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

    Anmärkning

    Om du har befintliga anpassade Istio-resurser (till exempel VirtualServices eller DestinationRules) tas även dessa resurser bort om du tar bort crd:erna. Se till att du inte längre behöver dem innan du fortsätter.

  • Api-implementeringen för programroutning använder samma lista över tillåtna resursanpassningar som Istio-tillägget för validering av ConfigMap-anpassningar för Gateway resurser. Tilläggshanterade webhooks blockerar anpassningar som inte finns med i listan över tillåtna.

  • Utgående trafikhantering via programdirigeringens Gateway API-implementering stöds inte.

  • Det finns inte officiellt stöd för att mata in icke-Microsoft-hanterade sidovagnar (till exempel anpassad telemetri, loggning eller säkerhetsagenter) i Istio-gatewayproxypoddarna som hanteras av tillägget för programroutning. Om du väljer att mata in din egen sidovagn i en hanterad proxypodd ger Microsoft endast bästa möjliga stöd för eventuella problem du stöter på.

  • Åtkomstloggning i Envoy är aktiverad som standard på Gateway-proxypoddar, men loggformatet, omfattningen och leverantören kan inte anpassas via Istio Telemetry API. Om du vill anpassa använder du gateway-API-ingressen i tillägget Istio Service Mesh i stället.

Förutsättningar

Uppdatera Azure CLI-versionen

Du måste använda azure-cli version 2.86.0 eller högre. Kör az --version för att hitta din azure-cli version och kör az upgrade för att uppgradera.

Aktivera CRD:erna för Managed Gateway API

Aktivera API-installationen för Managed Gateway. Användning av självhanterade GATEWAY-API CRD:er med tillägget för programroutning stöds inte.

AKS Automatiskt standardbeteende (AKS 1.36 och senare)

I nya AKS-automatiska kluster som kör AKS 1.36 eller senare aktiveras Kubernetes Gateway API via tillägget för programroutning som standard.

Du behöver vanligtvis inte köra kommandot för funktionsaktivering om du inte gör följande:

  • Använda ett befintligt kluster.
  • Köra en tidigare AKS-version.
  • Återaktivera funktionen när den har inaktiverats.

Aktivera implementeringen av gateway-API:et för programroutning

Anmärkning

Om du skapar ett nytt AKS-automatiskt kluster på AKS 1.36 eller senare är den här funktionen aktiverad som standard. Använd kommandona i det här avsnittet för AKS Standard-kluster, tidigare versioner eller befintliga kluster som inte redan har funktionen aktiverad.

Aktivera när klustret skapas

Kör följande kommando för att aktivera implementeringen av gateway-API:et för programroutning när AKS Standard-klustret skapas:

# 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-gateway-api --enable-app-routing-istio

Aktivera för ett befintligt kluster

Kör följande kommando för att aktivera implementeringen av gateway-API:et för programroutning för ett befintligt kluster:

# 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-gateway-api --enable-app-routing-istio

Du bör se istiod poddar i aks-istio-system namnområdet:

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

Du bör också se ValidatingWebhookConfiguration bli distribuerad:

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

Om du har aktiverat API-installationen för Managed Gateway bör du även se anpassningen av Istio Gateway ConfigMap skapas:

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

Konfigurera ingress med en Kubernetes Gateway

Distribuera exempelprogram

Distribuera först exempelprogrammet httpbin i default namnområdet:

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

Skapa Kubernetes Gateway och HTTPRoute

Distribuera sedan en gateway-API-konfiguration i default-namnrymden med gatewayClassName satt till 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

Anmärkning

Exemplet ovan skapar en extern ingress load balancer-tjänst som är tillgänglig utanför klustret. Du kan lägga till anteckningar för att skapa en intern lastbalanserare och anpassa andra inställningar för lastbalanserare.

Anmärkning

Som standardinställning lägger Istio-kontrollplanet till GatewayClass-namnet approuting-istio till namnet på de resurser som det etablerar för Gateway. Du kan kommentera resursen Gateway med gateway.istio.io/name-override för att åsidosätta namnet på de etablerade resurserna. Resursnamnen måste vara mindre än 63 tecken och måste vara ett giltigt DNS-namn.

Kontrollera att en Deployment, Service, HorizontalPodAutoscaleroch PodDisruptionBudget skapas för 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

Skicka begäran till exempelapplikationen

Försök slutligen skicka en curl begäran till programmet httpbin . INGRESS_HOST Ange först miljövariabeln:

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}')

Försök sedan skicka en HTTP-begäran till httpbin:

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

Du bör se ett HTTP 200 svar.

Anmärkning

Information om hur du skyddar inkommande trafik med implementeringen av gateway-API:et för programroutning och integrering med Azure DNS för hantering av värdnamn finns i Konfigurera Azure DNS och TLS med implementeringen av gateway-API:et för programdirigering för det automatiserade arbetsflödet som drivs av programroutningsoperatorn. Ett manuellt arbetsflöde för TLS-avslutning som inte förlitar sig på operatörens integrering finns i Skydda inkommande trafik med implementeringen av gateway-API:et för programroutning.

Om du vill använda Terraform för att skapa ett AKS-kluster med implementeringen av gateway-API:et för programroutning aktiverad behöver du:

  • Terraform-versionen1.9.0 eller senare installerad.
  • Azure CLI installerat och autentiserat. Kör az --version för att hitta din azure-cli version och kör az upgrade för att uppgradera. Du använder Azure CLI för att ansluta till klustret när Terraform har skapat det.
  • kubectl installerat. Du kan installera den lokalt med hjälp az aks install-cli av kommandot . Du använder kubectl för att distribuera exempelprogrammet och gateway-API-resurserna.

Distribuera ett AKS-kluster med implementeringen av gateway-API:et för programroutning med Terraform

Det här avsnittet visar hur du använder Terraform för att distribuera ett AKS-kluster med API-installationen för Managed Gateway och implementeringen av gateway-API:et för programroutning aktiverat.

Det här exemplet distribuerar:

  • En resursgrupp.
  • Ett AKS-kluster som använder Azure CNI-nätverksinsticksprogram och en standardlastbalanserare.
  • Api-installationen för Managed Gateway och implementeringen av gateway-API:et för programdirigering, båda aktiverade i klustret via AzAPI-providern. Om du aktiverar båda inställningarna blir AKS-hanterad approuting-istio GatewayClass tillgänglig i klustret.
  1. Skapa en katalog för att testa och köra Terraform-exempelkoden och gör den till den aktuella katalogen.

  2. Skapa en fil med namnet main.tfoch infoga följande kod:

    terraform {
      required_version = ">= 1.9.0"
    
      required_providers {
        azurerm = {
          source  = "hashicorp/azurerm"
          version = "~> 4.0"
        }
        azapi = {
          source  = "Azure/azapi"
          version = "~> 2.0"
        }
        random = {
          source  = "hashicorp/random"
          version = "~> 3.0"
        }
      }
    }
    
    provider "azurerm" {
      features {}
    }
    
    provider "azapi" {
      enable_preflight = true
    }
    
    resource "random_string" "suffix" {
      length  = 6
      upper   = false
      special = false
    }
    
    locals {
      location            = "eastus"
      resource_group_name = "rg-aks-gateway-api-${random_string.suffix.result}"
      cluster_name        = "aks-gwapi-${random_string.suffix.result}"
    }
    
    resource "azurerm_resource_group" "example" {
      name     = local.resource_group_name
      location = local.location
    }
    
    resource "azurerm_kubernetes_cluster" "example" {
      name                              = local.cluster_name
      location                          = azurerm_resource_group.example.location
      resource_group_name               = azurerm_resource_group.example.name
      dns_prefix                        = local.cluster_name
      role_based_access_control_enabled = true
    
      default_node_pool {
        name       = "system"
        node_count = 2
        vm_size    = "Standard_D4s_v4"
    
        upgrade_settings {
          drain_timeout_in_minutes      = 0
          max_surge                     = "10%"
          node_soak_duration_in_minutes = 0
        }
      }
    
      identity {
        type = "SystemAssigned"
      }
    
      network_profile {
        network_plugin    = "azure"
        load_balancer_sku = "standard"
      }
    }
    
    resource "azapi_update_resource" "gateway_api_app_routing" {
      type        = "Microsoft.ContainerService/managedClusters@2026-03-01"
      resource_id = azurerm_kubernetes_cluster.example.id
      body = {
        properties = {
          ingressProfile = {
            gatewayAPI = {
              installation = "Standard"
            }
            webAppRouting = {
              gatewayAPIImplementations = {
                appRoutingIstio = {
                  mode = "Enabled"
                }
              }
            }
          }
        }
      }
      response_export_values = [
        "properties.ingressProfile"
      ]
      depends_on = [
        azurerm_kubernetes_cluster.example
      ]
    }
    
    output "resource_group_name" {
      value = azurerm_resource_group.example.name
    }
    
    output "cluster_name" {
      value = azurerm_kubernetes_cluster.example.name
    }
    
    output "get_credentials_command" {
      value = "az aks get-credentials --resource-group ${azurerm_resource_group.example.name} --name ${azurerm_kubernetes_cluster.example.name} --overwrite-existing"
    }
    
  3. Initiera Terraform genom att terraform init köra kommandot . Det här kommandot laddar ned de Azure providers som krävs för att hantera Azure resurser med Terraform.

    terraform init
    
  4. Formatera och verifiera konfigurationen genom att köra kommandona terraform fmt och terraform validate .

    terraform fmt
    terraform validate
    
  5. Skapa en Terraform-exekveringsplan genom att köra kommandot terraform plan. Det här kommandot visar de resurser som Terraform skapar eller ändrar i din Azure prenumeration.

    terraform plan
    
  6. Tillämpa Terraform-körningsplanen genom att köra kommandot terraform apply. Det här kommandot skapar de resurser som definierats i main.tf filen i din Azure-prenumeration. När du uppmanas till det anger du yes för att bekräfta.

    terraform apply
    

Ansluta till AKS-klustret med Terraform

  1. Hämta resursgruppen och klusternamnen från Terraform-utdata.

    terraform output -raw resource_group_name
    terraform output -raw cluster_name
    
  2. Konfigurera kubectl så att det ansluter till ditt kluster genom att använda kommandot az aks get-credentials. Det här kommandot laddar ned autentiseringsuppgifter och konfigurerar Kubernetes CLI för att använda dem. Ersätt <resource-group-name> och <cluster-name> med värdena från föregående steg. Du kan också köra terraform output -raw get_credentials_command för att hämta det fullständiga kommandot ready-to-run.

    az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
    
  3. Kontrollera att klustret är igång genom att köra kommandot kubectl get nodes.

    kubectl get nodes
    

Verifiera gateway-API-konfigurationen med hjälp av Terraform

  1. Bekräfta att istiod poddarna körs i aks-istio-system namnområdet.

    kubectl get pods -n aks-istio-system
    
  2. Bekräfta att approuting-istio GatewayClass finns och godkänns.

    kubectl get gatewayclass
    

    approuting-istio GatewayClass ska returnera True i kolumnen ACCEPTED.

Konfigurera ingress med hjälp av en Kubernetes Gateway med Terraform

Distribuera exempelprogrammet med terraform

Distribuera exempelprogrammet httpbin i default namnområdet:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/httpbin/httpbin.yaml

Kontrollera att httpbin podden och tjänsten är tillgängliga:

kubectl get pods -l app=httpbin
kubectl get svc httpbin

Skapa gateway- och HTTPRoute-resurser med Terraform

Gateway API-implementeringsexemplet för programroutning innehåller ett Gateway-manifest som skapar en HTTP-lyssnare på port 80 och använder den AKS-hanterade approuting-istio GatewayClass.

  1. Skapa en fil med namnet gateway.yamloch infoga följande kod:

    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
    
  2. Tillämpa Gatewaykonfigurationen:

    kubectl apply -f gateway.yaml
    

    Exemplet innehåller också ett HTTPRoute manifest som dirigerar begäranden till httpbin.example.com/gethttpbin tjänsten på port 8000.

  3. Skapa en fil med namnet httproute.yamloch infoga följande kod:

    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
    
  4. Tillämpa HTTPRoutekonfigurationen:

    kubectl apply -f httproute.yaml
    

Anmärkning

I föregående exempel skapas en extern ingress load balancer-tjänst som är tillgänglig utanför klustret. Du kan lägga till anteckningar för att skapa en intern lastbalanserare och anpassa andra inställningar för lastbalanserare.

Kontrollera att en Deployment, Service, HorizontalPodAutoscaleroch PodDisruptionBudget skapas för httpbin-gateway:

kubectl get deployment httpbin-gateway-approuting-istio
kubectl get service httpbin-gateway-approuting-istio
kubectl get hpa httpbin-gateway-approuting-istio
kubectl get pdb httpbin-gateway-approuting-istio

Skicka en begäran till exempelprogrammet med Terraform

Vänta tills gatewayen rapporterar ett Programmed villkor och hämta sedan dess externa adress:

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}')

Skicka sedan en begäran till httpbin via gatewayen:

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

Du bör se ett HTTP 200 svar.

Åtkomstloggning

Implementeringen av programroutnings-API:et Gateway aktiverar som standard Envoys åtkomstloggning för alla hanterade Gateway-proxypoddar. Åtkomstloggar skrivs till proxycontainerns standardutdata i standardtextformatet Envoy. Du kan visa loggarna med hjälp kubectl logsav :

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

Varje begäran som gatewayen hanterar skapar en loggrad som innehåller information, till exempel HTTP-metod, sökväg, svarskod, uppströmstjänst samt storlekar för begäran och svar. Den här informationen gör det enklare att observera inkommande trafik och felsöka routningsproblem utan ytterligare konfiguration.

Versionshantering och uppgraderingar

Gateway API-implementeringen för programdirigering distribuerar och uppgraderar Istio-kontrollplanet baserat på Kubernetes-versionen för AKS-klustret vid uppgraderingar av både delversioner och korrigeringsversioner. Den här modellen på plats överensstämmer med standardinställningarna för automatisk AKS-produktion, där plattformslivscykelhantering är utformad för att minska manuella åtgärder.

Istio-versionen är den högsta istio-delversionen som stöds och som är kompatibel med klustrets AKS-version. Om du till exempel har AKS-versionen 1.34 är 1.28 den högsta Istio-delversion som stöds (från och med mars 2026). Tänk på att den högsta istio-versionen som stöds för en viss Kubernetes-version kan skilja sig mellan Long-Term SUPPORT-kluster (LTS) och icke-LTS-kluster.

Om du vill hitta den högsta istio-delversionen som stöds för din AKS Kubernetes-version kontrollerar du versionskalendern för service mesh-tillägget. Även om implementeringen av Gateway API för programdirigering inte är versionshanterad, motsvarar Istio-kontrollplanets sekundärversion den angivna revisionen för service mesh-tillägget (t.ex. för service mesh-tillägget asm-1-28 är programdirigeringens Istio-kontrollplans sekundärversion 1.28). Du kan också se istio-delversionen genom att kontrollera korrigeringsversionen i istiod-distributionsbilden:

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

Uppgraderingar

Korrigerings- och delversionsuppgraderingar av Istio-kontrollplanet för implementeringen av gateway-API:et för programroutning sker på plats. Uppgraderingar av patchversioner sker automatiskt som en del av AKS-utgåvor. Delversionsuppgraderingar kan utlösas automatiskt eller manuellt beroende på AKS Kubernetes-versionen och tidpunkten för versioner av Istio-delversioner. Delversionsuppgraderingar sker i följande scenarier:

  • AKS-klustret uppgraderas till en ny version som har en högre högsta version av Istio som stöds knuten till den. Istio-kontrollplanet uppgraderas till den högre delversionen som en del av AKS-klusteruppgradering.
  • En ny Istio-version släpps för AKS och blir den högsta Istio-versionen som stöds för AKS-klusterversionen. Efter distributionen till din region uppgraderas Istio-kontrollplanet i klustret automatiskt till den nya delversionen. Om du vill följa nya versioner av Istio och se när den nya versionen distribueras till din region, följer du AKS-versioninformationen och AKS versionsspårare.

Trafikstörningar kan uppstå under uppgraderingsprocessen. För att minimera störningar under uppgraderingar installerar tillägget för programroutning en Horizontal Pod Autoscaler (HPA) med minst två repliker och en PodDisruptionBudget (PDB) med en minsta tillgänglighet på 1 för varje Gateway. Du kan anpassa dessa resurser för att ändra de här inställningarna.

Resursanpassningar

HPA-anpassning (Horizontal Pod Autoscaling) för kontrollplanet

Implementeringen av Gateway-API:et för programroutning stöder anpassning av Horizontal Pod Autoscaler (HPA) i Istio-kontrollplanet. istiod HPA-resursen har följande standardkonfigurationer:

  • Min. repliker: två
  • Maximalt antal repliker: Fem
  • CPU-användning: 80%

Anmärkning

För att förhindra konflikter med PodDisruptionBudget tillåter Gateway API-implementeringen för programrouting inte att minReplicas ställs in till ett värde som är lägre än det ursprungliga standardvärdet 2.

HPA-konfigurationen kan ändras genom korrigeringar och direktredigeringar. Exempel:

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

Anpassning av gatewayresurser

Implementeringen av Gateway API för applikationsdirigering stödjer anpassning av Gateway-resurserna via annotationer och ConfigMaps. Programroutning använder samma lista över tillåtna resursanpassningar som tillägget Istio Service Mesh för gateway-API-resursanpassning. Följ stegen i Gateway-API-dokumenten för Istio-tillägget för att konfigurera resurser som genereras för Gateways och se vilka fält som ingår i vitlistan.

Anmärkning

istio-gateway-class-defaults ConfigMap etableras och avstäms av AKS när CRD:erna för Managed Gateway-API:erna och implementeringen av gateway-API:et för programroutning aktiveras tillsammans. Om du tidigare har skapat istio-gateway-class-defaults ConfigMap i aks-istio-system namnområdet själv måste du ta bort den självhanterade ConfigMap-instansen innan du aktiverar CRD:erna för den hanterade Gateway-API:en för att undvika konflikter med avstämning av den AKS-hanterade ConfigMap.

Anmärkning

Gateway API-implementeringen för programroutning lägger till Azure Load Balancer-annoteringar till Gateway Service för att konfigurera hälsoavsökningar för standardinställningen externalTrafficPolicy "Cluster". Om du ställer in spec.externalTrafficPolicy till "Local" måste du ta bort inställningen för följande annoteringar antingen i ConfigMap på GatewayClass-nivå eller i ConfigMap per gateway:

 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:

Inaktivera implementeringen av gateway-API:et för programroutning

Kör följande kommando för att inaktivera implementeringen av gateway-API:et för programroutning:

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

Rensa resurser

Kör följande kommandon för att ta bort Gateway resurserna och HTTPRoute :

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

Om du har skapat en ConfigMap för att anpassa din Gatewaykör du följande kommando för att ta bort ConfigMap:

kubectl delete configmap gw-options

Om du har skapat en SecretProviderClass och en hemlighet som ska användas för TLS-avslutning tar du bort följande resurser:

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

Rensa resurser med Terraform

I det här avsnittet driftsatte du en exempelapplikation som var begränsad till ett namnområde och Gateway API-resurser. Om du inte längre behöver dessa Kubernetes-resurser tar du bort dem innan du tar bort den underliggande Azure infrastrukturen.

Ta bort HTTPRoute, Gateway och exempelprogrammet med kommandot kubectl delete:

kubectl delete -f httproute.yaml
kubectl delete -f gateway.yaml
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/httpbin/httpbin.yaml

Warning

Följande kommando tar bort resursgruppen, AKS-klustret och alla andra resurser som är associerade med resursgruppen som skapats för det här exemplet. Om du har distribuerat andra resurser i den här resursgruppen tar kommandot också bort dem.

Ta bort Azure-resurserna som skapats av Terraform med kommandot terraform destroy. När du uppmanas till det anger du yes för att bekräfta.

terraform destroy