Migrer depuis Istio

Cette page explique comment exécuter le script permettant de migrer d'Istio vers Anthos Service Mesh 1.10.6 sur un cluster GKE pour un maillage contenant un ou plusieurs clusters situés dans le même projet Google Cloud. Si vous disposez d'Istio 1.6 ou d'une version antérieure, vous devez d'abord effectuer la mise à niveau avant de migrer vers Anthos Service Mesh. Si vous disposez d'Istio 1.7 ou d'une version ultérieure, vous pourrez peut-être utiliser la fonctionnalité Migrer depuis Istio 1.7 ou version ultérieure vers Anthos Service Mesh et Mesh CA. Si vous devez effectuer une mise à niveau, accédez à la page Mettre à niveau Istio dans la version d'Istio applicable. Notez que la mise à niveau d'Istio vers plusieurs versions mineures (par exemple, 1.6.x vers 1.8.x) en une seule étape n'est pas officiellement testée ni recommandée.

Avant de commencer

Avant de commencer la migration, vérifiez que vous avez effectué les opérations suivantes :

Le script nécessite que vous disposiez des autorisations requises, ou que vous incluiez les options --enable_all ou --enable_gcp_iam_roles afin de lui permettre d'activer automatiquement l'autorisation. De même, pour autoriser le script à activer les API requises et à mettre à jour votre cluster, spécifiez l'option --enable_all ou des options d'activation plus précises.

Préparer une migration

Veillez à consulter la page Préparer la migration depuis Istio.

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.

Le script suit 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, le script installe une nouvelle révision du plan de contrôle en parallèle du plan de contrôle existant. Lors de l'installation de la nouvelle version, le script inclut un libellé revision qui identifie le nouveau plan de contrôle.

Vous effectuez ensuite une migration vers la nouvelle version en définissant le même libellé revision sur vos charges de travail et en effectuant un redémarrage progressif pour réinjecter les proxys afin qu'ils utilisent la nouvelle version et la nouvelle configuration d'Anthos Service Mesh. Avec cette approche, vous pouvez surveiller l'effet de la mise à niveau sur un petit pourcentage de vos charges de travail. Après avoir testé votre application, vous pouvez migrer tout le trafic vers la nouvelle version. Cette approche est beaucoup plus sûre qu'une mise à niveau sur place, où les nouveaux composants du plan de contrôle remplacent la version précédente.

Migrer vers Anthos Service Mesh

  1. Définissez les options permettant d'exécuter le script. Vous incluez toujours les options suivantes : project_id, cluster_name, cluster_location, mode et ca. Pour ca, vous disposez des options suivantes :

    • --ca mesh_ca : spécifiez cette option lorsque vous souhaitez migrer vers l'autorité de certification Anthos Service Mesh (Mesh CA).

    • --ca citadel : spécifiez cette option si vous souhaitez continuer à utiliser l'autorité de certification d'Istio.

    Pour en savoir plus, consultez la section Choisir une autorité de certification.

    Remarque : Vous pouvez utiliser --mode install pour une migration depuis Istio. Lorsque vous utilisez --mode install au lieu de --mode migrate, install_asm autorise la migration quelle que soit la version du plan de contrôle présente sur le cluster. L'option migrate n'autorise la migration que depuis la version mineure précédente ou depuis une version de correctif antérieure.

    La section suivante fournit des exemples typiques d'exécution du script. Pour obtenir une description complète des arguments du script, consultez la section Option et indicateurs.

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

Examples

Cette section présente des exemples d'exécution du script pour une migration depuis Istio, ainsi que des arguments supplémentaires qui peuvent vous être utiles. Consultez la barre de navigation située à droite pour obtenir la liste des exemples.

Valider uniquement

L'exemple suivant montre comment exécuter le script avec l'option --only_validate. Avec cette option, le script n'apporte aucune modification à votre projet ou cluster et il n'installe pas Anthos Service Mesh. Lorsque vous spécifiez l'option --only_validate, le script échoue si vous incluez l'une des options --enable_*.

