Anthos Service Mesh 1.10 est arrivé en fin de vie et n'est plus pris en charge. Consultez la section Mettre à niveau à partir de versions antérieures.

Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Migrer depuis Istio 1.7 ou version ultérieure vers Anthos Service Mesh et Mesh CA

Ce document explique comment les administrateurs Google Kubernetes Engine (GKE) peuvent installer Anthos Service Mesh et migrer des charges de travail en cours d'exécution avec un maillage de services Istio. La configuration déployée d'Anthos Service Mesh inclut Cloud Monitoring pour la télémétrie et l'autorité de certification Anthos Service Mesh pour la gestion des certificats de maillage gérés à haute disponibilité. Les passerelles, les services virtuels et les autres configurations de maillage qui définissent votre topologie de maillage sont conservés dans la migration.

Ce processus couvre une installation à cluster unique. Pour une installation de maillage multicluster, consultez la page Configurer un maillage multicluster sur GKE, qui indique comment ajouter des clusters à Anthos Service Mesh. après l'installation.

Pour suivre la procédure décrite dans ce document, vous devez utiliser Istio 1.7 ou une version ultérieure avec un cluster GKE. Anthos Service Mesh n'est pas compatible avec Helm pour l'installation ou la configuration. Nous recommandons aux administrateurs de maillage d'utiliser l'API IstioOperator pour les configurations de maillage. Ce processus peut entraîner des temps d'arrêt pour votre application lors du changement d'autorités de certification. Nous vous recommandons donc d'effectuer ce processus lors d'un intervalle de maintenance programmé.

Anthos Service Mesh utilise les mêmes API Istio et Envoy pour configurer votre maillage. Par conséquent, aucune modification des ressources existantes n'est nécessaire.

Voici quelques différences de mise en œuvre après la migration :

  • Le plan de contrôle Istio est remplacé par un plan de contrôle Anthos Service Mesh.

  • L'autorité de certification Citadel est supprimée et les certificats sont gérés par un service Google Cloud Mesh CA.

  • La télémétrie est envoyée à Cloud Logging et Cloud Monitoring. Les tableaux de bord et la gestion des SLO sont disponibles dans Google Cloud Console.

  • Si vous disposez d'une ressource IstioOperator personnalisée, le script peut l'utiliser comme entrée.

  • Votre installation Istio Open Source (version 1.7 ou ultérieure) est migrée vers la version 1.10 d'Anthos Service Mesh avec Mesh CA. Si vous disposez d'une version différente d'Istio ou si vous avez besoin d'une version différente d'Anthos Service Mesh ou si vous souhaitez déployer Anthos Service Mesh avec un plan de contrôle géré par Google, consultez la pagePréparer la migration depuis Istio.

Prérequis

Les conditions préalables suivantes sont requises pour suivre ce guide :

  • Vous disposez d'un cluster GKE avec version 1.7 ou ultérieure d'Istio. Si vous n'avez pas de cluster GKE ou si vous souhaitez tester ce guide sur un nouveau cluster (test), commencez par suivre les étapes décrites dans l'annexe pour créer Un nouveau cluster GKE avec Istio version 1.7 ou ultérieure déployé avec une application de test.

  • Vous utilisez Cloud Shell pour effectuer les étapes décrites dans ce guide, car ce guide est testé sur Cloud Shell.

Objectifs

Dans ce guide, vous choisissez un chemin de migration. Vous pouvez choisir entre un chemin d'accès scripté à une étape ou une migration scriptée étape par étape.

Pour en savoir plus, consultez Choisir un chemin de migration.

Pour obtenir des réponses aux questions fréquentes sur cette migration, consultez la page Questions fréquentes sur la migration depuis Istio 1.7 ou version ultérieure vers Anthos Service Mesh et Mesh CA.

Avant de commencer

Pour ce guide, vous avez besoin d'un accès administrateur à un cluster GKE sur lequel Istio est installé. Pour observer le comportement de votre application pendant le processus de migration, nous vous recommandons de commencer par effectuer ce processus avec un cluster dans un environnement de développement ou de préproduction.

