Configurer l’entrée avec l’API Kubernetes Gateway via le module complémentaire de routage des applications pour Azure Kubernetes Service (AKS)

Le module complémentaire de routage des applications prend en charge l’API de passerelle Kubernetes pour la gestion du trafic d’entrée. L’API Gateway Kubernetes est un ensemble de ressources qui fournissent une infrastructure standardisée, orientée rôle et extensible pour la gestion du trafic, conçue pour être un successeur et une évolution de l’API Ingress. L’implémentation de l’API passerelle de routage d’application vise donc à servir de successeur au module complémentaire NGINX géré, qui est basé sur l’API Ingress héritée et cessera de recevoir le support Azure après novembre 2026. Si vous utilisez NGINX managé, vous devez migrer vers l’implémentation de l’API passerelle de routage d’application ou une autre implémentation prise en charge, d’après novembre 2026.

Pour les charges de travail de production, ce modèle est le modèle d’entrée par défaut recommandé sur AKS Automatic. À compter d’AKS version 1.36, les nouveaux clusters automatiques AKS utilisent l’API De passerelle Kubernetes via le module complémentaire de routage d’application par défaut. Pour plus d’informations sur les valeurs par défaut de production automatique AKS, consultez Qu’est-ce que Azure Kubernetes Service (AKS) Automatique ?

Comparaison avec le module complémentaire Istio Service Mesh

La mise en œuvre de l’API Gateway Kubernetes de l’extension de routage d’application déploie un plan de contrôle Istio pour gérer l’infrastructure des ressources de l’API Gateway Kubernetes. Toutefois, il diffère du module complémentaire Istio Service Mesh pour AKS de la manière suivante :

Fonctionnalité API de passerelle de routage d'applications Module complémentaire Istio Service Mesh
Nom de la classe de passerelle approuting-istio istio
Injection de sidecar et prise en charge des CRD Istio Non pris en charge. Gère uniquement l’infrastructure pour les ressources d’API de passerelle Kubernetes Soutenu
Révisions et mises à niveau Non révisé. Mise à niveau sur place pour les mises à jour de versions mineures et correctives Révisé. Mise à niveau via des upgrades canaripour les mises à jour de versions mineures et sur place pour les mises à jour correctives.

Quand utiliser l’API passerelle de routage d’application en production

Utilisez cette implémentation comme chemin d’entrée par défaut lorsque vous le souhaitez :

  • Une entrée gérée prête pour la production par défaut sur AKS Automatic.
  • Entrée HTTP/HTTPS native de l’API de passerelle Kubernetes.
  • Infrastructure de passerelle gérée avec des mécanismes de protection opérationnelle intégrés, tels que la mise à l’échelle automatique et les budgets de perturbation appliqués aux proxys de passerelle.

Prenez en compte les alternatives lorsque vous avez besoin de fonctionnalités en dehors de la prise en charge actuelle dans cet article, par exemple :

  • Gestion du trafic dans un maillage de services.
  • Fonctionnalités répertoriées dans Limitations.

