Cloud Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Mises à jour de la configuration pour la modernisation

Ce document décrit les mises à jour de configuration que vous devrez peut-être apporter à votre Cloud Service Mesh géré avant de moderniser votre maillage vers le plan de contrôle TRAFFIC_DIRECTOR à partir du plan de contrôle ISTIOD.

Vous trouverez ci-dessous une liste des mises à jour de configuration possibles nécessaires pour préparer votre cluster à la modernisation. Consultez chaque section pour obtenir des instructions de mise à jour :

Multicluster
Activer la fédération d'identité de charge de travail pour GKE
Activer le CNI géré
Utilisation de binaires non standards dans Sidecar
Migrer vers la passerelle d'entrée Istio

Pour en savoir plus sur le workflow de modernisation, consultez la page Modernisation du plan de contrôle géré.

Migrer des secrets Istio vers multicluster_mode

Les secrets multiclusters ne sont pas compatibles lorsqu'un cluster utilise le plan de contrôle TRAFFIC_DIRECTOR. Ce document explique comment passer des secrets multiclusters Istio à multicluster_mode.

Présentation des secrets Istio par rapport à l'API déclarative

La découverte de points de terminaison multiclusters Istio Open Source fonctionne en utilisant istioctl ou d'autres outils pour créer un secret Kubernetes dans un cluster. Ce secret permet à un cluster d'équilibrer la charge du trafic vers un autre cluster du maillage. Le plan de contrôle ISTIOD lit ensuite ce secret et commence à acheminer le trafic vers cet autre cluster.

Cloud Service Mesh dispose d'une API déclarative permettant de contrôler le trafic multicluster au lieu de créer directement des secrets Istio. Cette API traite les secrets Istio comme un détail d'implémentation et est plus fiable que la création manuelle de secrets Istio. Les futures fonctionnalités de Cloud Service Mesh dépendront de l'API déclarative. Vous ne pourrez pas utiliser ces nouvelles fonctionnalités directement avec les secrets Istio. L'API déclarative est la seule voie à suivre.

Si vous utilisez des secrets Istio, migrez vers l'API déclarative dès que possible. Notez que le paramètre multicluster_mode indique à chaque cluster de diriger le trafic vers tous les autres clusters du maillage. L'utilisation de secrets permet une configuration plus flexible, ce qui vous permet de configurer pour chaque cluster vers quel autre cluster il doit diriger le trafic dans le maillage. Pour obtenir la liste complète des différences entre les fonctionnalités compatibles de l'API déclarative et les secrets Istio, consultez Fonctionnalités compatibles avec les API Istio.

Migrer des secrets Istio vers l'API déclarative

Si vous avez provisionné Cloud Service Mesh à l'aide de la gestion automatique avec l'API de la fonctionnalité Parc, vous n'avez pas besoin de suivre ces instructions. Ces étapes ne s'appliquent que si vous avez effectué l'intégration à l'aide de asmcli --managed.

Notez que ce processus modifie les secrets qui pointent vers un cluster. Au cours de ce processus, les points de terminaison sont supprimés, puis ajoutés à nouveau. Entre la suppression et l'ajout des points de terminaison, le trafic reviendra brièvement au routage local au lieu de l'équilibrage de charge vers d'autres clusters. Pour en savoir plus, consultez ce problème GitHub.

Pour passer des secrets Istio à l'API déclarative, procédez comme suit. Effectuez ces étapes en même temps ou l'une après l'autre sans tarder :

Activez l'API déclarative pour chaque cluster du parc dans lequel vous souhaitez activer la découverte de points de terminaison multiclusters en définissant multicluster_mode=connected. Notez que vous devez définir explicitement multicluster_mode=disconnected si vous ne souhaitez pas que le cluster soit détectable.

Utilisez la commande suivante pour activer la découverte des points de terminaison multicluster pour un cluster :
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Utilisez la commande suivante pour désactiver la découverte des points de terminaison pour un cluster :
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Supprimez les anciens secrets.

Après avoir défini multicluster_mode=connected sur vos clusters, un nouveau secret sera généré pour chaque cluster sur lequel multicluster_mode=connected est également défini. Le secret est placé dans l'espace de noms istio-system et présente le format suivant :
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Le libellé istio.io/owned-by: mesh.googleapis.com sera également appliqué à chaque secret.

