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 la liste des mises à jour de configuration possibles nécessaires pour préparer votre cluster à la modernisation. Pour obtenir des instructions de mise à jour, consultez chaque section:

Multicluster
Activer Workload Identity Federation for 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 aux API déclaratives

La détection de point de terminaison multicluster 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 réseau maillé. 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 pour contrôler le trafic multi-clusters 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, et vous ne pourrez pas utiliser directement ces nouvelles fonctionnalités avec les secrets Istio. L'API déclarative est la seule voie à suivre.

Si vous utilisez des secrets Istio, passez à l'API déclarative dès que possible. Notez que le paramètre multicluster_mode dirige chaque cluster vers le trafic de 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 la section Fonctionnalités compatibles à l'aide des API Istio.

Migrer des secrets Istio vers une 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. Cette procédure ne s'applique 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 réajoutés. Entre la suppression et l'ajout des points de terminaison, le trafic revient brièvement au routage local au lieu de l'équilibrage de charge vers d'autres clusters. Pour en savoir plus, consultez ce problème sur GitHub.

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

Activez l'API déclarative pour chaque cluster du parc pour 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 de points de terminaison multiclusters dans 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étection 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.

Une fois multicluster_mode=connected défini sur vos clusters, un nouveau secret est généré pour chaque cluster qui a également multicluster_mode=connected défini. Le secret est placé dans l'espace de noms istio-system et a 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 tous les secrets créés manuellement avec istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Une fois la migration effectuée, vérifiez les métriques de vos requêtes pour vous assurer qu'elles sont acheminé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 à des Google Cloud services 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 qu'un 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 la sortie est vide, suivez les instructions de la section Mettre à jour un cluster existant pour activer l'identité de charge de travail 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 la sortie 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 de la CNI gérée

La CNI (Container Network Interface) gérée est une implémentation gérée par Google de la CNI Istio. Le plug-in CNI simplifie la mise en réseau des pods en configurant des règles iptables. Cela permet de rediriger le trafic entre les applications et les proxys Envoy, ce qui élimine le besoin d'autorisations privilégiées pour le conteneur d'initialisation 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 sidecar 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 d'autorisations élevées, 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, un CNI géré est obligatoire pour tous les déploiements de Cloud Service Mesh géré.

Impact sur les conteneurs d'initialisation

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 des tâches telles que 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 réseau peuvent rencontrer des problèmes lorsque le CNI géré est activé dans le cluster.

Le processus de configuration du pod avec CNI géré est le suivant:

Le plug-in CNI configure les interfaces réseau des pods, attribue des adresses IP aux 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 avec 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 du réseau maillé, 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 CNI Istio.

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 d'initialisation. Envisagez les alternatives suivantes:
- Modifier la logique ou les conteneurs de l'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 le proxy side-car démarré.
- Utilisez des ConfigMaps ou des secrets Kubernetes:stockez les données de configuration extraites par la requête réseau dans des ConfigMaps ou des secrets Kubernetes, puis installez-les dans vos conteneurs d'application. Pour découvrir d'autres solutions, consultez la documentation d'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 l'étiquette 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 sous la colonne "NAME" 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 l'étiquette 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 est supprimée de servicemesh.conditions.
  - Notez que la mise à jour de l'état peut prendre jusqu'à 15 à 20 minutes. Essayez d'attendre quelques minutes, puis réexécutez la commande.
3. Une fois que l'état de la fonctionnalité du cluster est Active pour controlPlaneManagement.state, redémarrez les pods.

Abandon de l'utilisation de binaires non standards dans Sidecar

Cette section suggère des façons de rendre vos déploiements compatibles avec l'image de proxy envoy sans distribution.

Images de 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 divers binaires et une image Distroless. Les images de base distroless sont des images de conteneur minimales qui donnent la priorité à 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ébarrassée 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 tels que kubectl exec dans le conteneur.

Rendre les clusters compatibles avec les images sans distribution

Supprimez de votre configuration les références à tous les binaires non compatibles (comme bash ou curl). En particulier dans les sondes d'aptitude, de démarrage et d'activité, ainsi que dans les hooks de cycle de vie PostStart et PreStop dans les conteneurs istio-proxy, istio-init ou istio-validation.
Envisagez d'utiliser d'autres options telles que holdApplicationUntilProxyStarts pour certains cas d'utilisation.
Pour le débogage, vous pouvez utiliser des conteneurs éphémères pour vous connecter à 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 la section Collecter les journaux de Cloud Service Mesh.

Si vous ne trouvez pas de solution pour votre cas d'utilisation spécifique, contactez l' Google Cloudassistance sur la page 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 en plusieurs phases avec répartition du trafic

Cette méthode vise à minimiser les perturbations en envoyant progressivement du trafic vers la nouvelle passerelle Istio, ce qui vous permet de surveiller ses performances sur un faible pourcentage de requêtes et de revenir rapidement en arrière si nécessaire. N'oubliez pas que la configuration de la répartition 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 la section Migration par étapes 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 de configurer la nouvelle passerelle de manière adaptable sans les contraintes de la configuration existante. Toutefois, le risque d'indisponibilité est plus élevé en cas de problèmes inattendus avec la nouvelle passerelle pendant la transition. Pour connaître la procédure à suivre, consultez Migration directe.

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

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) redirige 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 via l'adresse IP externe 34.57.246.68.

Schéma de base de la passerelle

Migration par étapes avec répartition du trafic

Provisionner une nouvelle passerelle d'entrée Istio

Déployez une nouvelle passerelle d'entrée en suivant les étapes de la section Déploiement d'un exemple de passerelle et personnalisez les exemples de configurations en fonction de vos besoins. Les exemples du dépôt anthos-service-mesh sont destinés à déployer un service loadBalancer istio-ingressgateway et les 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 de la passerelle pour gérer le trafic:
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
Assurez-vous que "spec.selector" dans votre ressource de passerelle correspond aux libellés de vos pods ingress-gateway. Par exemple, si les pods ingress-gateway portent le libellé istio=ingressgateway, votre configuration de passerelle doit également sélectionner ce libellé istio=ingressgateway.

Configurer le routage initial de la nouvelle passerelle

Définissez les règles de routage initiales de 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éder au service 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êtes avec la nouvelle passerelle d'entrée Istio

Modifier un Ingress existant pour la répartition du trafic

Une fois que vous avez vérifié que la nouvelle passerelle a bien été configurée (par exemple, istio-api-gateway), vous pouvez commencer à y acheminer une partie de votre trafic. Pour ce faire, mettez à jour votre HTTPRoute actuel afin de rediriger un faible pourcentage de trafic vers la nouvelle passerelle, tandis que la plus grande partie continue d'utiliser la passerelle existante (k8-api-gateway).

Ouvrez 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'équilibrage de charge de la nouvelle passerelle d'entrée avec un poids initial de 10% et 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 une autorisation pour les références entre espaces de noms avec une autorisation de référence.

Pour autoriser votre HTTPRoute dans l'espace de noms de l'application (par défaut) à 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é, définissant explicitement les références entre les espaces de noms autorisées.

L'istio-ingress-grant.yaml suivant décrit un exemple d'octroi de référence:

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 la licence de référence:

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

Vérifier les requêtes envoyées à une adresse IP externe existante (par exemple, 34.57.246.68) ne sont pas en panne. Le 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 ne échoue, quel que soit le routage du trafic:
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

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

Augmenter progressivement le pourcentage de trafic

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

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

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 une gestion réussie des 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 que le trafic est 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 Provisionner une nouvelle passerelle d'entrée Istio.

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

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

Migration directe