Exécuter votre migration avec le déploiement du maillage de services Istio

Last reviewed 2023-11-02 UTC

Ce document explique comment initialiser et configurer un maillage de services pour effectuer une migration fonctionnalité par fonctionnalité d'un centre de données sur site vers Google Cloud. Nous partons du principe que vous connaissez l'architecture de référence associée. Ce document est destiné aux administrateurs, aux développeurs et aux ingénieurs qui souhaitent utiliser un maillage de services pour le routage dynamique du trafic vers l'environnement source ou vers Google Cloud.

L'objectif de ce guide de déploiement est de vous aider à migrer d'un environnement non-Google Cloud (tel qu'un centre de données sur site ou un autre fournisseur cloud) vers Google Cloud. Ces migrations impliquent un certain niveau de complexité réseau, car vous devez configurer un canal de communication sécurisé entre l'environnement non-Google Cloud et celui de Google Cloud.

Architecture

Le schéma suivant montre comment utiliser un maillage de services pour acheminer le trafic vers des microservices s'exécutant dans l'environnement source ou vers Google Cloud :

Architecture utilisant un maillage de services permettant d'acheminer le trafic vers des microservices s'exécutant dans l'ancien environnement ou vers Google Cloud.

Dans le schéma, la passerelle Istio fournit un maillage de services qui associe les microservices d'une application. Google Kubernetes Engine (GKE) agit comme un conteneur afin de définir les limites de chaque microservice. Pour en savoir plus, consultez la page Faciliter votre migration avec le déploiement du maillage de services Istio.

Dans ce déploiement, vous utiliserez les logiciels suivants :

Ubuntu Server et Container-Optimized OS : systèmes d'exploitation utilisés dans ce déploiement
Docker Engine : plate-forme pour exécuter des charges de travail en conteneurs
Docker Compose : outil pour définir et exécuter des applications Docker
Istio : maillage de services Open Source
Kiali : outil pour visualiser les maillages de services Istio
Envoy : proxy side-car utilisé par Istio pour inclure des services dans le maillage

Exemple de charge de travail

Dans ce déploiement, vous utilisez l'application Bookinfo, une application de microservices polyglotte à quatre niveaux qui présente des informations sur des livres. Cette application est conçue pour être exécutée sur Kubernetes, mais vous devez la déployer sur une instance Compute Engine à l'aide de Docker et Docker Compose. Avec Docker Compose, vous décrivez des applications multiconteneurs à l'aide de descripteurs YAML. Vous pouvez ensuite démarrer l'application en exécutant une seule commande.

Bien que cet exemple de charge de travail soit déjà conteneurisé, cette approche s'applique également aux services qui ne sont pas conteneurisés. Dans de tels cas, vous pouvez ajouter une phase de modernisation au cours de laquelle vous conteneurisez les services que vous souhaitez migrer.

L'application Bookinfo comporte quatre composants de microservices :

productpage : appelle les microservices details, ratings et reviews pour remplir la page d'informations sur les livres.
details : diffuse des informations sur les livres.
reviews : contient des critiques de livres.
ratings : renvoie les informations de classement des livres pour accompagner une critique de livre.

Pour illustrer Istio et ses fonctionnalités, les auteurs et les responsables de l'application Bookinfo ont mis en œuvre plusieurs versions de certains de ces composants. Dans ce déploiement, vous ne déployez qu'une seule version de chaque composant.

Objectifs

Initialiser un environnement qui simule le centre de données sur site
Déployer et tester des exemples de charges de travail sur le centre de données sur site
Configurer l'environnement cible sur Google Cloud
Migrer la charge de travail du centre de données sur site vers l'environnement cible
Tester les charges de travail s'exécutant dans l'environnement cible
Supprimer le centre de données sur site

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Préparer votre environnement

Vous effectuerez la plupart des étapes de ce déploiement dans Cloud Shell.

Dans la console Google Cloud, activez Cloud Shell.

Activer Cloud Shell

En bas de la fenêtre 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.
Dans Cloud Shell, vérifiez la quantité d'espace libre dont vous disposez :
```
df -h
```
Pour effectuer ce déploiement, vous devez disposer d'environ 200 Mo d'espace libre.
Passez au répertoire de travail ${HOME} :
```
cd "${HOME}"
```
Clonez le dépôt Git contenant les scripts et les fichiers manifestes pour déployer et configurer l'exemple de charge de travail :
```
git clone https://github.com/GoogleCloudPlatform/solutions-istio-mesh-expansion-migration
```
Authentifiez-vous avec les identifiants par défaut de l'application :
```
gcloud auth application-default login
```
Le résultat indique le chemin d'accès au fichier Application Default Credentials :
```
Credentials saved to file:
[/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
```
Notez le chemin d'accès au fichier Application Default Credentials. Ces identifiants seront utilisés par toute bibliothèque demandant les identifiants par défaut de l'application.
Initialisez les variables d'environnement :
```
APPLICATION_DEFAULT_CREDENTIALS_PATH=APPLICATION_DEFAULT_CREDENTIALS_PATH
BILLING_ACCOUNT_ID=BILLING_ACCOUNT_ID
DEFAULT_FOLDER=DEFAULT_FOLDER
DEFAULT_PROJECT=DEFAULT_PROJECT
DEFAULT_REGION=DEFAULT_REGION
DEFAULT_ZONE=DEFAULT_ZONE
GKE_CLUSTER_NAME=istio-migration
DEPLOYMENT_DIRECTORY_PATH="$(pwd)"/solutions-istio-mesh-expansion-migration
ORGANIZATION_ID=ORGANIZATION_ID
```
Remplacez les éléments suivants :
- APPLICATION_DEFAULT_CREDENTIALS_PATH : chemin d'accès au fichier ADC de l'étape précédente.
- BILLING_ACCOUNT_ID : ID du compte de facturation à utiliser.
- DEFAULT_FOLDER : ID du dossier Google Cloud dans lequel créer le projet Google Cloud. Si vous souhaitez que Terraform crée le projet Google Cloud directement sous l'organisation Google Cloud, laissez cette chaîne vide.
- DEFAULT_PROJECT : ID du projet Google Cloud permettant de provisionner les ressources nécessaires à la réalisation de ce déploiement. Terraform crée ce projet pour vous lorsqu'il provisionne l'environnement.
- DEFAULT_REGION : région par défaut où les ressources sont provisionnées.
- DEFAULT_ZONE : zone par défaut où les ressources sont provisionnées.
- ORGANIZATION_ID : ID de votre organisation Google Cloud.

Provisionner vos environnements

Dans cette section, vous provisionnez les environnements suivants pour ce déploiement :

Un environnement qui simule le centre de données source sur site
Environnement qui simule la cible de migration

Dans ce déploiement, les deux environnements sont exécutés dans Google Cloud. Cette approche permet de simplifier le processus de configuration, car il n'existe qu'une seule phase d'amorçage. Vous provisionnez automatiquement les environnements source et cible à l'aide de Terraform.

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```

Initialisez la configuration du backend Terraform :

scripts/init.sh \
--application-credentials "${APPLICATION_DEFAULT_CREDENTIALS_PATH}" \
--billing-account-id "${BILLING_ACCOUNT_ID}" \
--default-folder "${DEFAULT_FOLDER}" \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--organization-id "${ORGANIZATION_ID}"

Le script init.sh a les effets suivants :

Il génère les descripteurs pour configurer le backend Terraform.
Il initialise le répertoire de travail Terraform.

Passez au répertoire de travail terraform :

cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform

Appliquez les modifications avec Terraform :
```
terraform apply
```
Lorsque vous y êtes invité, consultez les modifications proposées et confirmez en renseignant yes.

Le résultat ressemble à ce qui suit :
```
Apply complete! Resources: 27 added, 0 changed, 0 destroyed
```

En appliquant les modifications proposées avec Terraform, vous automatisez les tâches suivantes :

Créer des règles de pare-feu pour autoriser l'accès externe aux microservices et aux communications de la base de données et entre les nœuds.
Créez et activez un compte de service que les instances Compute Engine utiliseront. Nous vous recommandons de limiter le compte de service aux seuls rôles et aux seules autorisations d'accès nécessaires à l'exécution de l'application. Dans le cadre de ce déploiement, le compte de service pour les instances Compute Engine ne nécessite que le rôle de lecteur Compute (roles/compute.viewer). Ce rôle fournit un accès en lecture seule aux ressources Compute Engine.
Provisionner et configurer une instance Compute Engine afin d'héberger les charges de travail à migrer en tant qu'environnement source Lorsque vous configurez l'instance Compute Engine, vous fournissez un script de démarrage qui installe Docker, Docker Compose et Dnsmasq.
Créer et activer un compte de service pour que le cluster GKE héberge les charges de travail en tant qu'environnement cible Dans ce déploiement, vous allez créer un compte de service qui sera utilisé par les nœuds du cluster GKE. Nous vous recommandons de limiter le compte de service aux seuls rôles et aux seules autorisations d'accès nécessaires à l'exécution de l'application. Pour ce déploiement, les rôles requis pour le compte de service pour les nœuds de cluster GKE sont les suivants :
- Lecteur Monitoring (roles/monitoring.viewer)
- Rédacteur de métriques Monitoring (roles/monitoring.metricWriter)
- Rédacteur de journaux (roles/logging.logWriter), comme décrit sur la page Renforcer la sécurité d'un cluster.
Provisionner et configurer un cluster GKE pour héberger les charges de travail en tant qu'environnement cible. Pour provisionner les clusters GKE, Terraform utilise le module Terraform kubernetes-engine.

Déployer la charge de travail sur l'environnement source

Dans ce déploiement, vous allez déployer l'application Bookinfo Istio en tant que charge de travail à migrer. Le schéma suivant illustre l'architecture de l'environnement source :

Architecture cible pour l'environnement source

Dans le schéma, les clients accèdent à l'exemple de charge de travail exécuté sur Compute Engine. Pour réduire la complexité de cet exemple, les clients se connectent directement à une seule instance Compute Engine. Dans un environnement de production, cette connexion directe est peu probable, car vous avez besoin d'une couche d'équilibrage de charge pour exécuter plusieurs instances d'une charge de travail.

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Déployez les charges de travail dans les instances Compute Engine :
```
scripts/workloads.sh \
--deploy-with "COMPOSE" \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}"
```
Le script workloads.sh a les effets suivants :
- Il configure le projet, la région et la zone par défaut.
- Il copie les descripteurs Docker Compose dans les instances Compute Engine.
- Il déploie l'exemple de charge de travail à l'aide de Docker Compose.
Si vous n'avez pas créé de fichier de clé SSH pour vous authentifier auprès des instances Compute Engine, gcloud CLI vous invite à en générer un.

Le résultat affiche une confirmation du déploiement et indique comment y accéder. Le résultat ressemble à ce qui suit :
```
You can access the workload by loading http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
```
Dans le résultat, COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP correspond à l'adresse IP où la charge de travail est diffusée. Notez l'adresse IP, car vous l'utiliserez dans une étape ultérieure.

Tester le déploiement sur l'environnement source

Ouvrez un navigateur et accédez à l'URL suivante, où COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP correspond à l'adresse IP de l'étape précédente :
```
http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
```

Une page Bookinfo s'affiche avec des détails sur les livres et les évaluations correspondantes :

Configurer Istio

Dans cette section, vous allez configurer l'environnement cible dans Google Cloud en installant Istio, puis utiliser Istio pour exposer l'exemple de charge de travail. Le schéma suivant illustre l'architecture de l'environnement cible :

Environnement de destination avec Istio installé

Dans le schéma, Istio expose la charge de travail exécutée dans Compute Engine.

Installer Istio

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Installez Istio :
```
scripts/install-istio.sh \
--cluster-name "${GKE_CLUSTER_NAME}" \
--google-cloud-project "${DEFAULT_PROJECT}" \
--cluster-region "${DEFAULT_REGION}"
```
Le script install-istio.sh a les effets suivants :
- Il télécharge la distribution Istio.
- Il installe Istio dans le cluster GKE de l'environnement cible.
- Il déploie une passerelle pour exposer les services du maillage de services.
- Il configure Istio pour autoriser l'expansion du maillage de services aux instances Compute Engine qui simulent l'environnement source.
- Il installe des outils de surveillance et de visualisation du maillage de services, tels que Kiali.
À la fin de cette commande, la console affiche une confirmation d'installation. Le résultat ressemble à ce qui suit :
```
✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Egress gateways installed
✔ Installation complete
```

Configurer l'expansion du maillage Istio

Dans cette section, vous allez connecter l'instance Compute Engine qui simule l'environnement source au maillage de services. Le maillage de services gère la connexion des microservices de l'ancien environnement qui sera transféré vers l'environnement cible. Dans cette phase, le maillage de services est vide, en attente de l'enregistrement des services. Le maillage de services ne reçoit pas encore de trafic de production.

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Installez et configurez Istio sur l'instance Compute Engine :
```
scripts/compute-engine-mesh-expansion-setup.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}"
```
Le script compute-engine-mesh-expansion-setup.sh a les effets suivants :
- Il installe Istio sur les instances Compute Engine de l'environnement source.
- Il démarre le service Istio sur les instances Compute Engine.

Exposer la charge de travail

Dans cette section, vous allez enregistrer les charges de travail exécutées dans l'instance Compute Engine et simuler l'environnement source dans le maillage de services Istio.

Le script workloads.sh que vous exécutez dans cette section configure des règles de routage pour répartir le trafic de production entre les services exécutés dans l'ancien environnement et ceux exécutés dans l'environnement cible, à l'aide du maillage de services. Comme le routage du trafic à l'intérieur du maillage de services est transparent pour les clients, ils ne savent pas que la configuration du routage a changé.

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```