Limites

  • Vous ne pouvez pas configurer les limites d’en-tête de requête et de taille de corps, les scripts Lua ou la limitation de débit local et global par le biais de cette implémentation. Gateway API ne comporte pas de champs standard pour ces fonctionnalités, et l’implémentation App Routing de Gateway API ne prend pas en charge EnvoyFilter.

    Si vous avez besoin de ces fonctionnalités lors de la migration à partir d’ingress-nginx, envisagez l’entrée de l’API de passerelle avec le module complémentaire Istio Service Mesh. Vous pouvez utiliser Gateway, HTTPRoute et d’autres ressources de l’API Gateway sans injecter de sidecars dans vos charges de travail, et appliquer une ressource EnvoyFilter à portée de passerelle pour les configurer. Les problèmes provoqués par la EnvoyFilter configuration sont en dehors de support Azure. Si vous choisissez le module complémentaire de maillage de services Istio, vous devez lancer et mener à bien des mises à niveau canary lors des mises à jour de révisions mineures, même si vous l’utilisez uniquement pour l’ingress.

    Testez chaque remplacement d’une annotation ou d’un extrait de code nginx par rapport à votre révision Istio. Par exemple, le filtre de mémoire tampon d’Envoy applique une limite de taille de corps en maintenant le corps de la requête complète en mémoire avant de le transférer. Elle ne se déverse pas sur le disque.

  • Vous ne pouvez pas activer l’implémentation de l’API passerelle de routage d’application et le module complémentaire Istio Service Mesh en même temps. Vous devez d’abord désactiver un premier et activer l’autre dans une opération distincte. Lors de la transition du module complémentaire Istio Service Mesh vers l’implémentation de l’API de passerelle de routage d’application, vous devez supprimer les passerelles Istio GatewayClass et Istio CRD après avoir désactivé le module complémentaire Istio. Le module complémentaire Istio installe des CRD (tels que virtualservices.networking.istio.io, destinationrules.networking.istio.io et d’autres dans les groupes d’API networking.istio.io, security.istio.io, telemetry.istio.io et extensions.istio.io) qui ne sont pas supprimés lorsque le module complémentaire est désactivé. Si ces CRD restent sur le cluster, le plan de contrôle Istio de l’API de routage d'application via passerelle ne parvient pas à démarrer. Exécutez la commande suivante pour les supprimer :

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

    Note

    Si vous disposez de ressources personnalisées Istio existantes (telles que VirtualServices ou DestinationRules), la suppression des CRD supprime également ces ressources. Veillez à ne plus en avoir besoin avant de continuer.

  • L'implémentation de l'API de passerelle de routage d'application utilise la même liste d'autorisation de personnalisation des ressources que le module complémentaire Istio pour la validation des personnalisations ConfigMap pour les Gateway ressources. Les webhooks gérés de l’extension bloquent les personnalisations qui ne figurent pas dans la liste d’autorisations.

  • La gestion du trafic de sortie via l’implémentation de l’API Gateway pour le routage des applications n’est pas prise en charge.

  • L’injection de side-cars non gérés par Microsoft (par exemple, pour la télémétrie personnalisée, la journalisation ou la sécurité) dans les pods du proxy de passerelle Istio gérés par le module complémentaire de routage applicatif n’est pas officiellement prise en charge. Si vous choisissez d’injecter votre propre side-car dans un pod proxy géré, Microsoft fournit uniquement une assistance dans la mesure du possible pour tout problème que vous rencontrez.

  • La journalisation de l’accès Envoy est activée par défaut sur les pods proxy de passerelle, mais le format du journal, l’étendue et le fournisseur ne peuvent pas être personnalisés via l’API Istio Telemetry . Pour personnaliser, utilisez plutôt l’entrée de l’API de passerelle sur le module complémentaire Istio Service Mesh .

Prerequisites

Mettre à jour la version d’Azure CLI

Vous devez utiliser la version azure-cli2.86.0 ou une version ultérieure. Exécutez az --version pour rechercher votre azure-cli version et exécutez az upgrade la mise à niveau.

Activer les CRD de Managed Gateway API

Activez l’installation de l’API de passerelle gérée. L’utilisation de CRD de l’API Gateway autogérée avec l’extension de routage d’application n’est pas prise en charge.

Comportement par défaut automatique AKS (AKS 1.36 et versions ultérieures)

Sur les nouveaux clusters automatiques AKS exécutant AKS 1.36 ou version ultérieure, l’API Kubernetes Gateway via le module complémentaire de routage d’application est activée par défaut.

En règle générale, vous n’avez pas besoin d’exécuter la commande d’activation de fonctionnalité, sauf si vous êtes :

  • Utilisation d’un cluster existant.
  • Utilisation d’une version antérieure d’AKS.
  • Réactivez la fonctionnalité après sa désactivation.

Activer l’implémentation de l’API passerelle de routage d’application

Note

Si vous créez un cluster automatique AKS sur AKS 1.36 ou version ultérieure, cette fonctionnalité est activée par défaut. Utilisez les commandes de cette section pour les clusters AKS Standard, les versions antérieures ou les clusters existants qui n’ont pas encore activé la fonctionnalité.

