Mettre à niveau Cloud Service Mesh

Cette page explique comment effectuer les actions suivantes :

• Exécuter asmcli pour passer de Cloud Service Mesh à Cloud Service Mesh 1.19.10

• Vous pouvez éventuellement déployer une passerelle d'entrée.

• Effectuez une mise à niveau Canary pour migrer vos charges de travail vers le nouveau plan de contrôle.

La version de Cloud Service Mesh que vous pouvez mettre à niveau diffère selon la plate-forme.

GKE

Vous pouvez passer directement à Cloud Service Mesh 1.19.10-asm.9 sur Google Kubernetes Engine à partir des versions suivantes :

1.17+

Sur site

Vous pouvez passer directement à Cloud Service Mesh 1.19.10-asm.9 sur Google Distributed Cloud et Google Distributed Cloud à partir des versions suivantes :

1.17+

GKE sur AWS

Vous pouvez passer directement à Cloud Service Mesh 1.19.10-asm.9 sur GKE sur AWS à partir versions:

1.17+

GKE sur Azure

GKE sur Azure n'est compatible qu'avec Cloud Service Mesh 1.16. Surclassement à partir de les versions antérieures de Cloud Service Mesh ne sont pas compatibles.

Amazon EKS

Si Cloud Service Mesh 1.7 est installé sur EKS, vous devez installer Cloud Service Mesh 1.19 sur un nouveau cluster. Les mises à niveau de Cloud Service Mesh 1.7 vers Cloud Service Mesh 1.19 ne sont pas compatibles.

Microsoft AKS

Si Cloud Service Mesh 1.7 est installé sur AKS, vous devez installer Cloud Service Mesh 1.19 sur un nouveau cluster. Les mises à niveau de Cloud Service Mesh 1.7 vers Cloud Service Mesh 1.19 ne sont pas compatibles.

Avant de commencer

Avertissement :Les outils GitOps (y compris Config Sync, Argo CD, Terraform, et Jenkins) peuvent interférer avec l'installation, la migration ou processus de mise à niveau. Pour de meilleurs résultats, désactivez vos outils GitOps avant d'installer, de migrer ou de mettre à niveau Cloud Service Mesh.

Avant de commencer, veillez à suivre les étapes ci-dessous :

• Consultez les conditions préalables.
• Consultez les informations de la section Planifier la mise à niveau.
• Installez les outils nécessaires.
• Téléchargez asmcli.
• Accordez des autorisations d'administrateur de cluster.
• Validez le projet et le cluster.

Personnalisations du plan de contrôle

Si vous avez personnalisé l'installation précédente, vous avez besoin des mêmes personnalisations lorsque vous effectuez une mise à niveau vers une nouvelle version de Cloud Service Mesh ou une migration depuis Istio. Si vous avez personnalisé l'installation en ajoutant l'option --set values à istioctl install, vous devez ajouter ces paramètres à un fichier YAML IstioOperator, appelé fichier de superposition. Vous spécifiez le fichier superposé en utilisant l'option --custom_overlay avec le nom de fichier lorsque vous exécutez le script. Le script transmet le fichier de superposition à istioctl install.

Attention : L'installation aboutit même si vous oubliez le fichier superposé. Toutefois, la configuration de votre maillage de services est différente de celle prévue, car les valeurs omises sont réinitialisées aux valeurs par défaut lors du redéploiement du plan de contrôle et de la passerelle d'entrée.

Autorité de certification

La modification de l'autorité de certification lors d'une mise à niveau entraîne des temps d'arrêt. Pendant la mise à niveau, le trafic mTLS est interrompu jusqu'à ce que toutes les charges de travail passent au nouveau plan de contrôle avec la nouvelle autorité de certification.

Mettez à niveau Anthos Service Mesh.

Vous trouverez ci-dessous la procédure à suivre pour mettre à niveau Cloud Service Mesh :

1. Si vous mettez à niveau un réseau maillé multicluster sur GKE qui utilise l'autorité de certification Cloud Service Mesh, exécutez asmcli create-mesh pour configurer d'un réseau maillé multicluster parc d'identité de charge de travail pour éviter les temps d'arrêt de l'équilibrage de charge entre clusters lors de la mise à niveau.