Le script valide les points suivants :

  • Votre environnement dispose des outils nécessaires.
  • Vous disposez de l'autorisation requise sur le projet spécifié.
  • Le cluster répond aux exigences minimales.
  • Toutes les API Google requises sont activées dans le projet.

Par défaut, le script télécharge et extrait le fichier d'installation et télécharge le package de configuration asm de GitHub dans un répertoire temporaire. Avant de quitter, le script génère un message indiquant le nom du répertoire temporaire. Vous pouvez spécifier un répertoire pour les téléchargements à l'aide de l'option --output_dir DIR_PATH. L'option --output_dir vous permet d'utiliser l'outil de ligne de commande istioctl si vous en avez besoin. De plus, les fichiers de configuration permettant d'activer les fonctionnalités facultatives sont inclus dans le répertoire asm/istio/options.

Exécutez la commande suivante pour valider votre configuration et télécharger le fichier d'installation et le package asm dans le répertoire OUTPUT_DIR :

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --output_dir DIR_PATH \
  --only_validate

En cas de réussite, le script génère ce qui suit :

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Si l'un des tests échoue à la validation, le script génère un message d'erreur. Par exemple, si toutes les API Google requises ne sont pas activées pour votre projet, vous obtenez l'erreur suivante :

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Si vous recevez un message d'erreur indiquant que vous devez exécuter le script avec une option d'activation, vous disposez des options suivantes :

  • Incluez l'option spécifique du message d'erreur ou l'option --enable_all lors de l'exécution du script pour effectuer l'installation réelle (c'est-à-dire sans --only_validate).

  • Si vous préférez, vous pouvez vous-même mettre à jour votre projet et votre cluster avant d'exécuter le script, comme décrit dans la section Configurer l'installation d'Anthos Service Mesh sur GKE.

Notez que install_asm n'autorise aucune option d'activation avec --only_validate.

Migrer vers Mesh CA avec un temps d'arrêt

La migration vers l'autorité de certification Anthos Service Mesh (Mesh CA) à partir de l'autorité de certification d'Istio nécessite la migration de la racine de confiance. Pendant la migration, certaines charges de travail utilisent l'ancien certificat racine, tandis que d'autres utilisent le nouveau certificat racine Mesh CA. Les charges de travail utilisant des certificats signés par des certificats racine différents ne peuvent pas s'authentifier entre elles. L'ensemble du cluster n'est complètement rétabli que lorsque le plan de contrôle et toutes les charges de travail de tous les espaces de noms sont redéployés avec le nouveau certificat de l'autorité de certification racine.

Si vous pouvez planifier un temps d'arrêt, il s'agit du moyen le plus simple de migrer vers Anthos Service Mesh avec Mesh CA. L'exemple suivant montre des options de ligne de commande courantes pour migrer vers Mesh CA.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir OUTPUT_DIRECTORY
  --enable_all

Migrer vers Mesh CA avec peu ou pas de temps d'arrêt

Si vous ne pouvez pas programmer de temps d'arrêt pour la migration vers Mesh CA, un processus de migration vers Mesh CA reste possible, mais celui-ci nécessite des étapes supplémentaires. Pour en savoir plus, consultez la section Migrer vers Mesh CA.

Migrer, mais continuer à utiliser Istio CA

Si vous avez besoin d'une autorité de certification personnalisée, vous pouvez continuer à utiliser l'autorité de certification d'Istio après avoir migré vers Anthos Service Mesh. La commande suivante exécute le script pour une migration et active l'autorité de certification d'Istio. (L'option --ca citadel est appelée "citadel" car il s'agissait du nom du composant CA avant que tous les composants Istio n'aient été intégrés à istiod.) Cette migration ne déploie que le plan de contrôle et la passerelle d'entrée. Elle ne modifie pas l'autorité de certification racine et ne perturbe pas vos charges de travail existantes.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all