Activer lors de la création du cluster

Exécutez la commande suivante pour activer l’implémentation de l’API passerelle de routage d’application lors de la création du cluster AKS Standard :

# 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

Activer pour un cluster existant

Exécutez la commande suivante pour activer l’implémentation de l’API passerelle de routage d’application pour un cluster existant :

# 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

Vous devriez voir istiod pods dans aks-istio-system l’espace de noms :

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

Vous devriez également voir le déploiement de ValidatingWebhookConfiguration :

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

Si l’installation de l’API de passerelle managée est activée, vous devez également voir le ConfigMap de personnalisation de la passerelle Istio être créé :

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

Configurer l’entrée à l’aide d’une passerelle Kubernetes

Déployer un exemple d’application

Tout d'abord, déployez l'exemple d'application httpbin dans l'espace de noms default.

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

Créer une passerelle Kubernetes et HTTPRoute

Ensuite, déployez une configuration d'API de passerelle dans l'espace de noms default avec la valeur gatewayClassName définie sur 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

Note

L’exemple ci-dessus crée un service d’équilibreur de charge d’entrée externe accessible à partir de l’extérieur du cluster. Vous pouvez ajouter des annotations pour créer un équilibreur de charge interne et personnaliser d’autres paramètres d’équilibreur de charge.

Note

Par défaut, le plan de contrôle Istio ajoutera le nom GatewayClassapprouting-istio au nom des ressources qu'il provisionne pour le Gateway. Vous pouvez annoter votre Gateway ressource avec gateway.istio.io/name-override afin de remplacer le nom des ressources approvisionnées. Les noms de ressources doivent comporter moins de 63 caractères et être des noms DNS valides.

Vérifiez qu'un Deployment, Service, HorizontalPodAutoscaler, et PodDisruptionBudget sont créés pour 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

Envoyer une demande à un exemple d’application

Enfin, essayez d’envoyer une curl demande à l’application httpbin. Tout d’abord, définissez la variable d’environnement INGRESS_HOST :

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

Ensuite, essayez d’envoyer une requête HTTP à httpbin:

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

Vous devriez voir une HTTP 200 réponse.

Note

Pour sécuriser le trafic d’entrée avec l’implémentation de l’API passerelle de routage d’application et l’intégrer à Azure DNS pour la gestion des noms d’hôte, consultez Configurer Azure DNS et TLS avec l’implémentation de l’API passerelle de routage d’application pour le flux de travail automatisé alimenté par l’opérateur de routage d’application. Pour une procédure manuelle de terminaison TLS sans s’appuyer sur l’intégration de l’opérateur, consultez Sécuriser le trafic d’entrée avec l’implémentation de l’API Gateway de routage d’application.

Pour utiliser Terraform pour créer un cluster AKS avec l’implémentation de l’API passerelle de routage d’application activée, vous avez besoin des éléments suivants :

  • Version Terraform1.9.0 ou ultérieure installée.
  • Azure CLI installé et authentifié. Exécutez az --version pour rechercher votre azure-cli version et exécutez az upgrade la mise à niveau. Vous utilisez Azure CLI pour vous connecter au cluster après que Terraform l’a créé.
  • kubectl installé. Vous pouvez l’installer localement à l’aide de la az aks install-cli commande. Vous utilisez kubectl pour déployer l’exemple d’application et les ressources d’API de passerelle.

Déployer un cluster AKS avec l’implémentation de l’API passerelle de routage d’application à l’aide de Terraform

Cette section montre comment utiliser Terraform pour déployer un cluster AKS avec l’installation de l’API de passerelle gérée et l’implémentation de l’API passerelle de routage d’applications activées.

Note

L’exemple de code de cette section se trouve dans le dépôt Azure Terraform GitHub. Vous pouvez afficher le fichier journal contenant les résultats des tests des versions actuelles et précédentes de Terraform.

