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 :

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 :

• Un ingress managé prêt 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 :

• Comportement complet du maillage de services Istio avec une gestion du trafic basée sur des side-cars et une utilisation plus étendue des CRD Istio.
• Les fonctionnalités actuellement répertoriées comme non prises en charge, telles que la passe directe SNI basée sur TLSRoute.

Limites

• 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’autorisation.

• La configuration de l’accès d’entrée HTTPS aux services HTTPS (par exemple, l’indication de nom de serveur (SNI) passthrough) via la TLSRoute ressource n’est pas prise en charge actuellement. La prise en charge de la TLSRoute ressource sera disponible une fois qu’AKS ajoute la prise en charge d’Istio 1.30, à quel moment votre plan de contrôle Istio de routage d’application est automatiquement mis à niveau vers cette version.

• 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 sidecars non gérés par Microsoft (par exemple, une télémétrie personnalisée, la journalisation ou des agents de sécurité) dans les pods du proxy de passerelle Istio gérés par le module complémentaire de routage d'application 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

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-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-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

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.

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 réduire les interruptions pendant les mises à niveau, le module complémentaire de routage d’application déploie un HPA (Horizontal Pod Autoscaler) avec un minimum de deux réplicas et un PodDisruptionBudget (PDB) avec une disponibilité minimale d’un 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%

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.

 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

Contenu connexe

• Qu’est-ce que Azure Kubernetes Service (AKS) automatique ?
• Créer un cluster automatique AKS
• Configurer Azure DNS et TLS avec l’implémentation de l’API passerelle de routage d’application
• Sécuriser le trafic d’entrée avec l’implémentation de l’API passerelle de routage d’application (configuration manuelle)