2. Exécutez asmcli install pour installer Cloud Service Mesh sur un seul cluster. Consultez les sections suivantes pour obtenir des exemples de ligne de commande. Les exemples contiennent à la fois des arguments obligatoires et des arguments facultatifs qui peuvent vous être utiles. Nous vous recommandons de toujours spécifier l'argument output_dir afin de pouvoir facilement trouver des exemples de passerelles et d'outils tels que istioctl. Consultez la barre de navigation située à droite pour obtenir la liste des exemples.

3. Vous pouvez également installer ou mettre à niveau une passerelle d'entrée. Par défaut, asmcli n'installe pas la istio-ingressgateway. Nous vous recommandons de déployer et de gérer le plan de contrôle et les passerelles séparément. Si vous avez besoin d'installer l'option istio-ingressgateway par défaut avec le plan de contrôle au sein du cluster, incluez l'argument --option legacy-default-ingressgateway.

4. Pour terminer la configuration de Cloud Service Mesh, vous devez activer le side-car automatique l'injection et déployer ou redéployer des charges de travail.

Configurer le réseau maillé multicluster pour approuver l'identité de la charge de travail du parc.

Si vous mettez à niveau un réseau maillé multicluster sur GKE utilise l'autorité de certification Cloud Service Mesh comme autorité de certification, vous devez exécuter asmcli create-mesh avant de mettre à niveau chaque cluster. Cette commande configure l'autorité de certification Cloud Service Mesh pour utiliser le pool d'identité de charge de travail du parc, FLEET_PROJECT_ID.svc.id.goog, comme domaine de confiance après la mise à niveau. La commande asmcli create-mesh :

• enregistre tous les clusters dans le même parc ;
• configure le réseau maillé pour approuver l'identité de charge de travail du parc ;
• crée des secrets distants.

Vous pouvez spécifier l'URI de chaque cluster ou le chemin d'accès au fichier kubeconfig.

URI des clusters

Dans la commande suivante, remplacez FLEET_PROJECT_ID par l'ID du projet hôte du parc et l'URI du cluster par le nom, la zone, la région et l'ID du projet pour chaque cluster.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

Fichier kubeconfig

Dans la commande suivante, remplacez FLEET_PROJECT_ID par l'ID du projet hôte du parc et PATH_TO_KUBECONFIG par le chemin d'accès à chaque fichier kubeconfig.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

Mettre à niveau avec les fonctionnalités par défaut et Mesh CA

Cette section explique comment exécuter asmcli pour mettre à niveau Cloud Service Mesh avec les fonctionnalités compatibles par défaut de votre plate-forme et activer l'autorité de certification Cloud Service Mesh comme autorité de certification.

GKE

Exécutez la commande suivante pour mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Cloud Service Mesh. Saisissez vos valeurs dans les espaces réservés fournis.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
• --fleet_id : ID du projet du projet hôte du parc. Si vous n'incluez pas cette option, asmcli utilise le projet dans lequel le cluster a été créé lors de son enregistrement.
• --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  Remarque : Notez ce répertoire --output_dir. Vous devrez le référencer lors du déploiement de passerelles.
• --enable_all : permet au script d'effectuer les opérations suivantes :
  • Accorder les autorisations IAM requises.
  • Activer les API Google requises.
  • Définir un libellé sur le cluster qui identifie le réseau maillé.
  • Enregistrer le cluster dans le parc si ce n'est déjà fait.
• --ca mesh_ca : utiliser l'autorité de certification Cloud Service Mesh comme autorité de certification. Modifier les autorités de certification au cours d'une peut entraîner des temps d'arrêt. asmcliconfigure l'autorité de certification Cloud Service Mesh à utiliser parc Workload Identity

Autres clusters GKE Enterprise

Exécutez les commandes suivantes sur d'autres clusters GKE Enterprise pour mettre à niveau plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification Cloud Service Mesh. Saisissez vos valeurs dans les espaces réservés fournis.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca mesh_ca : utiliser l'autorité de certification Cloud Service Mesh comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne un temps d'arrêt. asmcli configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail de parc.

Mettre à jour les fonctionnalités par défaut avec CA Service

Cette section explique comment exécuter asmcli pour mettre à niveau Cloud Service Mesh avec le fonctionnalités compatibles par défaut pour votre plate-forme et activez Certificate Authority Service.

GKE

