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 la console Google Cloud.
Si vous disposez d'une ressource
IstioOperatorpersonnalisé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.
Activez les API Google Cloud suivantes :
container.googleapis.commeshca.googleapis.commeshconfig.googleapis.comgkehub.googleapis.comstackdriver.googleapis.com
Activez Workload Identity et Stackdriver pour votre cluster GKE.
Ajoutez un libellé à votre cluster pour activer l'interface utilisateur du service.
Obtenez des droits d'administrateur sur le cluster Kubernetes.
Enregistrer un cluster dans un parc.
Activez la fonctionnalité
servicemeshsur le parc.
Configurer votre environnement
Pour configurer votre environnement, procédez comme suit :
Dans la console Google Cloud, activez Cloud Shell.
En bas de la page de la console Google Cloud, 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.
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_ZONECréer un dossier
WORKDIRmkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`
Créez un fichier
KUBECONFIGpour ce guide :touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
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}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 :
- Effectuez une étape de pré-migration pour valider et préparer le cluster et l'environnement pour la migration vers Anthos Service Mesh.
- 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
- Tester des charges de travail sur Anthos Service Mesh et étiqueter les espaces de noms pour l'injection side-car Anthos Service Mesh
- Accéder aux tableaux de bord Anthos Service Mesh et les inspecter
- 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-dependenciesest 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_backupet, 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 ressourceIstioOperator, 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
IstioOperatorpersonnalisé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 passerelleistio-ingressgatewaypar défaut.Option 2 : avec une option
--no-gateways. Lorsque vous installez Anthos Service Mesh sans ressourceIstioOperatorpersonnalisée, vous pouvez également utiliser l'option--no-gatewayspour ne pas mettre à jour la valeuristio-ingressgatewaypar défaut. Si vous utilisez cette option, vous devez mettre à niveau les passerelles manuellement après l'installation.Option 3 : Avec une ressource
IstioOperatorpersonnalisée Vous pouvez installer Anthos Service Mesh avec une ressourceIstioOperatorpersonnalisée. Si vous avez déployé Istio à l'aide d'une ressourceIstioOperatorpersonnalisée, nous vous recommandons d'utiliser la même ressourceIstioOperatorlors 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 :
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_IDLe 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!
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)
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.
Dans la console Google Cloud, accédez à la page Anthos Service Mesh.
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 la console Google Cloud.
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.
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.5Cré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-autoscalingClusters 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-autoscalingConfirmez 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
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.
Télécharger Istio
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -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
IstioOperatorpersonnalisée
Option 1
Sans ressource
IstioOperatorpersonnalisée :./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -yLe résultat ressemble à ce qui suit :
✔ Istio core installed ✔ Istiod installed ✔ Ingress gateways installed ✔ Installation complete
Option 2
Avec une ressource
IstioOperatorpersonnalisé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 -yLe résultat ressemble à ce qui suit :
✔ Istio core installed ✔ Istiod installed ✔ Ingress gateways installed ✔ Installation complete
- Option 1 : sans ressource personnalisée
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,podsLe résultat ressemble à ce qui suit :
Option 1
Sans ressource
IstioOperatorpersonnalisé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
IstioOperatorpersonnalisé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.
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-boutiqueAttendez 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 recommendationserviceAssurez-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 podsLe 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
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"
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}'
Étapes suivantes
- 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.