Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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,HTTPRouteet d’autres ressources de l’API Gateway sans injecter de sidecars dans vos charges de travail, et appliquer une ressourceEnvoyFilterà portée de passerelle pour les configurer. Les problèmes provoqués par laEnvoyFilterconfiguration 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.ioet d’autres dans les groupes d’APInetworking.istio.io,security.istio.io,telemetry.istio.ioetextensions.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 istioNote
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
Gatewayressources. 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 Terraform
1.9.0ou ultérieure installée. - Azure CLI installé et authentifié. Exécutez
az --versionpour rechercher votreazure-cliversion et exécutezaz upgradela 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-clicommande. Vous utilisezkubectlpour 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-istiodisponible sur le cluster.
Créez un répertoire pour tester et exécuter l’exemple de code Terraform et le rendre le répertoire actif.
Créez un fichier nommé
main.tfet 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" }Initialisez Terraform en exécutant la
terraform initcommande. Cette commande télécharge les fournisseurs Azure requis pour gérer les ressources Azure avec Terraform.terraform initMettez en forme et validez la configuration en exécutant les commandes
terraform validateetterraform fmt.terraform fmt terraform validateCréez un plan d’exécution Terraform en exécutant la
terraform plancommande. Cette commande vous montre les ressources que Terraform crée ou modifie dans votre abonnement Azure.terraform planAppliquez le plan d’exécution Terraform en exécutant la
terraform applycommande. Cette commande crée les ressources définies dans votremain.tffichier dans votre abonnement Azure. Lorsque vous y êtes invité, entrezyespour confirmer.terraform apply
Se connecter au cluster AKS à l’aide de Terraform
Obtenez les noms du groupe de ressources et du cluster à partir des sorties Terraform.
terraform output -raw resource_group_name terraform output -raw cluster_nameConfigurez
kubectlpour vous connecter à votre cluster à l’aide de laaz aks get-credentialscommande. 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écuterterraform output -raw get_credentials_commandpour obtenir la commande complète et prête à l’exécution.az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>Vérifiez que le cluster est en cours d’exécution en exécutant la
kubectl get nodescommande.kubectl get nodes
Vérifier la configuration de l’API de passerelle à l’aide de Terraform
Vérifiez que les
istiodpods sont en cours d’exécution dans l’espace de nomsaks-istio-system.kubectl get pods -n aks-istio-systemVérifiez que gatewayClass
approuting-istioexiste et est accepté.kubectl get gatewayclassGatewayClass
approuting-istiodoit retournerTruedans laACCEPTEDcolonne.
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.
Créez un fichier nommé
gateway.yamlet 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: SameAppliquez la
Gatewayconfiguration :kubectl apply -f gateway.yamlL’exemple inclut également un manifeste
HTTPRoutequi redirige les requêtes pourhttpbin.example.com/getvers le servicehttpbinsur le port8000.Créez un fichier nommé
httproute.yamlet 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: 8000Appliquez la
HTTPRouteconfiguration :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
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)