Exécutez la commande suivante pour mettre à jour le plan de contrôle avec les fonctionnalités par défaut et Certificate Authority Service. Saisissez vos valeurs dans les espaces réservés fournis.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

• --project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
• --fleet_id : ID du projet du projet hôte du parc. Si vous n'incluez pas cette option, asmcli utilise le projet dans lequel le cluster a été créé lors de son enregistrement.
• --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  Remarque: Notez ce répertoire --output_dir. Vous devrez le référencer lors du déploiement de passerelles.
• --enable_all : permet au script d'effectuer les opérations suivantes :
  • Accorder les autorisations IAM requises.
  • Activer les API Google requises.
  • Définir un libellé sur le cluster qui identifie le réseau maillé.
  • Enregistrer le cluster dans le parc si ce n'est déjà fait.
• --ca gcp_cas : utilisez Certificate Authority Service comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne des temps d'arrêt. asmcli configure Certificate Authority Service pour utiliser l'identité de charge de travail de parc.
• --ca_pool : identifiant complet du pool d'autorités de certification Certificate Authority Service.

Sur site

Exécutez les commandes suivantes sur Google Distributed Cloud ou Google Distributed Cloud pour mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et Certificate Authority Service. Saisissez vos valeurs dans les espaces réservés fournis.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   ./asmcli install \
    --kubeconfig KUBECONFIG_FILE \
    --fleet_id FLEET_PROJECT_ID \
    --output_dir DIR_PATH \
    --enable_all \
    --ca gcp_cas \
    --platform multicloud \
    --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca gcp_cas : utilisez Certificate Authority Service comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne des temps d'arrêt. asmcli configure Certificate Authority Service pour utiliser l'identité de charge de travail de parc.
   • --ca_pool : identifiant complet du pool d'autorités de certification Certificate Authority Service.

Mettre à niveau les fonctionnalités par défaut avec l'autorité de certification d'Istio

Cette section explique comment exécuter asmcli pour mettre à niveau Cloud Service Mesh avec les fonctionnalités compatibles par défaut de votre plate-forme et activer Istio CA.

GKE

Exécutez la commande suivante pour mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

• --project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
• --fleet_id : ID du projet du projet hôte du parc. Si vous n'incluez pas cette option, asmcli utilise le projet dans lequel le cluster a été créé lors de son enregistrement.
• --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  Remarque: Notez ce répertoire --output_dir. Vous devrez le référencer lors du déploiement de passerelles.
• --enable_all : permet au script d'effectuer les opérations suivantes :
  • Accorder les autorisations IAM requises.
  • Activer les API Google requises.
  • Définir un libellé sur le cluster qui identifie le réseau maillé.
  • Enregistrer le cluster dans le parc si ce n'est déjà fait.
• --ca citadel : Utilise l'autorité de certification Istio. La modification des autorités de certification lors d'une mise à niveau entraîne un temps d'arrêt.

Sur site

Exécutez les commandes suivantes sur Google Distributed Cloud ou Google Distributed Cloud pour mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification d'Istio. Saisissez vos valeurs dans les espaces réservés fournis.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
   • --ca_cert : le certificat intermédiaire
   • --ca_key : la clé du certificat intermédiaire
   • --root_cert : le certificat racine
   • --cert_chain : la chaîne de certificats

AWS

Exécutez les commandes suivantes sur GKE sur AWS pour mettre à niveau le contrôle avec les fonctionnalités par défaut et l'autorité de certification d'Istio. Saisissez vos valeurs dans les espaces réservés fournis. Vous pouvez choisir d'activer l'entrée du sous-réseau public ou du sous-réseau privé.

Public

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
   • --ca_cert : le certificat intermédiaire
   • --ca_key : la clé du certificat intermédiaire
   • --root_cert : le certificat racine
   • --cert_chain : la chaîne de certificats

Privé

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Enregistrez le fichier YAML suivant dans un fichier appelé istio-operator-internal-lb.yaml :

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. Exécutez asmcli install :

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
   • --ca_cert : le certificat intermédiaire
   • --ca_key : la clé du certificat intermédiaire
   • --root_cert : le certificat racine
   • --cert_chain : la chaîne de certificats

Amazon EKS

Exécutez les commandes suivantes sur Amazon EKS pour mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.

