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

  • 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.14.6-asm.16 sur Google Kubernetes Engine à partir des versions suivantes :

1.12 et supérieures

Sur site

Vous pouvez passer directement à Anthos Service Mesh 1.14.6-asm.16 sur GKE sur VMware et à Google Distributed Cloud Virtual pour Bare Metal à partir des versions suivantes:

1.12 et supérieures

GKE sur AWS

Vous pouvez effectuer directement la mise à niveau vers Anthos Service Mesh 1.14.6-asm.16 sur GKE sur AWS à partir des versions suivantes:

1.12 et supérieures

Amazon EKS

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

Microsoft AKS

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

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

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.
  • --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 à jour les fonctionnalités par défaut avec CA Service

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

  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.

  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.
  • --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, Amazon EKS ou Microsoft AKS. 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 \
  --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.

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-1146-16-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1139-10
istiod-asm-1146-16-67998f4b55-r76kr           1/1     Running   0          68m   asm-1139-10
istiod-1139-10-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1146-16
istiod-1139-10-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1146-16

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

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

  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. Comme l'injection automatique échoue si un espace de noms possède à la fois le libellé istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh spécifient explicitement les deux libellés.

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

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

      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é 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-1146-16 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-1146-16
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1146-16
istiod-asm-1146-16-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1139-10
istiod-asm-1146-16-67998f4b55-r76kr          1/1     Running   0          68m   asm-1139-10
istiod-asm-1139-10-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1146-16
istiod-asm-1139-10-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1146-16

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

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

  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 le libellé istio-injection. Comme l'injection automatique échoue si un espace de noms possède à la fois le libellé istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh spécifient explicitement les deux libellés.

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

    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>

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

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

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