Effectuer la migration en utilisant un fichier superposé

Un fichier de superposition est un fichier YAML contenant une ressource personnalisée IstioOperator que vous transmettez à install_asm 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 à install_asm. Vous pouvez effectuer plusieurs couches de superpositions. Chaque fichier de superposition remplace la configuration dans les couches précédentes.

Si vous spécifiez plusieurs ressources personnalisées dans un fichier YAML, install_asm divise ce fichier en plusieurs fichiers YAML temporaires, un pour chaque ressource personnalisée. Le script divise les ressources personnalisées en fichiers distincts, car istioctl install applique uniquement la première ressource personnalisée dans un fichier YAML qui en contient plusieurs.

L'exemple suivant effectue une migration et inclut un fichier de superposition pour personnaliser la configuration du plan de contrôle. Dans la commande suivante, remplacez OVERLAY_FILE par le nom du fichier YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Effectuer la migration en utilisant une option

L'exemple suivant effectue une migration en incluant le fichier egressgateways.yaml du package asm qui active une passerelle de sortie. Notez que vous n'incluez pas l'extension .yaml. Le script extrait le fichier à votre place afin que vous n'ayez pas à télécharger le package asm au préalable.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --enable_all \
  --option egressgateways

Vous pouvez utiliser --option pour activer une fonctionnalité facultative. Si vous devez modifier des fichiers dans le répertoire asm/istio/options du package asm, téléchargez le package asm, apportez vos modifications et incluez le fichier à l'aide de --custom_overlay.

Pour télécharger le package asm dans le répertoire de travail actuel afin de pouvoir modifier les fichiers :

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.10-asm asm

Si vous avez exécuté l'exemple Only validate (Valider uniquement) avec l'option --output_dir, les fichiers de configuration se trouvent dans le répertoire de sortie spécifié sous asm/istio/options.

Déployer et redéployer des charges de travail

Votre installation n'est pas terminée tant que vous n'avez pas activé l'injection automatique du proxy side-car (injection automatique). 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-1106-2 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-1106-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
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. 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. É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.

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

Afficher les tableaux de bord Anthos Service Mesh

Une fois que les charges de travail sont déployées sur votre cluster et que les proxys side-car ont été injectés, vous pouvez explorer les pages Anthos Service Mesh de la console Google Cloud pour consulter toutes les fonctionnalités d'observabilité offertes par Anthos Service Mesh. Notez qu'il faut environ une à deux minutes pour que les données de télémétrie soient affichées dans la console Google Cloud après le déploiement des charges de travail.

L'accès à Anthos Service Mesh dans la console Google Cloud est contrôlé par IAM (Identity and Access Management). Pour permettre l'accès aux pages Anthos Service Mesh, un propriétaire de projet doit accorder aux utilisateurs le rôle éditeur ou lecteur de projet, ou les rôles plus restrictifs décrits dans la section Contrôler l'accès à Anthos Service Mesh dans la console Google Cloud.

  1. Dans Google Cloud Console, accédez à Anthos Service Mesh.

    Accéder à Anthos Service Mesh

  2. Sélectionnez le projet Google Cloud dans la liste déroulante de la barre de menu.

  3. Si vous avez plusieurs maillages de services, sélectionnez le maillage dans la liste déroulante Maillage de services.

Pour en savoir plus, consultez la page Explorer Anthos Service Mesh dans la console Google Cloud.

Outre les pages Anthos Service Mesh, les métriques liées à vos services (telles que le nombre de requêtes reçues par un service particulier) sont envoyées à Cloud Monitoring, où elles apparaissent dans l'explorateur de métriques.

Pour afficher les métriques, procédez comme suit :

  1. Dans Google Cloud Console, accédez à la page Monitoring :

    Accéder à Monitoring

  2. Sélectionnez Ressources > Explorateur de métriques.

Pour obtenir la liste complète des métriques, consultez la section Métriques Istio dans la documentation Cloud Monitoring.

Étapes suivantes