Remarque sur la plate-forme: Si Cloud Service Mesh 1.7 est installé sur EKS, vous devez installer Cloud Service Mesh 1.19 sur un nouveau cluster. Surclassement à partir de Cloud Service Mesh 1.7 vers Cloud Service Mesh 1.19 ne sont pas compatibles.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
   • --ca_cert : le certificat intermédiaire
   • --ca_key : la clé du certificat intermédiaire
   • --root_cert : le certificat racine
   • --cert_chain : la chaîne de certificats

Microsoft AKS

Exécutez les commandes suivantes sur Amazon EKS pour mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et Istio CA. Saisissez vos valeurs dans les espaces réservés fournis.

Remarque :Si Cloud Service Mesh 1.7 est installé sur AKS, vous devrez installer Cloud Service Mesh 1.19 sur un nouveau cluster. Surclassement à partir de Cloud Service Mesh 1.7 vers Cloud Service Mesh 1.19 ne sont pas compatibles.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca citadel : utiliser l'autorité de certification Istio comme autorité de certification.
   • --ca_cert : le certificat intermédiaire
   • --ca_key : la clé du certificat intermédiaire
   • --root_cert : le certificat racine
   • --cert_chain : la chaîne de certificats

Passer à une édition supérieure avec des fonctionnalités facultatives

Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator que vous transmettez à asmcli pour configurer le plan de contrôle. Vous pouvez ignorer la configuration par défaut du plan de contrôle et activer une fonctionnalité facultative en transmettant le fichier YAML à asmcli. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier superposé remplace la configuration dans les couches précédentes.

GKE

Exécutez la commande suivante pour installer le plan de contrôle avec une fonctionnalité facultative. Pour ajouter plusieurs fichiers, spécifiez --custom_overlay et le nom du fichier, par exemple : --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml. Saisissez vos valeurs dans les espaces réservés fournis.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
• --fleet_id : ID du projet du projet hôte du parc. Si vous n'incluez pas cette option, asmcli utilise le projet dans lequel le cluster a été créé lors de son enregistrement.
• --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
  Remarque: Notez ce répertoire --output_dir. Vous devrez le référencer lors du déploiement de passerelles.
• --enable_all : permet au script d'effectuer les opérations suivantes :
  • Accorder les autorisations IAM requises.
  • Activer les API Google requises.
  • Définir un libellé sur le cluster qui identifie le réseau maillé.
  • Enregistrer le cluster dans le parc si ce n'est déjà fait.
• --ca mesh_ca : utiliser l'autorité de certification Cloud Service Mesh comme autorité de certification. Modifier les autorités de certification au cours d'une peut entraîner des temps d'arrêt. asmcliconfigure l'autorité de certification Cloud Service Mesh à utiliser parc Workload Identity
• --custom_overlay : spécifier le nom du fichier de superposition.

En dehors de Google Cloud

Exécutez les commandes suivantes sur Google Distributed Cloud : Google Distributed Cloud, GKE sur AWS, Amazon EKS ou Microsoft AKS. Saisissez vos valeurs dans les espaces réservés fournis.

Remarque sur la plate-forme: Si Cloud Service Mesh 1.7 est installé sur EKS, vous devez installer Cloud Service Mesh 1.19 sur un nouveau cluster. Les mises à niveau de Cloud Service Mesh 1.7 vers Cloud Service Mesh 1.19 ne sont pas compatibles.

1. Définissez le contexte actuel sur votre cluster d'utilisateur :

   kubectl config use-context CLUSTER_NAME
   

2. Exécutez asmcli install :

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id : ID du projet du projet hôte du parc.
   • --kubeconfig : chemin d'accès complet au fichier kubeconfig. La variable d'environnement $PWD ne fonctionne pas ici. De plus, les emplacements de fichiers kubeconfig relatifs qui utilisent une valeur `~` ne fonctionneront pas.
   • --output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
   • --platform multicloud spécifie que la plate-forme est une plate-forme autre que Google Cloud, par exemple une plate-forme sur site ou multicloud.
   • --enable_all : permet au script d'effectuer les opérations suivantes :
     • Accorder les autorisations IAM requises.
     • Activer les API Google requises.
     • Définir un libellé sur le cluster qui identifie le réseau maillé.
     • Enregistrer le cluster dans le parc si ce n'est déjà fait.
   • --ca mesh_ca : utiliser l'autorité de certification Cloud Service Mesh comme autorité de certification. La modification des autorités de certification lors d'une mise à niveau entraîne des temps d'arrêt. asmcli configure l'autorité de certification Cloud Service Mesh pour utiliser l'identité de charge de travail de parc.
   • --custom_overlay : spécifier le nom du fichier de superposition.

