Mettre à niveau Anthos Service Mesh

Cette page explique comment effectuer les actions suivantes :

• Exécutez asmcli pour passer d'Anthos Service Mesh à Anthos Service Mesh 1.11.8.

• 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 d'Anthos Service Mesh que vous pouvez mettre à niveau varie selon la plate-forme.

GKE

Vous pouvez passer directement à Anthos Service Mesh 1.11.8-asm.4 sur Google Kubernetes Engine à partir des versions suivantes :

1.9 et 1.10

Sur site

Vous pouvez effectuer une mise à niveau directement vers Anthos Service Mesh 1.11.8-asm.4 sur GKE sur VMware et Google Distributed Cloud Virtual pour Bare Metal à partir des versions suivantes:

1.10

GKE sur AWS

Vous pouvez effectuer une mise à niveau directe vers Anthos Service Mesh 1.11.8-asm.4 sur GKE sur AWS à partir des versions suivantes:

1.10

Amazon EKS

Si vous avez installé Anthos Service Mesh 1.7 sur EKS, vous devez installer Anthos Service Mesh 1.11 sur un nouveau cluster. Les mises à niveau d'Anthos Service Mesh 1.7 vers Anthos Service Mesh 1.11 ne sont pas compatibles.

Remarque : L'ajout de machines virtuelles Compute Engine au maillage de services nécessite des options spécifiques lorsque vous mettez à niveau Anthos Service Mesh. Pour connaître la procédure détaillée, consultez la section Ajouter des machines virtuelles Compute Engine à Anthos Service Mesh.

Avant de commencer

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écharger 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 d'Anthos 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.

Mettre à niveau Anthos Service Mesh

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

1. Si vous mettez à niveau un réseau maillé multicluster sur GKE qui utilise l'autorité de certification Anthos Service Mesh (Mesh CA), exécutez asmcli create-mesh pour que le réseau maillé multicluster approuve l'identité de la charge de travail du parc afin de ne pas interrompre l'équilibrage de charge entre les clusters pendant la mise à niveau.

2. Exécutez asmcli install pour installer Anthos 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 d'Anthos Service Mesh, vous devez activer l'injection side-car automatique 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 à jour un réseau maillé multicluster sur GKE qui utilise Mesh CA comme autorité de certification, vous devez exécuter asmcli create-mesh avant de mettre à jour chaque cluster. Cette commande configure Mesh CA 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 Anthos Service Mesh avec les fonctionnalités compatibles par défaut de votre plate-forme et activer l'autorité de certification Anthos Service Mesh (Mesh CA) comme autorité de certification.

Remarque concernant la plate-forme:Mesh CA n'est pas compatible avec GKE sur AWS ni Amazon EKS. Si vous exécutez asmcli install et spécifiez --ca mesh_ca sur ces plates-formes, l'installation échoue.

GKE

Exécutez la commande suivante pour mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et Mesh 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 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 Mesh CA 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 MeshMesh pour utiliser l'identité de charge de travail de parc.

Sur site

Exécutez les commandes suivantes sur GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal afin de mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et Mesh CA. 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 Mesh CA 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 Mesh CA pour utiliser l'identité de charge de travail du parc.

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 Anthos 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 GKE sur VMware ou Google Distributed Cloud Virtual pour Bare Metal afin de mettre à niveau le plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification 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 plan de contrôle avec les fonctionnalités par défaut et l'autorité de certification 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é.

Publique

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

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 vous avez installé Anthos Service Mesh 1.7 sur EKS, vous devez installer Anthos Service Mesh 1.11 sur un nouveau cluster. Les mises à niveau d'Anthos Service Mesh 1.7 vers Anthos Service Mesh 1.11 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

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 de superposition 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 Mesh CA 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 MeshMesh pour utiliser l'identité de charge de travail de parc.
• --custom_overlay : spécifier le nom du fichier de superposition.

En dehors de Google Cloud

Exécutez les commandes suivantes sur GKE sur VMware, Google Distributed Cloud Virtual pour Bare Metal, GKE sur AWS ou Amazon EKS. Saisissez vos valeurs dans les espaces réservés fournis.

Remarque sur la plate-forme : Si vous avez installé Anthos Service Mesh 1.7 sur EKS, vous devez installer Anthos Service Mesh 1.11 sur un nouveau cluster. Les mises à niveau d'Anthos Service Mesh 1.7 vers Anthos Service Mesh 1.11 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 Mesh CA 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 MeshMesh 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é Anthos Service Mesh avec une autre méthode que asmcli, la passerelle d'entrée par défaut installée sera supprimée, à moins d'être transmise dans 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-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-1107-1
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-1107-1
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1118-4
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1118-4

   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-1118-4.

   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-1107-1.

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 le libellé istio-injection. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.

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

   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. 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 d'Anthos 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

      Si vous avez effectué une mise à niveau à partir d'une version précédente d'Anthos 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
      

   4. 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é un libellé 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-1118-4 sur istiod. Pour activer l'injection automatique, vous devez ajouter un libellé de révision correspondant à votre ou vos espaces de noms. Le libellé 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é le libellé, redémarrez les pods de l'espace de noms pour que les sidecars soient injectés.

1. Obtenez le libellé de révision associé à 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-1118-4
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1118-4
   istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-1107-1
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-1107-1
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1118-4
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1118-4

   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-1118-4.

   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-1107-1.

2. 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 le libellé istio-injection. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.

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

   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. Supprimez l'ancien déploiement istio-ingressgateway. La commande que vous exécutez varie selon que vous effectuez la migration depuis Istio ou une mise à niveau depuis une version précédente d'Anthos 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 deploy/istio-ingressgateway -n istio-system
      

      Mettre à niveau

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

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

   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 d'Anthos 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

      Si vous avez effectué une mise à niveau à partir d'une version précédente d'Anthos 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
      

   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. Revenez à l'ancienne version de istio-ingressgateway. Dans la commande suivante, remplacez OLD_REVISION par l'ancienne révision.

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

   2. Modifier les libellés à votre espace de noms afin d'activer l'injection automatique avec la version précédente de istiod. La commande que vous utilisez varie selon que vous avez utilisé un libellé 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

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

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

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

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

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

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