Consultez d’autres articles et exemples de code montrant comment utiliser Terraform pour gérer des ressources Azure.

Cet exemple déploie :

  • Un groupe de ressources.
  • Un cluster AKS qui utilise le plug-in réseau CNI Azure et un équilibreur de charge standard.
  • L’installation de l’API Managed Gateway et l’implémentation de Gateway API pour le routage des applications, toutes deux activées sur le cluster via le fournisseur AzAPI. L’activation des deux paramètres rend la classe de passerelle managée AKS approuting-istio disponible sur le cluster.
  1. Créez un répertoire pour tester et exécuter l’exemple de code Terraform et le rendre le répertoire actif.

  2. Créez un fichier nommé main.tf et insérez le code suivant :

    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. Initialisez Terraform en exécutant la terraform init commande. Cette commande télécharge les fournisseurs Azure requis pour gérer les ressources Azure avec Terraform.

    terraform init
    
  4. Mettez en forme et validez la configuration en exécutant les commandes terraform validate et terraform fmt.

    terraform fmt
    terraform validate
    
  5. Créez un plan d’exécution Terraform en exécutant la terraform plan commande. Cette commande vous montre les ressources que Terraform crée ou modifie dans votre abonnement Azure.

    terraform plan
    
  6. Appliquez le plan d’exécution Terraform en exécutant la terraform apply commande. Cette commande crée les ressources définies dans votre main.tf fichier dans votre abonnement Azure. Lorsque vous y êtes invité, entrez yes pour confirmer.

    terraform apply
    

Se connecter au cluster AKS à l’aide de Terraform

  1. Obtenez les noms du groupe de ressources et du cluster à partir des sorties Terraform.

    terraform output -raw resource_group_name
    terraform output -raw cluster_name
    
  2. Configurez kubectl pour vous connecter à votre cluster à l’aide de la az aks get-credentials commande. Cette commande télécharge les informations d’identification et configure l’interface CLI Kubernetes pour les utiliser. Remplacez <resource-group-name> et <cluster-name> par les valeurs notées à l’étape précédente. Vous pouvez également exécuter terraform output -raw get_credentials_command pour obtenir la commande complète et prête à l’exécution.

    az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>
    
  3. Vérifiez que le cluster est en cours d’exécution en exécutant la kubectl get nodes commande.

    kubectl get nodes
    

Vérifier la configuration de l’API de passerelle à l’aide de Terraform

  1. Vérifiez que les istiod pods sont en cours d’exécution dans l’espace de noms aks-istio-system.

    kubectl get pods -n aks-istio-system
    
  2. Vérifiez que gatewayClass approuting-istio existe et est accepté.

    kubectl get gatewayclass
    

    GatewayClass approuting-istio doit retourner True dans la ACCEPTED colonne.

Configurer l’entrée à l’aide d’une passerelle Kubernetes avec Terraform

Déployer l’exemple d’application à l’aide de Terraform

Déployez l’application exemple httpbin dans l’espace de noms default :

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

Vérifiez que le httpbin pod et le service sont disponibles :

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

Créer les ressources Passerelle et HTTPRoute à l’aide de Terraform

L’exemple d’implémentation de l’API Gateway pour le routage des applications inclut un manifeste Gateway qui crée un écouteur HTTP sur le port 80 et utilise la GatewayClass approuting-istio gérée par AKS.

  1. Créez un fichier nommé gateway.yaml et insérez le code suivant :

    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. Appliquez la Gateway configuration :

    kubectl apply -f gateway.yaml
    

    L’exemple inclut également un manifeste HTTPRoute qui redirige les requêtes pour httpbin.example.com/get vers le service httpbin sur le port 8000.

  3. Créez un fichier nommé httproute.yaml et insérez le code suivant :

    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. Appliquez la HTTPRoute configuration :

    kubectl apply -f httproute.yaml
    

Note

L’exemple précédent crée un service d’équilibreur de charge d’entrée externe accessible à partir de l’extérieur du cluster. Vous pouvez ajouter des annotations pour créer un équilibreur de charge interne et personnaliser d’autres paramètres d’équilibreur de charge.