Mettre à niveau les passerelles

Si des passerelles sont déjà déployées, vous devrez également les mettre à niveau. Pour une mise à niveau simple, suivez la section "Mises à niveau sur place" du guide Installer et mettre à niveau les passerelles.

Avertissement :Si vous avez installé Cloud Service Mesh avec une autre méthode que asmcli, la passerelle d'entrée par défaut installée sera supprimée, sauf si vous transmettez le paramètre l'argument --option legacy-default-ingressgateway.

Passer au nouveau plan de contrôle

1. Obtenez le libellé de révision qui se trouve sur istiod.

   kubectl get pod -n istio-system -L istio.io/rev
   

   La sortie de la commande ressemble à ceci :

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-11910-9-67998f4b55-lrzpz           1/1     Running   0          68m   asm-11910-9
   istiod-asm-11910-9-67998f4b55-r76kr           1/1     Running   0          68m   asm-11910-9
   istiod-1187-26-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-11910-9
   istiod-1187-26-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-11910-9

   1. Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision pour la nouvelle version. Dans cet exemple, la valeur est asm-11910-9.

   2. Notez également la valeur du libellé de révision pour l'ancienne version de istiod. Vous devrez supprimer l'ancienne version de istiod lorsque vous aurez fini de déplacer les charges de travail vers la nouvelle version. Dans l'exemple de résultat, la valeur de l'étiquette de révision pour l'ancienne version est asm-11910-9.

2. Ajoutez le libellé de révision à un espace de noms d'application et supprimez le libellé istio-injection (s'il existe). Dans la commande suivante, remplacez REVISION par la valeur correspondant à la nouvelle révision de istiod.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant l'étiquette istio-injection. Comme le comportement de l'injection automatique n'est pas défini lorsqu'un espace de noms possède à la fois istio-injection et l'élément l'étiquette de révision, toutes les commandes kubectl label de Cloud Service Mesh s'assurent explicitement qu'un seul est défini.

3. Redémarrez les pods pour déclencher la réinjection :

   Avertissement : Veillez à redémarrer tous les pods pour déclencher la réinjection des sidecars. Sinon, les rapports de métriques Cloud Service Mesh risquent de devenir incohérents entre les anciens et les nouveaux proxys du cluster.

   kubectl rollout restart deployment -n NAMESPACE

4. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

5. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

6. Si vous êtes sûr que votre application fonctionne comme prévu, continuez de suivre les étapes pour valider la transition vers la nouvelle version de istiod. Si vous rencontrez un problème avec votre application, suivez la procédure de rollback.

   Terminer la transition

   Si vous êtes sûr que votre application fonctionne comme prévu, supprimez l'ancien plan de contrôle pour terminer la transition vers la nouvelle version.

   1. Accédez au répertoire dans lequel se trouvent les fichiers du dépôt GitHub anthos-service-mesh.

   2. Configurez le webhook de validation pour utiliser le nouveau plan de contrôle :

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. Déplacez le tag par défaut :

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

   4. Supprimez l'ancienne version de istiod. La commande que vous utilisez varie selon que vous effectuez la migration depuis Istio ou une mise à niveau depuis une version précédente de Cloud Service Mesh.

      Migrer

      Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas de libellé de révision :

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
      

      Mettre à niveau

      1. Si vous avez effectué une mise à niveau à partir d'une version précédente de Cloud Service Mesh, assurez-vous que OLD_REVISION correspond au libellé de révision de la version précédente de istiod dans la commande suivante :

         kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
         

      2. Supprimez la ressource validatingwebhookconfiguration pour l'ancienne révision :

         kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
         

   5. Supprimez l'ancienne version de la configuration IstioOperator :

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      Le résultat ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   Rollback

   Si vous avez rencontré un problème lors du test de votre application avec la nouvelle version de istiod, procédez comme suit pour effectuer un rollback vers la version précédente :

   1. Modifiez les libellés de votre espace de noms pour activer l'injection automatique avec la version précédente de istiod. La commande que vous utilisez varie selon que vous avez utilisé une étiquette de révision ou istio-injection=enabled avec la version précédente.

      • Si vous avez utilisé un libellé de révision pour l'injection automatique :

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
        

      • Si vous avez utilisé istio-injection=enabled :

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
        

      Résultat attendu :

      namespace/NAMESPACE labeled

   2. Confirmez que le libellé de révision de l'espace de noms correspond au libellé de révision de la version précédente de istiod :

      kubectl get ns NAMESPACE --show-labels
      

   3. Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente :

      kubectl rollout restart deployment -n NAMESPACE
      

   4. Supprimez la nouvelle version de istiod. Assurez-vous que la valeur de REVISION dans la commande suivante est correcte.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      

   5. Supprimez la nouvelle version de la configuration IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      Le résultat attendu ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   6. Si vous n'avez pas ajouté l'option --disable_canonical_service, asmcli a activé le contrôleur de service canonique. Nous vous recommandons de conserver cette option activée. Cependant, si vous devez la désactiver, consultez la section Activer et désactiver le contrôleur de service canonique.

   7. Si vous avez déployé des passerelles, veillez à modifier le libellé de révision sur l'espace de noms ou le déploiement pour qu'il corresponde à la version précédente de istiod. Suivez la même procédure que celle décrite dans la section "Mise à niveau sur place" du guide Installer et mettre à niveau des passerelles.