Exposez les charges de travail :

scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--expose-with "ISTIO_COMPUTE_ENGINE"

Le script workloads.sh a les effets suivants :
- Il configure le projet, la région et la zone par défaut.
- Il active l'injection side-car automatique afin d'éviter les modifications manuelles de vos descripteurs de déploiement.
- Il enregistre les charges de travail exécutées dans l'instance Compute Engine dans le maillage en configurant le point de terminaison WorkloadEntry et les services correspondants.
- Il déploie ServiceEntries pour autoriser le trafic vers le serveur de métadonnées Compute Engine et vers des API Cloud.
- Il déploie les services virtuels pour acheminer le trafic de la passerelle Istio vers l'instance productpage exécutée dans l'instance Compute Engine.
Le résultat affiche une confirmation du déploiement et indique comment y accéder. Le résultat ressemble à ce qui suit :
```
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```
Dans le résultat, ISTIO_INGRESS_GATEWAY_EXTERNAL_IP correspond à l'adresse IP où la charge de travail est diffusée. Notez l'adresse IP, car vous l'utiliserez dans une étape ultérieure.

Tester l'expansion du maillage Istio

Dans cette section, vous allez tester l'exemple de charge de travail exécuté dans l'instance Compute Engine que vous avez utilisée pour exposer Istio.