Vérifiez qu'un Deployment, Service, HorizontalPodAutoscaler, et PodDisruptionBudget sont créés pour 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

Envoyer une requête à l’exemple d’application à l’aide de Terraform

Attendez que la passerelle signale une Programmed condition, puis obtenez son adresse externe :

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

Ensuite, envoyez une requête via la passerelle httpbin :

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

Vous devriez voir une HTTP 200 réponse.

Journalisation des accès

L’implémentation de la Gateway API du routage applicatif active par défaut la journalisation des accès d’Envoy sur tous les pods proxy gérés Gateway. Les journaux d’accès sont consignés dans la sortie standard du conteneur de proxy, au format texte Envoy par défaut. Vous pouvez afficher les journaux à l’aide de kubectl logs:

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

Chaque demande que la passerelle gère génère une ligne de journal contenant des détails tels que la méthode HTTP, le chemin d’accès, le code de réponse, le service en amont et les tailles de requête et de réponse. Ce détail facilite l’observation du trafic d’entrée et la résolution des problèmes de routage sans configuration supplémentaire.

Contrôle de version et mises à niveau

L’implémentation de l’API passerelle de routage d’application déploie et met à niveau le plan de contrôle Istio basé sur la version Kubernetes du cluster AKS pour les mises à niveau de version mineure et corrective. Ce modèle sur place s’aligne sur les valeurs par défaut de production automatiques AKS, où la gestion du cycle de vie de la plateforme est conçue pour réduire les opérations manuelles.

La version d’Istio correspond à la version mineure maximale d’Istio prise en charge, compatible avec la version d’AKS de votre cluster. Par exemple, si vous utilisez AKS en version 1.34, la version mineure maximale prise en charge d’Istio pouvant être installée (en mars 2026) est 1.28. Gardez à l’esprit que la version maximale d’Istio prise en charge pour une version donnée de Kubernetes peut différer entre les clusters Long-Term Support (LTS) et les clusters non-LTS.

Pour rechercher la version mineure d’Istio prise en charge maximale pour votre version d’AKS Kubernetes, consultez le calendrier de publication du module complémentaire service mesh. Bien que l’implémentation de l’API de passerelle de routage d’application ne soit pas révisée, la version mineure du plan de contrôle Istio correspond à la révision du module complémentaire de maillage de service donnée (par exemple, pour le module complémentaire asm-1-28de maillage de service, la version mineure du plan de contrôle Istio de routage des applications est 1.28). Vous pouvez également voir la version mineure d’Istio en vérifiant la version corrective dans l’image de déploiement istiod :

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

Mises à niveau

Les mises à niveau correctives et mineures du plan de contrôle Istio pour l’implémentation de Gateway API pour le routage des applications s’effectuent sur place. Les mises à niveau des versions correctives sont déclenchées automatiquement dans le cadre des versions AKS. Les mises à niveau de version mineures peuvent être déclenchées automatiquement ou manuellement en fonction de la version et du minutage d’AkS Kubernetes des versions mineures d’Istio. Les mises à niveau de version mineures se produisent dans les scénarios suivants :

  • Le cluster AKS est mis à niveau vers une nouvelle version à laquelle est associée une version maximale d’Istio prise en charge plus élevée. Le plan de contrôle Istio est mis à niveau vers la version mineure supérieure dans le cadre de la mise à niveau du cluster AKS.
  • Une nouvelle version d’Istio est publiée pour AKS et devient la version maximale d’Istio prise en charge pour la version du cluster AKS. Après le déploiement vers votre région, le plan de contrôle Istio sur votre cluster est automatiquement mis à niveau vers la nouvelle version mineure. Pour suivre les nouvelles versions d’Istio et voir quand la nouvelle version est déployée dans votre région, suivez les notes de publication AKS et le suivi des versions AKS.