Déployer et redéployer des charges de travail

Votre installation (ou mise à niveau) n'est pas terminée tant que vous n'avez pas activé l'injection automatique du proxy side-car. Les migrations depuis OSS Istio et les mises à niveau suivent le processus de mise à niveau basé sur la révision (processus appelé "mises à jour Canary" dans la documentation d'Istio). Avec une mise à niveau basée sur la révision, la nouvelle version du plan de contrôle est installée en parallèle du plan de contrôle existant. Vous déplacez ensuite certaines de vos charges de travail vers la nouvelle version, ce qui vous permet de surveiller l'effet de la mise à niveau avec un faible pourcentage des charges de travail avant de migrer tout le trafic vers la nouvelle version.

Le script définit un libellé de révision au format istio.io/rev=asm-11910-9 sur istiod. Pour activer l'injection automatique, vous devez ajouter une étiquette de révision correspondant à votre ou vos espaces de noms. L'étiquette de révision est utilisé par le webhook d'injecteur sidecar automatique pour associer les sidecars injectés à une révision istiod particulière. Après avoir ajouté l'étiquette, redémarrez les pods de l'espace de noms pour que les sidecars soient injectés.

1. Obtenez l'étiquette de révision associée à istiod et istio-ingressgateway.

   kubectl get pod -n istio-system -L istio.io/rev
   

   La sortie de la commande ressemble à ceci :

   NAME                                                READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk               1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz               1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb      1/1     Running   0          5s    asm-11910-9
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-11910-9
   istiod-asm-11910-9-67998f4b55-lrzpz          1/1     Running   0          68m   asm-11910-9
   istiod-asm-11910-9-67998f4b55-r76kr          1/1     Running   0          68m   asm-11910-9
   istiod-asm-1187-26-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-11910-9
   istiod-asm-1187-26-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-11910-9

   1. Dans le résultat, sous la colonne REV, notez la valeur du libellé de révision pour la nouvelle version. Dans cet exemple, la valeur est asm-11910-9.

   2. Notez également la valeur du libellé de révision pour l'ancienne version de istiod. Vous devrez supprimer l'ancienne version de istiod lorsque vous aurez fini de déplacer les charges de travail vers la nouvelle version. Dans l'exemple de résultat, la valeur du libellé de révision pour l'ancienne version est asm-11910-9.

2. Basculez istio-ingressgateway vers la nouvelle révision. Dans la commande suivante, remplacez REVISION par la valeur correspondant au libellé de révision de la nouvelle version.

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

   Résultat attendu : service/istio-ingressgateway patched