Une fois les nouveaux secrets créés, vous pouvez supprimer manuellement ceux créés avec istioctl create-remote-secret :
```
kubectl delete secret SECRET_NAME -n istio-system
```

Une fois la migration effectuée, vérifiez vos métriques de requête pour vous assurer qu'elles sont routées comme prévu.

Activer la fédération d'identité de charge de travail pour GKE

La fédération d'identité de charge de travail est la méthode sécurisée recommandée pour les charges de travail Google Kubernetes Engine. Cela permet d'accéder aux services Google Cloud tels que Compute Engine, BigQuery et les API Machine Learning. La fédération d'identité de charge de travail ne nécessite pas de configuration manuelle ni de méthodes moins sécurisées telles que les fichiers de clé de compte de service, car elle utilise des stratégies IAM. Pour en savoir plus sur la fédération d'identité de charge de travail, consultez Fonctionnement de la fédération d'identité de charge de travail pour GKE.

La section suivante explique comment activer la fédération d'identité de charge de travail.

Activer Workload Identity Federation sur les clusters

Vérifiez que la fédération d'identité de charge de travail est activée pour votre cluster. Pour ce faire, assurez-vous que le pool de fédération d'identité de charge de travail est configuré sur le cluster GKE, ce qui est essentiel pour la validation des identifiants IAM.

Utilisez la commande suivante pour vérifier le pool d'identités de charge de travail défini pour un cluster :
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
Remplacez CLUSTER_NAME par le nom de votre cluster GKE. Si vous n'avez pas encore spécifié une zone ou une région par défaut pour gcloud, vous devrez peut-être également spécifier une option --region ou --zone lors de l'exécution de cette commande.
Si le résultat est vide, suivez les instructions de la section Mettre à jour un cluster existant pour activer Workload Identity sur les clusters GKE existants.

Activer la fédération d'identité de charge de travail sur les pools de nœuds

Une fois la fédération d'identité de charge de travail activée sur un cluster, les pools de nœuds doivent être configurés pour utiliser le serveur de métadonnées GKE.

Répertoriez tous les pools de nœuds d'un cluster standard. Exécutez la commande gcloud container node-pools list :
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
Remplacez CLUSTER_NAME par le nom de votre cluster GKE. Si vous n'avez pas encore spécifié une zone ou une région par défaut pour gcloud, vous devrez peut-être également spécifier une option --region ou --zone lors de l'exécution de cette commande.
Vérifiez que chaque pool de nœuds utilise le serveur de métadonnées GKE :
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
Remplacez les éléments suivants :
- NODEPOOL_NAME par le nom de votre pool de nœuds.
- CLUSTER_NAME par le nom de votre cluster GKE.
Si le résultat ne contient pas GKE_METADATA, mettez à jour le pool de nœuds à l'aide du guide Mettre à jour un pool de nœuds existant.

Activer l'interface réseau de conteneur (CNI) gérée

Cette section vous explique comment activer le CNI géré pour Cloud Service Mesh sur Google Kubernetes Engine.

Présentation du CNI géré

L'interface CNI (Container Network Interface) gérée est une implémentation de l'interface CNI Istio gérée par Google. Le plug-in CNI simplifie la mise en réseau des pods en configurant des règles iptables. Cela permet la redirection du trafic entre les applications et les proxys Envoy, ce qui élimine le besoin d'autorisations privilégiées pour le conteneur init requis pour gérer iptables.

Le plug-in CNI Istio remplace le conteneur istio-init. Le conteneur istio-init était auparavant chargé de configurer l'environnement réseau du pod pour permettre l'interception du trafic pour le side-car Istio. Le plug-in CNI effectue la même fonction de redirection réseau, mais avec l'avantage supplémentaire de réduire le besoin de privilèges élevés, ce qui améliore la sécurité.

Par conséquent, pour améliorer la sécurité et la fiabilité, et pour simplifier la gestion et le dépannage, le CNI géré est requis dans tous les déploiements Managed Cloud Service Mesh.

Impact sur les conteneurs init