Les interruptions de trafic peuvent se produire pendant le processus de mise à niveau. Pour minimiser les perturbations pendant les mises à niveau, le module complémentaire de routage des applications déploie un Horizontal Pod Autoscaler (HPA) avec au moins deux répliques et un PodDisruptionBudget (PDB) avec une disponibilité minimale d'une réplique pour chaque Gateway. Vous pouvez personnaliser ces ressources pour modifier ces paramètres.

Personnalisations des ressources

Personnalisation de l’Horizontal Pod Autoscaling (HPA) du plan de contrôle

L'implémentation de l'API de passerelle pour le routage des applications supporte la personnalisation du plan de contrôle Istio (Horizontal Pod Autoscaler, HPA). La istiod ressource HPA a les configurations par défaut suivantes :

  • Répliques minimum : 2
  • Nombre maximal de réplicas : Cinq
  • Utilisation du processeur : 80%

Note

Pour éviter les conflits avec le PodDisruptionBudget, l’implémentation de l’API passerelle de routage d’application n’autorise pas la définition de la minReplicas valeur inférieure à la valeur par défaut initiale de 2.

La configuration HPA peut être modifiée par le biais de correctifs et de modifications directes. Exemple :

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

Personnalisation des ressources de passerelle

La mise en œuvre de l’API Gateway de routage d’application prend en charge la personnalisation des Gateway ressources via des annotations et des ConfigMap. Le routage d’application utilise la même liste d’autorisation de personnalisation des ressources que l’extension Istio Service Mesh pour la personnalisation des ressources de l’API Gateway. Suivez les étapes décrites dans la documentation de l'API Gateway du module complémentaire Istio pour configurer les ressources générées pour le Gateways et voir quels champs figurent sur la liste d'autorisation.

Note

Le istio-gateway-class-defaultsConfigMap est provisionné et réconcilié par AKS lorsque les CRD de l’API Gateway gérée et la mise en œuvre de l’API Gateway de routage d’application sont activées simultanément. Si vous avez précédemment créé vous-même le istio-gateway-class-defaults ConfigMap dans l’espace de noms aks-istio-system, vous devez supprimer l’instance de ConfigMap autogérée avant d’activer les CRD de l’API Gateway gérée afin d’éviter des conflits avec la réconciliation du ConfigMap géré par AKS.

Note

L’implémentation de l’API Gateway de routage des applications ajoute des annotations Azure Load Balancer au Gateway Service pour configurer les sondes d’intégrité pour le paramètre externalTrafficPolicy par défaut de « Cluster ». Si vous définissez spec.externalTrafficPolicy sur « Local », vous devez supprimer les annotations suivantes, soit dans la ConfigMap au niveau de GatewayClass, soit dans la ConfigMap propre à chaque passerelle :

 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:

Désactiver l’implémentation de l’API passerelle de routage d’application

Exécutez la commande suivante pour désactiver l’implémentation de l’API passerelle de routage d’application :

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

Nettoyer les ressources

Exécutez les commandes suivantes pour supprimer les ressources Gateway et HTTPRoute :

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

Si vous avez créé un ConfigMap pour personnaliser votre Gatewayfichier, exécutez la commande suivante pour supprimer ConfigMap :

kubectl delete configmap gw-options

Si vous avez créé secretProviderClass et secret à utiliser pour l’arrêt TLS, supprimez les ressources suivantes :

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

Nettoyer les ressources à l’aide de Terraform

Dans cette section, vous avez déployé une application d’exemple limitée à un espace de noms ainsi que des ressources de la Gateway API. Si vous n’avez plus besoin de ces ressources Kubernetes, supprimez-les avant de supprimer l’infrastructure Azure sous-jacente.

Supprimez le HTTPRoute, Gatewayet l’exemple d’application à l’aide de la kubectl delete commande :

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

La commande suivante supprime le groupe de ressources, le cluster AKS et toutes les autres ressources associées au groupe de ressources créé pour cet exemple. Si vous avez déployé d’autres ressources à l’intérieur de ce groupe de ressources, la commande les supprime également.

Supprimez les ressources Azure créées par Terraform à l’aide de la terraform destroy commande. Lorsque vous y êtes invité, entrez yes pour confirmer.

terraform destroy