Mettre à niveau Anthos Service Mesh

Cette page explique comment effectuer les actions suivantes :

  • Exécuterasmcli pour effectuer une mise à niveau à partir d'Anthos Service Mesh ou d'Istio Open Source 1.9 or a 1.10 patch release vers Anthos Service Mesh1.10.6. Les mises à niveau à partir de versions antérieures ne sont pas acceptées.

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

Avant de commencer

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

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.

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

  2. Vous pouvez également installer ou mettre à niveau une passerelle d'entrée.

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

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.

GKE

Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. 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.
  • --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

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

    kubectl config use-context CLUSTER_NAME
    
  2. Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.

    ./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 au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
    • --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 sur site est utilisée.
    • --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

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

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

     kubectl config use-context CLUSTER_NAME
    
  2. Exécutez la commande suivante pour installer Anthos Service Mesh avec les fonctionnalités par défaut et Istio CA :

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

    • --fleet_id : ID du projet du projet hôte du parc.
    • --kubeconfig : Chemin d'accès au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
    • --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 sur site est utilisée.
    • --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 de l'autorité de certification lors d'une mise à niveau entraîne des temps d'arrêt.

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 nouveau plan de contrôle avec les fonctionnalités par défaut. 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.
  • --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.

Sur site

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

    kubectl config use-context CLUSTER_NAME
    
  2. Exécutez la commande suivante pour installer le nouveau plan de contrôle avec les fonctionnalités par défaut. Saisissez vos valeurs dans les espaces réservés fournis.

    ./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 au fichier kubeconfig. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
    • --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 sur site est utilisée.
    • --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.

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-198-3
    istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
    istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
    istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2
    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-1106-2.

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

  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. Vérifiez que vos pods sont configurés pour pointer vers la nouvelle version de istiod.

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
  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. 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, 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.

    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.