Les conteneurs d'initialisation sont des conteneurs spécialisés qui s'exécutent avant les conteneurs d'application pour les tâches de configuration. Les tâches de configuration peuvent inclure le téléchargement de fichiers de configuration, la communication avec des services externes ou l'initialisation avant l'application. Les conteneurs d'initialisation qui dépendent de l'accès au réseau peuvent rencontrer des problèmes lorsque le CNI géré est activé dans le cluster.

Voici le processus de configuration des pods avec un CNI géré :

Le plug-in CNI configure les interfaces réseau des pods, attribue les adresses IP des pods et redirige le trafic vers le proxy side-car Istio qui n'a pas encore démarré.
Tous les conteneurs d'initialisation s'exécutent et se terminent.
Le proxy side-car Istio démarre en même temps que les conteneurs d'application.

Par conséquent, si un conteneur d'initialisation tente d'établir des connexions réseau sortantes ou de se connecter à des services au sein du maillage, les requêtes réseau des conteneurs d'initialisation peuvent être abandonnées ou mal acheminées. En effet, le proxy side-car Istio, qui gère le trafic réseau du pod, n'est pas en cours d'exécution lorsque les requêtes sont effectuées. Pour en savoir plus, consultez la documentation Istio CNI.

Activer le CNI géré pour votre cluster

Suivez les étapes de cette section pour activer le CNI géré sur votre cluster.

Supprimez les dépendances réseau de votre conteneur init. Envisagez les alternatives suivantes :
- Modifier la logique ou les conteneurs d'application : vous pouvez modifier vos services pour supprimer la dépendance aux conteneurs d'initialisation qui nécessitent des requêtes réseau ou effectuer des opérations réseau dans vos conteneurs d'application, une fois que le proxy side-car a démarré.
- Utilisez des ConfigMaps ou des secrets Kubernetes : stockez les données de configuration récupérées par la requête réseau dans des ConfigMaps ou des secrets Kubernetes, puis installez-les dans les conteneurs de votre application. Pour découvrir d'autres solutions, consultez la documentation Istio.
Activez le CNI géré sur votre cluster :
1. Apportez les modifications de configuration suivantes :
  1. Exécutez la commande suivante pour localiser le controlPlaneRevision.
```
kubectl get controlplanerevision -n istio-system
```
  2. Dans votre ressource personnalisée ControlPlaneRevision (CPR), définissez le libellé mesh.cloud.google.com/managed-cni-enabled sur true.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    Remplacez CPR_NAME par la valeur de la colonne "NAME" (NOM) de la sortie de l'étape précédente.
  3. Dans le ConfigMap asm-options, définissez la valeur ASM_OPTS sur CNI=on.
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. Dans votre ressource personnalisée ControlPlaneRevision (CPR), définissez le libellé mesh.cloud.google.com/force-reprovision sur true. Cette action déclenche le redémarrage du plan de contrôle.
    
    Remarque : Cette méthode n'est pas recommandée pour redémarrer le plan de contrôle. Elle ne doit être utilisée que pour les efforts de modernisation de Cloud Service Mesh.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. Vérifiez l'état de la fonctionnalité. Récupérez l'état de la fonctionnalité à l'aide de la commande suivante :
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  Remplacez FLEET_PROJECT_ID par l'ID de votre projet hôte de parc. En général, le FLEET_PROJECT_ID porte le même nom que le projet.
  - Vérifiez que la condition MANAGED_CNI_NOT_ENABLED a été supprimée de servicemesh.conditions.
  - Notez que la mise à jour de l'état peut prendre jusqu'à 15 à 20 minutes. Patientez quelques minutes, puis réexécutez la commande.
3. Une fois que controlPlaneManagement.state est Active dans l'état des fonctionnalités du cluster, redémarrez les pods.

Abandonner l'utilisation de binaires non standards dans Sidecar

Cette section suggère des méthodes pour rendre vos déploiements compatibles avec l'image de proxy Envoy sans distribution.

Images side-car de proxy Envoy Distroless

Cloud Service Mesh utilise deux types d'images side-car de proxy Envoy en fonction de votre configuration du plan de contrôle : une image basée sur Ubuntu contenant différents binaires et une image Distroless. Les images de base Distroless sont des images de conteneur minimales qui privilégient la sécurité et l'optimisation des ressources en n'incluant que les composants essentiels. La surface d'attaque est réduite pour éviter les failles. Pour en savoir plus, consultez la documentation sur l'image de proxy Distroless.