3. Ajoutez le libellé de révision à un espace de noms et supprimez le libellé istio-injection (s'il existe). Dans la commande suivante, remplacez REVISION par la valeur correspondant à la nouvelle révision de istiod.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant l'étiquette istio-injection. Comme le comportement de l'injection automatique n'est pas défini lorsqu'un espace de noms possède à la fois istio-injection et l'élément l'étiquette de révision, toutes les commandes kubectl label de Cloud Service Mesh s'assurent explicitement qu'un seul est défini.

4. Redémarrez les pods pour déclencher la réinjection :

   Avertissement :Veillez à redémarrer tous les pods afin de déclencher la réinjection. des side-cars. Sinon, les rapports de métriques Cloud Service Mesh risquent de devenir incohérents entre les anciens et les nouveaux proxys du cluster.

   kubectl rollout restart deployment -n NAMESPACE

5. Testez votre application pour vérifier que les charges de travail fonctionnent correctement.

6. Si vous avez des charges de travail dans d'autres espaces de noms, répétez les étapes pour leur ajouter des libellés et redémarrer les pods.

7. Si vous êtes sûr que votre application fonctionne comme prévu, continuez de suivre les étapes pour valider la transition vers la nouvelle version de istiod. Si vous rencontrez un problème avec votre application, suivez la procédure de rollback.

   Terminer la transition

   Si vous êtes sûr que votre application fonctionne comme prévu, supprimez l'ancien plan de contrôle pour terminer la transition vers la nouvelle version.

   1. Accédez au répertoire dans lequel se trouvent les fichiers du dépôt GitHub anthos-service-mesh.

   2. Configurez le webhook de validation pour utiliser le nouveau plan de contrôle.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. Déplacez le tag par défaut.

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite
      

   4. Supprimez l'ancien déploiement istio-ingressgateway. La commande que vous varie selon que vous effectuez une migration depuis Istio à partir d'une version précédente de Cloud Service Mesh:

      Migrer

      Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas d'étiquette de révision.

      kubectl delete deploy/istio-ingressgateway -n istio-system
      

      Mettre à niveau

      Si vous avez effectué une mise à niveau à partir d'une version précédente de Cloud Service Mesh, commande suivante, remplacez OLD_REVISION par le libellé de révision de la version précédente istio-ingressgateway

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. Supprimez l'ancienne version de istiod. La commande que vous utilisez varie selon que vous effectuez la migration depuis Istio ou une mise à niveau depuis une version précédente de Cloud Service Mesh.

      Migrer

      Si vous avez effectué une migration depuis Istio, l'ancienne istio-ingressgateway ne comporte pas d'étiquette de révision.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
      

      Mettre à niveau

      Si vous avez effectué une mise à niveau à partir d'une version précédente de Cloud Service Mesh, assurez-vous que OLD_REVISION correspond au libellé de révision de la version précédente de istiod dans la commande suivante.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   6. Supprimez l'ancienne version de la configuration IstioOperator.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      Le résultat ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   Rollback

   Si vous avez rencontré un problème lors du test de votre application avec la nouvelle version de istiod, procédez comme suit pour effectuer un rollback vers la version précédente :

   1. Modifiez les libellés de votre espace de noms pour activer l'injection automatique avec la version précédente de istiod. La commande que vous utilisez varie selon que vous avez utilisé une étiquette de révision ou istio-injection=enabled avec la version précédente.

      • Si vous avez utilisé un libellé de révision pour l'injection automatique :

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
        

      • Si vous avez utilisé istio-injection=enabled :

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
        

      Résultat attendu :

      namespace/NAMESPACE labeled

   2. Confirmez que le libellé de révision de l'espace de noms correspond au libellé de révision de la version précédente de istiod :

      kubectl get ns NAMESPACE --show-labels
      

   3. Redémarrez les pods pour déclencher une réinjection afin que les proxys disposent de la version précédente :

      kubectl rollout restart deployment -n NAMESPACE
      

   4. Supprimez le nouveau déploiement istio-ingressgateway. Assurez-vous que la valeur de REVISION dans la commande suivante est correcte.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
      

   5. Supprimez la nouvelle version de istiod. Assurez-vous que la valeur de REVISION dans la commande suivante est correcte.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      

   6. Supprimez la nouvelle version de la configuration IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      Le résultat attendu ressemble à ce qui suit :

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   7. Si vous n'avez pas ajouté l'option --disable_canonical_service, le script a activé le contrôleur de service canonique. Nous vous recommandons de conserver cette option activée. Cependant, si vous devez la désactiver, consultez la section Activer et désactiver le contrôleur de service canonique.