Ouvrez un navigateur et accédez à l'URL suivante, où ISTIO_INGRESS_GATEWAY_EXTERNAL_IP correspond à l'adresse IP de l'étape précédente :
```
http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```

Le point d'entrée de l'environnement source (qui se connecte à l'instance Compute Engine) est toujours disponible à ce stade. Lorsque vous migrez un environnement de production, nous vous recommandons de rediriger progressivement le trafic vers l'environnement cible en mettant à jour la configuration de la couche d'équilibrage de charge.

Visualiser le maillage de services

Dans cette section, vous utilisez Kiali pour afficher une représentation visuelle du maillage de services.

Ouvrez un navigateur et accédez à l'URL suivante, où ISTIO_INGRESS_GATEWAY_EXTERNAL_IP correspond à l'adresse IP de l'étape précédente :

http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre

Le tableau de bord des services Kiali s'affiche.

Dans Cloud Shell, exécutez une requête plusieurs fois pour la page principale de l'exemple de charge de travail :
```
ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"

for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
```
La requête génère du trafic vers l'application Bookinfo. Le résultat affiche la liste des horodatages de chaque requête HTTP adressée au service productpage, ainsi que le code de retour HTTP de chaque requête (200 dans ce cas).

Le résultat ressemble à ce qui suit :
```
2021-06-09T10:16:15,355323181+00:00 - 200
2021-06-09T10:16:15,355323182+00:00 - 200
2021-06-09T10:16:15,355323183+00:00 - 200
[...]
```
L'exécution de la requête prend du temps. Vous pouvez donc la laisser s'exécuter et passer à l'étape suivante.
Dans le tableau de bord des services Kiali, vous voyez un schéma du maillage actuel, avec le trafic acheminé vers des services exécutés dans Compute Engine. Tout le trafic est acheminé du microservice istio-ingressgateway au microservice productpage qui s'exécute sur l'instance Compute Engine avec le libellé de version compute-engine, et vers le service kiali pour visualiser le maillage de services.

Vous ne voyez pas les autres services dans le graphique (details, reviews et ratings), car le microservice productpage qui s'exécute dans Compute Engine se connecte directement au service d'autres microservices s'exécutant dans Compute Engine. Le microservice productpage ne passe pas par le maillage de services.

Si vous souhaitez que tout le trafic passe par le maillage de services, vous devez reconfigurer les charges de travail exécutées dans Compute Engine pour qu'elles pointent vers les services du maillage de services, au lieu de s'y connecter directement.

Si vous ne voyez pas le schéma suivant sur le tableau de bord Kiali, actualisez la page.

Le schéma du tableau de bord Kiali montre que le trafic est acheminé vers des services exécutés dans Compute Engine.
Dans Cloud Shell, appuyez sur Control+C pour arrêter la commande de génération de trafic.

Migrer la charge de travail

Dans cette section, vous migrez les composants de l'exemple de charge de travail des instances Compute Engine vers le cluster GKE. Pour chaque microservice de l'exemple de charge de travail, procédez comme suit :

Déployez une instance du microservice dans le cluster GKE.
Commencez à acheminer le trafic vers les instances de microservices exécutées dans Compute Engine et dans GKE.

Le schéma suivant montre l'architecture du système pour cette section :

Architecture cible avec trafic acheminé vers des instances de microservices dans Compute Engine et GKE

Dans le schéma, Cloud Load Balancing achemine le trafic vers la passerelle Istio, puis Istio achemine le trafic vers des services exécutés dans Compute Engine ou vers des services exécutés dans GKE.

Pour migrer les composants de l'exemple de charge de travail, procédez comme suit :

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Déployez les charges de travail dans l'environnement cible :
```
scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--deploy-with "GKE"
```
Le script workloads.sh a les effets suivants :
- Il active l'injection side-car automatique afin d'éviter les modifications manuelles de vos descripteurs de déploiement.
- Il déploie les comptes de service et les déploiements pour exécuter les exemples de charges de travail dans le cluster GKE.
Une confirmation du déploiement s'affiche, ainsi que des instructions pour y accéder. Le résultat ressemble à ce qui suit :
```
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```

Le maillage de services achemine le trafic vers les exemples de charges de travail exécutés dans les instances Compute Engine et vers les exemples exécutés dans le cluster GKE.

Tester la charge de travail exécutée dans Compute Engine et GKE

Dans cette section, vous allez tester l'exemple de charge de travail que vous avez déployé dans Compute Engine et GKE.

Ouvrez un navigateur et accédez à l'URL suivante, où ISTIO_INGRESS_GATEWAY_EXTERNAL_IP correspond à l'adresse IP de l'étape précédente :
```
http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```
Une page Bookinfo s'affiche avec des informations sur les livres et les évaluations correspondantes :

Étant donné que vous avez déployé la même version de l'exemple de charge de travail dans Compute Engine et dans le cluster GKE, le résultat ressemble à celui du test précédent.

Visualiser le maillage de services

Dans cette section, vous utilisez Kiali pour afficher une représentation visuelle du maillage de services.

Ouvrez un navigateur et accédez à l'URL suivante, où ISTIO_INGRESS_GATEWAY_EXTERNAL_IP correspond à l'adresse IP de l'étape précédente :

http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre

Dans Cloud Shell, exécutez une requête plusieurs fois pour la page principale de l'exemple de charge de travail :

ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done

La commande génère du trafic vers l'application Bookinfo. Le résultat attendu est une liste de la date de la requête HTTP adressée au service productpage, ainsi que le code de retour HTTP de chaque requête (200 OK dans ce cas). Le résultat ressemble à ce qui suit :

2021-06-09T10:16:15,355323181+00:00 - 200
2021-06-09T10:16:15,355323182+00:00 - 200
2021-06-09T10:16:15,355323183+00:00 - 200
[...]

Dans le tableau de bord des services Kiali, vous voyez un schéma du maillage actuel, avec le trafic acheminé vers des services exécutés dans Compute Engine et GKE.

Chaque instance de microservice possède une étiquette pour expliquer sa révision :
- Les instances exécutées dans Compute Engine ont le libellé compute-engine.
- Les instances exécutées dans GKE disposent d'une chaîne supplémentaire, par exemple v1 ou v3.
Les instances exécutant Compute Engine se connectent directement aux autres instances dans Compute Engine et ne passent pas par le maillage de services. Par conséquent, vous ne voyez pas le trafic provenant des instances exécutées dans Compute Engine vers d'autres instances.

Si vous ne voyez pas le schéma suivant sur le tableau de bord Kiali, actualisez la page.

Le schéma du tableau de bord Kiali montre le trafic acheminé vers des services exécutés dans Compute Engine et vers des services exécutés dans GKE.
Dans Cloud Shell, appuyez sur Control+C pour arrêter la commande de génération de trafic.

Acheminer le trafic vers le cluster GKE uniquement

Dans cette section, vous allez acheminer le trafic vers les instances de service de charge de travail qui ne s'exécutent que dans le cluster GKE. Pour chaque service de l'exemple de charge de travail, vous supprimez la référence WorkloadEntry qui pointe vers le service exécuté dans Compute Engine. La suppression force le service à ne sélectionner que les instances de microservices exécutés dans le cluster GKE et le trafic n'est acheminé que vers le cluster GKE. Le schéma suivant montre l'architecture du système pour cette section :

Architecture cible avec trafic acheminé vers le cluster GKE

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```
Exposez les charges de travail uniquement dans l'environnement cible :
```
scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--expose-with "GKE_ONLY"
```
Le script workloads.sh supprime les références WorkloadEntry qui pointent vers les instances de microservices exécutées dans Compute Engine à partir du cluster GKE.

Une confirmation du déploiement s'affiche, ainsi que des instructions pour y accéder. Le résultat ressemble à ce qui suit :
```
You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```

L'entrée de service utilise workloadSelector pour sélectionner automatiquement l'exemple de charge de travail exécuté dans le cluster GKE.

Tester la charge de travail exécutée dans GKE

Ouvrez un navigateur et accédez à l'URL suivante, où ISTIO_INGRESS_GATEWAY_EXTERNAL_IP correspond à l'adresse IP de l'étape précédente :
```
http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
```
Une page Bookinfo s'affiche avec des informations sur les livres et les évaluations correspondantes :

Visualiser le maillage de services

Dans cette section, vous utilisez Kiali pour afficher une représentation visuelle du maillage de services.

Ouvrez un navigateur et accédez à l'URL suivante, où ISTIO_INGRESS_GATEWAY_EXTERNAL_IP correspond à l'adresse IP de l'étape précédente :

http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre

Dans Cloud Shell, exécutez une requête plusieurs fois pour la page principale de l'exemple de charge de travail :

ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done

Cette commande génère du trafic vers l'application Bookinfo. Le résultat attendu est une liste de la date de la requête HTTP adressée au service productpage, ainsi que le code de retour HTTP de chaque requête (200 OK dans ce cas). Le résultat ressemble à ce qui suit :

2021-06-09T10:16:15,355323181+00:00 - 200
2021-06-09T10:16:15,355323182+00:00 - 200
2021-06-09T10:16:15,355323183+00:00 - 200
[...]

Le tableau de bord des services Kiali affiche un schéma du maillage actuel avec le trafic acheminé vers des services exécutés dans GKE. Vous avez déployé deux instances de chaque microservice : l'une exécutée dans l'instance Compute Engine et l'autre dans le cluster GKE. Toutefois, étant donné que vous avez supprimé les références WorkloadEntry qui pointent vers les instances de microservices exécutées dans Compute Engine, les services ne sélectionnent que les instances de microservices exécutées dans le cluster GKE.

Si vous ne voyez pas le schéma suivant sur le tableau de bord Kiali, actualisez la page.

Le schéma du tableau de bord Kiali montre le trafic acheminé vers des services exécutés dans GKE.
Dans Cloud Shell, appuyez sur Control+C pour arrêter la commande de génération de trafic.

Supprimer l'environnement source

Étant donné que l'ensemble du trafic est désormais acheminé vers le cluster GKE, vous pouvez arrêter les instances de la charge de travail exécutées dans Compute Engine.

Lors d'une migration de production, gardez le centre de données source prêt pour votre stratégie de rollback. Nous vous recommandons de ne commencer à supprimer le centre de données source que lorsque vous êtes sûr que la nouvelle solution fonctionne comme prévu et que tous les mécanismes de sauvegarde et de tolérance aux pannes sont en place.

Le schéma suivant montre l'architecture du système pour cette section :

Environnement source sans instance de charge de travail s'exécutant dans Compute Engine.

Dans le schéma, Istio achemine le trafic vers des services qui ne s'exécutent que dans GKE, et les charges de travail exécutées dans Compute Engine sont supprimées.

Pour supprimer l'environnement source, procédez comme suit :

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"
```

Exposez les charges de travail uniquement dans l'environnement cible :

scripts/workloads.sh \
--default-project "${DEFAULT_PROJECT}" \
--default-region "${DEFAULT_REGION}" \
--default-zone "${DEFAULT_ZONE}" \
--deploy-with "GKE_ONLY"

Le script workloads.sh arrête les conteneurs s'exécutant dans les instances Compute Engine.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans le cadre de ce déploiement soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimer le projet

Attention : La suppression d'un projet aura les effets suivants :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches de ce document, lorsque vous le supprimez, vous supprimez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

Dans la console Google Cloud, accédez à la page Gérer les ressources.
Accéder à la page Gérer les ressources
Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer les ressources individuelles

Dans Cloud Shell, définissez le répertoire de travail sur le répertoire de dépôt :
```
cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
```
Supprimez les ressources que vous avez provisionnées :
```
terraform destroy -auto-approve
```

Étapes suivantes

Apprenez-en plus sur GKE.
Découvrez Istio.
Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.