Compatibilité binaire

Il est recommandé de limiter le contenu d'un environnement d'exécution de conteneur aux packages nécessaires. Cette approche améliore la sécurité et le rapport signal sur bruit des outils d'analyse des failles CVE (Common Vulnerabilities and Exposures). L'image Sidecar Distroless dispose d'un ensemble minimal de dépendances, dépourvu de tous les exécutables, bibliothèques et outils de débogage non essentiels. Par conséquent, il n'est pas possible d'exécuter une commande shell, ni d'utiliser curl, ping ou d'autres utilitaires de débogage comme kubectl exec dans le conteneur.

Rendre les clusters compatibles avec les images distroless

Supprimez de votre configuration les références à des binaires non compatibles (comme bash ou curl). En particulier dans les vérifications d'aptitude, de démarrage et d'activité, ainsi que dans les hooks PostStart et PreStop du cycle de vie dans les conteneurs istio-proxy, istio-init ou istio-validation.
Envisagez d'utiliser des alternatives telles que holdApplicationUntilProxyStarts pour certains cas d'utilisation.
Pour le débogage, vous pouvez utiliser des conteneurs éphémères pour les associer à un pod de charge de travail en cours d'exécution. Vous pouvez ensuite l'inspecter et exécuter des commandes personnalisées. Pour obtenir un exemple, consultez Collecter les journaux Cloud Service Mesh.

Si vous ne trouvez pas de solution pour votre cas d'utilisation spécifique, contactez l'assistance Google Cloud en consultant Obtenir de l'aide.

Migrer vers la passerelle d'entrée Istio

Cette section explique comment migrer vers la passerelle d'entrée Istio. Il existe deux méthodes pour migrer vers la passerelle d'entrée Istio :

Migration progressive avec répartition du trafic

Cette méthode vise à minimiser les perturbations. Elle consiste à envoyer progressivement du trafic vers la nouvelle passerelle Istio, ce qui vous permet de surveiller ses performances sur un petit pourcentage de requêtes et de revenir rapidement en arrière si nécessaire. N'oubliez pas que la configuration du fractionnement du trafic de couche 7 peut être difficile pour certaines applications. Vous devez donc gérer les deux systèmes de passerelle simultanément pendant la transition. Pour connaître la procédure, consultez Migration par phases avec répartition du trafic.
Migration directe

Cette méthode consiste à rediriger simultanément tout le trafic vers la nouvelle passerelle Istio une fois que vous avez effectué des tests approfondis. L'avantage de cette approche est la séparation complète de l'infrastructure de l'ancienne passerelle, ce qui permet une configuration adaptable de la nouvelle passerelle sans les contraintes de la configuration existante. Toutefois, le risque d'indisponibilité est plus élevé en cas de problème inattendu avec la nouvelle passerelle pendant la transition. Pour connaître la procédure, consultez Migration directe.

Les exemples de migration suivants supposent que vous disposez d'un service HTTP (httpbin) s'exécutant dans l'espace de noms de l'application (par défaut) et exposé en externe à l'aide de l'API Kubernetes Gateway. Voici les configurations concernées :