Anthos Service Mesh doit répondre aux exigences suivantes. Vous pouvez les exécuter manuellement ou autoriser les outils fournis à activer des dépendances en votre nom lors du processus de pré-installation.

  1. Activez les API Google Cloud suivantes :

    • container.googleapis.com
    • meshca.googleapis.com
    • meshconfig.googleapis.com
    • gkehub.googleapis.com
    • stackdriver.googleapis.com
  2. Activez Workload Identity et Stackdriver pour votre cluster GKE.

  3. Ajoutez un libellé à votre cluster pour activer l'interface utilisateur du service.

  4. Obtenez des droits d'administrateur sur le cluster Kubernetes.

  5. Enregistrer un cluster dans un parc.

  6. Activez la fonctionnalité servicemesh sur le parc.

Configurer votre environnement

Pour configurer votre environnement, procédez comme suit :

  1. Dans Google Cloud Console, activez Cloud Shell :

    Activer Cloud Shell

    En bas de la fenêtre de Cloud Console, une session Cloud Shell démarre et affiche une invite de ligne de commande. Cloud Shell est un environnement shell dans lequel Google Cloud CLI est déjà installé, et dans lequel des valeurs sont déjà définies pour votre projet actuel. L'initialisation de la session peut prendre quelques secondes.

  2. Créez les variables d'environnement utilisées dans ce guide :

    export PROJECT_ID=PROJECT_ID
    gcloud config set project ${PROJECT_ID}
    export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
    export CLUSTER_NAME=GKE_CLUSTER_NAME
    export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
    
  3. Créer un dossier WORKDIR

    mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`
    
  4. Créez un fichier KUBECONFIG pour ce guide :

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
    
  5. Connectez-vous à votre cluster GKE :

    Cluster zonal

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
       --zone ${CLUSTER_LOCATION}
    

    Clusters régionaux

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
       --region ${CLUSTER_LOCATION}
    
  6. Désactivez la CNI gérée en modifiant la CRD ControlPlaneRevision et en appliquant le libellé mesh.cloud.google.com/managed-cni-enabled: "false":

    apiVersion: mesh.cloud.google.com/v1beta1
    kind: ControlPlaneRevision
    metadata:
      labels:
        mesh.cloud.google.com/managed-cni-enabled: "false"
    

    Notez que cette étape peut prendre jusqu'à cinq minutes avant que le rapprochement n'applique la modification.

  7. Téléchargez le script de migration :

    curl -LO https://storage.googleapis.com/csm-artifacts/asm/migrate-to-asm
    chmod +x ./migrate-to-asm
    

Choisir un chemin de migration

Vous pouvez choisir l'un des deux chemins de migration vers Anthos Service Mesh. Choisissez l'une des deux stratégies suivantes, puis passez à la section suivante :

  • Migration en une étape vers Anthos Service Mesh Comme son nom l'indique, vous pouvez effectuer toutes les étapes requises pour migrer vers Anthos Service Mesh à l'aide d'une seule commande. Cela peut être utile si vous avez de nombreux clusters et que vous avez besoin d'un moyen rapide et facile de les mettre à niveau vers Anthos Service Mesh. Toutefois, cette méthode peut entraîner des temps d'arrêt de l'application.

  • Migration étape par étape vers Anthos Service Mesh. Cette méthode vous permet de mieux contrôler chaque étape et vous aide à comprendre exactement ce qui est nécessaire pour migrer vers Anthos Service Mesh.

Migration en une seule étape vers Anthos Service Mesh

Dans cette section, vous migrez votre installation Istio 1.7 (ou ultérieure) actuelle vers Anthos Service Mesh version 1.10. Cette section vous permet d'effectuer la migration en exécutant une seule étape. Si vous souhaitez effectuer la migration en exécutant une série d'étapes, consultez la section Migration étape par étape vers Anthos Service Mesh.

Pour migrer vers Anthos Service Mesh, exécutez la commande suivante. Avec n'importe quelle commande, vous pouvez utiliser l'indicateur --dry-run pour imprimer des commandes au lieu de les exécuter, ou vous pouvez utiliser l'indicateur --verbose pour imprimer des commandes lorsque le script les exécute. Si vous avez déjà configuré des dépendances, comme indiqué dans la section Avant de commencer, vous pouvez omettre l'option --enable-dependencies.

Aucune ressource personnalisée

N'utilisez pas de ressource IstioOperator personnalisée :

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --verbose

Utiliser une ressource personnalisée

Utilisez une ressource IstioOperator personnalisée :

export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --custom_overlay ${ISTIO_OPERATOR_FILEPATH} \
    --verbose

Cette commande effectue les étapes suivantes :

  • Garantit que la version d'Istio est la version 1.7 ou ultérieure.
  • Active Workload Identity sur le cluster. Workload Identity est requis pour Mesh CA. Vous n'avez pas besoin d'activer le serveur GKE Metadata sur les pools de nœuds existants.
  • Active les API requises pour Anthos Service Mesh.
  • Enregistre le cluster dans un parc.
  • Met à jour le cluster avec les libellés requis.
  • Détermine si un plan de contrôle géré par Google est mieux adapté au cluster spécifié.
  • Déploie Anthos Service Mesh avec la configuration de plan de contrôle optimale.
  • Elle ajoute un libellé Anthos Service Mesh requis à tous les espaces de noms pour lesquels Istio est activé.
  • Redémarre les charges de travail dans tous les espaces de noms compatibles avec Anthos Service Mesh afin que les charges de travail obtiennent les nouveaux proxys Service Mesh.
  • Supprime le plan de contrôle Istio.

Migration par étapes vers Anthos Service Mesh

Dans cette section, vous allez migrer votre installation d'Istio version 1.7 (ou ultérieure) vers Anthos Service Mesh version 1.10. Cette section vous permet d'effectuer la migration en exécutant une série d'étapes. Si vous souhaitez effectuer la migration en une seule étape, consultez la section Migration en une étape vers Anthos Service Mesh.

Pour migrer vers Anthos Service Mesh, procédez comme suit :

  1. Effectuez une étape de pré-migration pour valider et préparer le cluster et l'environnement pour la migration vers Anthos Service Mesh.
  2. Installer Anthos Service Mesh en tant que plan de contrôle Canary avec un plan de contrôle Istio existant et préparer les charges de travail
  3. Tester des charges de travail sur Anthos Service Mesh et étiqueter les espaces de noms pour l'injection side-car Anthos Service Mesh
  4. Accéder aux tableaux de bord Anthos Service Mesh et les inspecter
  5. Nettoyez les artefacts Istio ou revenez à une version existante d'Istio.

Effectuer l'étape préalable à la migration

L'étape préalable à la migration effectue les actions suivantes :

  • Il vérifie que les informations du projet et du cluster sont correctes et que la version d'Istio installée est compatible avec la migration.

  • Il sauvegarde la configuration de la passerelle par défaut et les libellés du maillage de services Istio actuel.

  • Si l'option --enable-dependencies est utilisée, elle active les dépendances en votre nom. Sinon, elle vérifie que les dépendances sont activées.

Le script de pré-migration crée un dossier (ou écrase un dossier existant) appelé configuration_backup dans le répertoire actuel.

Pour effectuer l'étape de pré-migration, exécutez la commande suivante :

Dépendances

Activez les dépendances :

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies

Aucune dépendance

N'activez pas les dépendances :

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID

Le résultat ressemble à ce qui suit :

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Confirming cluster information for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Confirming node pool requirements for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Checking existing Istio version(s)...
    migrate-to-asm:   1.9.5
    migrate-to-asm: No version issues found.
    migrate-to-asm: Enabling required APIs...
    migrate-to-asm:
    migrate-to-asm: APIs enabled.
    migrate-to-asm: Enabling the service mesh feature...
    migrate-to-asm:
    migrate-to-asm: The service mesh feature is already enabled.
    migrate-to-asm: Enabling Stackdriver on $LOCATION/$CLUSTER_NAME...
    Updating $CLUSTER_NAME...
    .........................done.
    Updated [https://container.googleapis.com/v1/projects/$PROJECT_ID/zones/$LOCATION/clusters/$CLUSTER_NAME].
    To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/$LOCATION/$CLUSTER_NAME?project=$PROJECT_ID
    migrate-to-asm:
    migrate-to-asm: Stackdriver enabled.
    migrate-to-asm: Querying for core/account...
    migrate-to-asm: Binding user@example.com to cluster admin role...
    migrate-to-asm:
    migrate-to-asm:
    migrate-to-asm: Successfully bound to cluster admin role.
    migrate-to-asm: Initializing meshconfig API...
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100     3    0     3    0     0      6      0 --:--:-- --:--:-- --:--:--     6
    migrate-to-asm:
    migrate-to-asm: Finished pre-migration!

Installer Anthos Service Mesh et préparer les charges de travail

Cette étape permet d'effectuer les opérations suivantes :

  • Elle vérifie la présence du dossier configuration_backup et, s'il n'est pas présent, abandonne la tâche, afin d'assurer l'exécution de l'outil de pré-migration.
  • Il installe et configure un plan de contrôle Anthos Service Mesh basé sur l'analyse de la configuration du cluster et du maillage.
  • Il utilise la ressource personnalisée IstioOperator, le cas échéant. Si vous disposez de passerelles personnalisées ou de plusieurs passerelles configurées à l'aide d'une ressource IstioOperator, utilisez la même ressource à cette étape.

Pour ignorer l'analyse et forcer l'outil à installer un plan de contrôle non géré s'exécutant avec les ressources de votre cluster, ajoutez l'option --no-mcp à votre commande.

Vous pouvez choisir l'un des trois chemins suivants lors de l'installation d'Anthos Service Mesh:

  • Option 1 : Sans ressource IstioOperator personnalisée. Vous pouvez installer Anthos Service Mesh sans ressource personnalisée. Cette option permet d'installer la configuration par défaut d'Istio et de mettre à jour la passerelle istio-ingressgateway par défaut.

  • Option 2 : avec une option --no-gateways. Lorsque vous installez Anthos Service Mesh sans ressource IstioOperator personnalisée, vous pouvez également utiliser l'option --no-gateways pour ne pas mettre à jour la valeur istio-ingressgateway par défaut. Si vous utilisez cette option, vous devez mettre à niveau les passerelles manuellement après l'installation.

  • Option 3 : Avec une ressource IstioOperator personnalisée Vous pouvez installer Anthos Service Mesh avec une ressource IstioOperator personnalisée. Si vous avez déployé Istio à l'aide d'une ressource IstioOperator personnalisée, nous vous recommandons d'utiliser la même ressource IstioOperator lors de l'installation d'Anthos Service Mesh.

Pour installer Anthos Service Mesh, exécutez l'une des commandes suivantes :

Option 1

Mettez à niveau le istio-ingressgateway par défaut :

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

Option 2

Ne mettez pas à jour le istio-ingressgateway par défaut :

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --no-gateways

Option n° 3

Mettez à niveau les passerelles en place avec une ressource IstioOperator personnalisée :

 export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --custom-overlay ${ISTIO_OPERATOR_FILEPATH}

Le résultat ressemble à ce qui suit :

 migrate-to-asm: Checking installation tool dependencies...
 migrate-to-asm: Checking for $PROJECT_ID...
 migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
 Fetching cluster endpoint and auth data.
 kubeconfig entry generated for $CLUSTER_NAME.
 migrate-to-asm:
 migrate-to-asm: Verifying connectivity (20s)...
 migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
 migrate-to-asm: Configuring kpt package...
 asm/
 set 20 field(s) of setter "gcloud.container.cluster" to value "$CLUSTER_NAME"
 asm/
 set 28 field(s) of setter "gcloud.core.project" to value "$PROJECT_ID"
 asm/
 set 2 field(s) of setter "gcloud.project.projectNumber" to value "42"
 asm/
 set 5 field(s) of setter "gcloud.project.environProjectNumber" to value "42"
 asm/
 set 20 field(s) of setter "gcloud.compute.location" to value "$LOCATION"
 asm/
 set 1 field(s) of setter "gcloud.compute.network" to value "$PROJECT_ID-default"
 asm/
 set 6 field(s) of setter "anthos.servicemesh.rev" to value "asm-1102-2"
 asm/
 set 5 field(s) of setter "anthos.servicemesh.tag" to value "1.10.2-asm.2"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.hubTrustDomain" to value "$PROJECT_ID.svc.id.goog"
 asm/
 set 2 field(s) of setter "anthos.servicemesh.hub-idp-url" to value "https://container.googleapis.com/v1/projects/$PROJECT_ID/locations/$LOCATION/clusters/$CLUSTER_NAME"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.trustDomainAliases" to value "$PROJECT_ID.svc.id.goog"
 migrate-to-asm: Configured.
 migrate-to-asm: Installing Anthos Service Mesh control plane...
 migrate-to-asm:
 - Processing resources for Istio core.
 ✔ Istio core installed
 - Processing resources for Istiod.
 - Processing resources for Istiod. Waiting for Deployment/istio-system/istiod-asm-1102-2
 ✔ Istiod installed
 - Processing resources for CNI, Ingress gateways.
 - Processing resources for CNI, Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ CNI installed
 - Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ Ingress gateways installed
 - Pruning removed resources
 migrate-to-asm:
 migrate-to-asm:
 namespace/asm-system created
 customresourcedefinition.apiextensions.k8s.io/canonicalservices.anthos.cloud.google.com configured
 role.rbac.authorization.k8s.io/canonical-service-leader-election-role created
 clusterrole.rbac.authorization.k8s.io/canonical-service-manager-role configured
 clusterrole.rbac.authorization.k8s.io/canonical-service-metrics-reader unchanged
 serviceaccount/canonical-service-account created
 rolebinding.rbac.authorization.k8s.io/canonical-service-leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-manager-rolebinding unchanged
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-proxy-rolebinding unchanged
 service/canonical-service-controller-manager-metrics-service created
 deployment.apps/canonical-service-controller-manager created
 deployment.apps/canonical-service-controller-manager condition met
 migrate-to-asm:
 migrate-to-asm:
 migrate-to-asm: *******
 migrate-to-asm: Control plane installation complete!

Injecter à nouveau de nouvelles charges de travail et vérifier le comportement de l'application

Le plan de contrôle d'Anthos Service Mesh est maintenant prêt à gérer les charges de travail, mais le plan de contrôle d'Istio existant gère toujours les charges de travail existantes. Pour migrer ces charges de travail, vous devez modifier les étiquettes des espaces de noms Kubernetes qui sont actuellement étiquetés pour l'injection Istio avec le libellé de révision Anthos Service Mesh. Vous devez ensuite redémarrer les charges de travail dans ces espaces de noms. Vous pouvez le faire manuellement (voir la remarque à l'étape 1) ou en une seule étape à l'aide de l'outil.

L'étape de changement de libellé effectue les opérations suivantes :

  • Il trouve tous les espaces de noms qui utilisent actuellement un libellé d'injection Istio.
  • Elle ajoute le libellé istio.io/rev=asm-1102-2 à ces espaces de noms.
  • Il redémarre les charges de travail dans l'espace de noms.

Pour réinjecter les charges de travail, procédez comme suit :

  1. Attribuez un nouveau libellé à tous les espaces de noms compatibles avec Istio et redémarrez les charges de travail en exécutant la commande suivante :

     ./migrate-to-asm relabel \
         --cluster_location $CLUSTER_LOCATION \
         --cluster-name $CLUSTER_NAME \
         --project-id $PROJECT_ID
    

    Le résultat ressemble à ce qui suit :

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for $CLUSTER_NAME.
    migrate-to-asm:
    migrate-to-asm: Verifying connectivity (20s)...
    migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    ******
    migrate-to-asm: Installation of Anthos Service Mesh has completed. Migration will continue
    migrate-to-asm: by relabeling and restarting workloads in the following namespaces:
    migrate-to-asm:     namespace/default
    migrate-to-asm:
    Continue with migration? (Y/n)Y
    migrate-to-asm: Relabeling namespace/default...
    namespace/default labeled
    migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
    deployment.apps/frontend restarted
    deployment.apps/backend restarted
    deployment.apps/frontend condition met
    deployment.apps/backend condition met
    migrate-to-asm: *******
    migrate-to-asm: Finished restarting workloads!
    
  2. Attendez que tous les déploiements soient redémarrés, puis vérifiez la version du plan de données en exécutant la commande suivante :

    istioctl version
    

    Le résultat ressemble à ce qui suit :

    client version: 1.8.0
    pilot version: 1.9.5
    istiod version: 1.10.2-asm.2
    data plane version: 1.10.2-asm.2 (14 proxies)
    
  3. Vérifiez que les applications fonctionnent correctement après le redémarrage.

Accéder aux tableaux de bord Anthos Service Mesh

Dans cette section, accédez aux tableaux de bord Anthos Service Mesh et assurez-vous que vous recevez les signaux clés pour tous les services. Vous devriez également pouvoir voir la topologie de votre application.

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

    Accéder à Anthos Service Mesh

  2. Vous devriez pouvoir afficher les métriques et la topologie de vos services.

Pour en savoir plus sur les tableaux de bord Anthos Service Mesh, consultez la page Explorer Anthos Service Mesh dans Cloud Console.

Finalisez votre migration

Avant de finaliser votre migration, assurez-vous que toutes vos applications fonctionnent correctement. Une fois la migration terminée, vous ne pouvez pas revenir à la version d'Istio existante. La finalisation de votre migration effectue les étapes suivantes :

  • Il valide que tous les proxys en cours d'exécution du cluster utilisent Anthos Service Mesh.
  • Elle supprime les composants Istio inutilisés du cluster. Cette étape est irréversible.

Pour finaliser votre migration vers Anthos Service Mesh, exécutez la commande suivante :

 ./migrate-to-asm finalize \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
Le résultat ressemble à ce qui suit :
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for asm-scriptaro-oss...
migrate-to-asm: All proxies running Anthos Service Mesh!
Remove previous control plane resources? (Y/n)
migrate-to-asm: ****
migrate-to-asm: Previous Istio control plane has been removed.

Restaurer une version d'Istio existante

Exécutez l'étape de rollback pour étiqueter les espaces de noms avec l'étiquette d'injection Istio précédente, redémarrer les charges de travail et effectuer un rollback des modifications de passerelle. Ensuite, l'outil supprime tous les composants Anthos Service Mesh déployés dans le cluster.

Vous devez rétablir manuellement toutes les dépendances activées à l'étape de pré-migration.

Pour revenir à Istio, exécutez la commande suivante :

 ./migrate-to-asm rollback \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
Le résultat ressemble à ce qui suit :
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
******
migrate-to-asm: Rolling back migration by relabeling and restarting workloads
migrate-to-asm: in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with rollback? (Y/n)
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!
service/istio-ingressgateway configured
deployment.apps/istio-ingressgateway configured
There are still 14 proxies pointing to the control plane revision asm-1102-2
istio-ingressgateway-66c85975d-2gt8c.istio-system
istio-ingressgateway-66c85975d-jdd96.istio-system
...
frontend-685dcb78d6-9l45j.default
If you proceed with the uninstall, these proxies will become detached from any control plane and will not function correctly.

Removed HorizontalPodAutoscaler:istio-system:istio-ingressgateway.
Removed HorizontalPodAutoscaler:istio-system:istiod-asm-1102-2.
...
Removed ClusterRoleBinding::mdp-controller.
✔ Uninstall complete
namespace "asm-system" deleted
migrate-to-asm: ****
migrate-to-asm: Anthos Service Mesh has been uninstalled from the cluster.

Annexe

Créer un cluster GKE avec Istio installé

Dans cette section, vous allez déployer un cluster GKE avec Istio activé. Vous pouvez utiliser un cluster GKE privé ou non privé. Les clusters GKE privés doivent disposer d'un point de terminaison GKE public. Vous allez également vérifier l'installation d'Istio.

Si vous disposez déjà d'un cluster GKE, vous pouvez ignorer l'étape de création et vous assurer que vous avez accès au cluster qui utilise le fichier KUBECONFIG. Le contexte utilisé par ce guide est défini dans la variable ${CLUSTER_1_CTX}. Vous pouvez définir le contexte de votre cluster sur cette variable.

  1. Créez les variables d'environnement utilisées dans ce guide :

    # Enter your project ID
    export PROJECT_ID=PROJECT_ID
    gcloud config set project ${PROJECT_ID}
    export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
    export CLUSTER_NAME=GKE_CLUSTER_NAME
    export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
    export CLUSTER_CTX=gke_${PROJECT_ID}_${CLUSTER_LOCATION}_${CLUSTER_NAME}
    export ISTIO_VERSION=ISTIO_VERSION # Must be versions 1.7 through 1.10 and must be of the form major.minor.patch, for example 1.7.4 or 1.9.5
    
  2. Créer un cluster GKE avec Istio activé (il s'agit d'un cluster privé). Vous pouvez également effectuer ces étapes avec un cluster GKE non privé.

    Cluster zonal

    gcloud container clusters create ${CLUSTER_NAME} \
        --project ${PROJECT_ID} \
        --zone ${CLUSTER_LOCATION} \
        --machine-type "e2-standard-4" \
        --num-nodes "4" --min-nodes "2" --max-nodes "5" \
        --enable-ip-alias --enable-autoscaling
    

    Clusters régionaux

    gcloud container clusters create ${CLUSTER_NAME} \
        --project ${PROJECT_ID} \
        --region ${CLUSTER_LOCATION} \
        --machine-type "e2-standard-4" \
        --num-nodes "4" --min-nodes "2" --max-nodes "5" \
        --enable-ip-alias --enable-autoscaling
    
  3. Confirmez que le cluster est RUNNING :

     gcloud container clusters list
    

    Le résultat ressemble à ce qui suit :

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
    gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING
    
  4. Connectez-vous au cluster :

    Cluster zonal

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
        --zone ${CLUSTER_LOCATION}
    

    Clusters régionaux

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
        --region ${CLUSTER_LOCATION}
    

N'oubliez pas de désactiver votre variable KUBECONFIG à la fin.

Installer Istio

Dans cette section, vous déployez Istio version 1.7 sur le cluster GKE.

  1. Télécharger Istio

    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -
    
  2. Installez Istio à l'aide de l'outil de ligne de commande istioctl. Choisissez l'une des options suivantes :

    • Option 1 : sans ressource personnalisée IstioOperator
    • Option 2 : avec une ressource IstioOperator personnalisée

    Option 1

    Sans ressource IstioOperator personnalisée :

    ./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -y
    

    Le résultat ressemble à ce qui suit :

    ✔ Istio core installed
    ✔ Istiod installed
    ✔ Ingress gateways installed
    ✔ Installation complete
    

    Option 2

    Avec une ressource IstioOperator personnalisée :

    cat <<EOF > istio-operator.yaml
    apiVersion: install.istio.io/v1alpha1
    kind: IstioOperator
    metadata:
     name: istio-operator
    spec:
     components:
       base:
         enabled: true
       ingressGateways:
       - enabled: true
         k8s:
           env:
           - name: TERMINATION_DRAIN_DURATION_SECONDS
             value: "10"
           hpaSpec:
             maxReplicas: 10
             metrics:
             - resource:
                 name: cpu
                 targetAverageUtilization: 80
               type: Resource
             minReplicas: 2
           resources:
             limits:
               cpu: "4"
               memory: 8Gi
             requests:
               cpu: "2"
               memory: 4Gi
           service:
             ports:
             - name: status-port
               port: 15021
               targetPort: 15021
             - name: http2
               port: 80
               targetPort: 8080
             - name: https
               port: 443
               targetPort: 8443
             - name: tls
               port: 15443
               targetPort: 15443
         name: istio-ingressgateway
       - enabled: true
         k8s:
           env:
           - name: TERMINATION_DRAIN_DURATION_SECONDS
             value: "10"
           hpaSpec:
             maxReplicas: 10
             minReplicas: 2
           resources:
             limits:
               cpu: "4"
               memory: 8Gi
             requests:
               cpu: "2"
               memory: 4Gi
           service:
             ports:
             - name: status-port
               port: 15021
               targetPort: 15021
             - name: http2
               port: 80
               targetPort: 8080
             - name: https
               port: 443
               targetPort: 8443
             - name: tls
               port: 15443
               targetPort: 15443
         label:
           istio: istio-api-ingressgateway
         name: istio-api-ingressgateway
     meshConfig:
       defaultConfig:
         tracing:
           sampling: 1
           zipkin:
             address: jaeger-collector.observability.svc.cluster.local:9411
       enableTracing: true
    EOF
    
    ./istio-${ISTIO_VERSION}/bin/istioctl install -f istio-operator.yaml -y
    

    Le résultat ressemble à ce qui suit :

    ✔ Istio core installed
    ✔ Istiod installed
    ✔ Ingress gateways installed
    ✔ Installation complete
    
  3. Assurez-vous que les services et les pods Istio sont déployés et exécutés :

    kubectl --context=${CLUSTER_CTX} -n istio-system get services,pods
    

    Le résultat ressemble à ce qui suit :

    Option 1

    Sans ressource IstioOperator personnalisée :

    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)                                                      AGE
    service/istio-ingressgateway   LoadBalancer   10.64.5.113    <pending>           15021:31285/TCP,80:31740/TCP,443:30753/TCP,15443:31246/TCP   33s
    service/istiod                 ClusterIP      10.64.15.184   <none>              15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP                45s
    
    NAME                                        READY   STATUS    RESTARTS   AGE
    pod/istio-ingressgateway-6f44d6745b-22q9h   1/1     Running   0          34s
    pod/istiod-b89f5cc6-nhsrc                   1/1     Running   0          48s
    

    Option 2

    Avec une ressource IstioOperator personnalisée :

    NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
    service/istio-api-ingressgateway   LoadBalancer   10.100.0.84    104.196.26.108   15021:32489/TCP,80:30083/TCP,443:30565/TCP,15443:30705/TCP   76s
    service/istio-ingressgateway       LoadBalancer   10.100.3.221   34.139.111.125   15021:30966/TCP,80:31557/TCP,443:31016/TCP,15443:31574/TCP   75s
    service/istiod                     ClusterIP      10.100.13.72   <none>           15010/TCP,15012/TCP,443/TCP,15014/TCP                        86s
    
    NAME                                            READY   STATUS    RESTARTS   AGE
    pod/istio-api-ingressgateway-79978ddc65-hslbv   1/1     Running   0          61s
    pod/istio-api-ingressgateway-79978ddc65-z92w8   1/1     Running   0          77s
    pod/istio-ingressgateway-fb47c4859-pkdn7        1/1     Running   0          60s
    pod/istio-ingressgateway-fb47c4859-t2pfq        1/1     Running   0          77s
    pod/istiod-9445656d7-fxk9j                      1/1     Running   0          89s
    

Déployer Online Boutique

Dans cette section, vous allez déployer un exemple d'application basée sur des microservices, appelée Boutique en ligne, sur le cluster GKE. Online Boutique est déployé dans un espace de noms compatible avec Istio. Vous allez vérifier que l'application fonctionne et qu'Istio injecte les proxys side-car à chaque pod.

Si vous disposez déjà de clusters avec des applications, vous pouvez ignorer la création d'un espace de noms et le déploiement d'Online Boutique. Vous pouvez suivre le même processus pour tous les espaces de noms dans la section Installer Anthos Service Mesh et préparer les charges de travail.

  1. Déployez Online Boutique sur le cluster GKE :

    kpt pkg get \
    https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
    online-boutique
    
    kubectl --context=${CLUSTER_CTX} create namespace online-boutique
    kubectl --context=${CLUSTER_CTX} label namespace online-boutique istio-injection=enabled
    
    kubectl --context=${CLUSTER_CTX} -n online-boutique apply -f online-boutique
    
  2. Attendez que tous les déploiements soient prêts :

    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice
    
  3. Assurez-vous qu'il existe deux conteneurs par pod : le conteneur d'applications et le proxy side-car Istio qu'Istio injecte automatiquement dans le pod :

    kubectl --context=${CLUSTER_CTX} -n online-boutique get pods
    

    Le résultat ressemble à ce qui suit :

    NAME                                     READY   STATUS    RESTARTS   AGE
    adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
    cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
    checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
    currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
    emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
    frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
    loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
    paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
    productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
    recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
    redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
    shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s
    
  4. Vous pouvez également vérifier la version du proxy Envoy side-car de l'un des pods pour confirmer que vous avez déployé des proxys Envoy Istio version 1.4 :

    export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_CTX} -o jsonpath='{.items[0].metadata.name}')
    kubectl --context=${CLUSTER_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'
    

    Le résultat ressemble à ce qui suit :

    "docker.io/istio/proxyv2:1.7.4"
    "gcr.io/google-samples/microservices-demo/frontend:v0.3.4"
    
  5. Accédez à l'application en accédant à l'adresse IP de l'adresse IP du service istio-ingressgateway :

    kubectl --context=${CLUSTER_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
    

Étape suivante