Passerelle : k8-api-gateway (dans l'espace de noms istio-ingress) : configurée pour écouter le trafic HTTP sur le port 80 pour tout nom d'hôte se terminant par .example.com.
HTTPRoute : httpbin-route (dans l'espace de noms default) : dirige toute requête HTTP avec le nom d'hôte httpbin.example.com et un chemin d'accès commençant par /get vers le service httpbin dans l'espace de noms default.
L'application httpbin est accessible à l'aide de l'adresse IP externe 34.57.246.68.

Schéma de passerelle de base

Migration par étapes avec répartition du trafic

Provisionner une passerelle d'entrée Istio

Déployez une passerelle d'entrée en suivant les étapes de la section Déployer un exemple de passerelle et personnalisez les exemples de configurations selon vos besoins. Les exemples du dépôt anthos-service-mesh sont destinés au déploiement d'un service istio-ingressgateway loadBalancer et des pods ingress-gateway correspondants.

Exemple de ressource de passerelle (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

Appliquez la configuration Gateway pour gérer le trafic :
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
Assurez-vous que le champ "spec.selector" de votre ressource Gateway correspond aux libellés de vos pods ingress-gateway. Par exemple, si les pods ingress-gateway ont le libellé istio=ingressgateway, votre configuration de passerelle doit également sélectionner ce libellé istio=ingressgateway.

Configurer le routage initial pour la nouvelle passerelle

Définissez les règles de routage initiales pour votre application à l'aide d'un VirtualService Istio.

Exemple de VirtualService (my-app-vs-new.yaml) :

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

Appliquez le VirtualService :

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Accédez au service de backend (httpbin) via la passerelle d'entrée Istio nouvellement déployée.

Définissez la variable d'environnement Ingress Host sur l'adresse IP externe associée à l'équilibreur de charge istio-ingressgateway récemment déployé :
```
export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
```
Vérifiez que l'application (httpbin) est accessible à l'aide de la nouvelle passerelle :
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
Le résultat est semblable à :
```
HTTP/1.1 200 OK
```

Flux de requête avec la nouvelle passerelle d'entrée Istio

Modifier Ingress existante pour la répartition du trafic

Après avoir confirmé la configuration de la nouvelle passerelle (par exemple, istio-api-gateway), vous pouvez commencer à y acheminer une partie de votre trafic. Pour ce faire, mettez à jour votre HTTPRoute actuelle afin de rediriger un petit pourcentage de trafic vers la nouvelle passerelle, tandis que la plus grande partie continue d'utiliser la passerelle existante (k8-api-gateway).

Ouvrez l'objet HttpRoute pour le modifier :

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Ajoutez une référence de backend pointant vers le service d'équilibreur de charge de la nouvelle passerelle d'entrée avec un poids initial de 10 %, puis mettez à jour le poids du backend de l'ancienne passerelle.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

Accordez l'autorisation de référencer des espaces de noms croisés avec l'autorisation de référence.

Pour permettre à votre HTTPRoute dans l'espace de noms de l'application (par défaut) d'accéder au service loadbalancer dans l'espace de noms de la passerelle (istio-ingress), vous devrez peut-être créer une autorisation de référence. Cette ressource sert de contrôle de sécurité, en définissant explicitement les références entre espaces de noms autorisées.

Le fichier istio-ingress-grant.yaml suivant décrit un exemple de référence d'accord :

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

Appliquez l'autorisation de référence :

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

Vérifiez les demandes adressées à une adresse IP externe existante (par exemple, 34.57.246.68) ne sont pas en échec. L'check-traffic-flow.sh suivant décrit un script permettant de vérifier les échecs de requête :

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

Exécutez le script pour vérifier qu'aucune requête n'échoue, quelle que soit la route du trafic :
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

Flux de requêtes avec trafic réparti entre la passerelle existante et la nouvelle passerelle d'entrée Istio

Augmentez progressivement le pourcentage de trafic

Si aucune défaillance de requête n'est constatée pour l'adresse IP externe existante (par exemple, 34.57.246.68), transférez progressivement davantage de trafic vers la nouvelle passerelle Istio Ingress en ajustant les pondérations de backend dans votre HTTPRoute. Augmentez la pondération de istio-ingressgateway et diminuez celle de l'ancienne passerelle par petits incréments (10 %, 20 %, etc.).

Utilisez la commande suivante pour mettre à jour votre HTTPRoute existant :

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migration complète du trafic et suppression de l'ancienne passerelle

Lorsque la nouvelle passerelle d'entrée Istio affiche des performances stables et gère correctement les requêtes, transférez-y tout le trafic. Mettez à jour votre HTTPRoute pour définir le poids du backend de l'ancienne passerelle sur 0 et celui de la nouvelle passerelle sur 100.
Une fois le trafic entièrement acheminé vers la nouvelle passerelle, mettez à jour vos enregistrements DNS externes pour le nom d'hôte de votre application (par exemple, httpbin.example.com) afin qu'ils pointent vers l'adresse IP externe du service d'équilibreur de charge créé dans Provision a new Istio Ingress Gateway (Provisionner une nouvelle passerelle d'entrée Istio).

Enfin, supprimez l'ancienne passerelle et les ressources associées :

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Migration directe