Anthos Service Mesh 1.9 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 :

Versions disponibles

Ajouter des machines virtuelles Compute Engine à Anthos Service Mesh

Introduction

Anthos Service Mesh vous permet de gérer, d'observer et de sécuriser les services exécutés sur des groupes d'instances gérés (MIG) avec des services s'exécutant sur des clusters Google Kubernetes Engine (GKE) dans le maillage. Cela vous permet d'effectuer les opérations suivantes avec les instances Compute Engine de votre maillage :

Gérer le trafic
Appliquer mTLS
Appliquer un contrôle d'accès au trafic de service
Accéder en toute sécurité aux services Google Cloud
Collecter des métriques, des journaux et des données de traçage
Surveiller les services à l'aide de la console Google Cloud

Cela permet aux anciennes applications non adaptées ou pas prêtes pour la conteneurisation de tirer parti des fonctionnalités d'Anthos Service Mesh. Cela permet également d'intégrer ces charges de travail au reste de vos services.

Fonctionnement

ASM fournit deux définitions de ressources personnalisées (CRD, Custom Resource Definition) pour représenter les charges de travail des machines virtuelles :

WorkloadGroup représente un groupe logique de charges de travail de machines virtuelles partageant des propriétés communes. Cette méthode s'apparente à un déploiement dans Kubernetes.
WorkloadEntry représente une instance unique d'une charge de travail de machine virtuelle. Cet objet s'apparente à un pod dans Kubernetes.
Un Service peut ensuite sélectionner le WorkloadGroup et acheminer le trafic ASM vers l'instance de VM de la même manière que vers Pod. Cela permet à la VM d'agir comme n'importe quelle autre charge de travail dans le réseau maillé.

Vous créez un modèle d'instance Compute Engine pour chaque groupe d'instances Compute Engine, qui spécifie un agent proxy de service pour chaque instance Compute Engine de ce groupe. Lors de l'installation, l'agent amorçage du proxy de service, configure l'interception du trafic et surveille l'état du proxy de service pendant la durée de vie de l'instance Compute Engine. Le proxy se connecte au plan de contrôle Anthos Service Mesh, puis enregistre automatiquement chaque instance Compute Engine en tant que WorkloadEntry pour le WorkloadGroup correspondant. Cela permet à Anthos Service Mesh de traiter chaque instance comme un point de terminaison de service, tel que les pods Kubernetes du cluster. Vous pouvez également créer des services Kubernetes pour les charges de travail de VM, comme vous le feriez pour les pods Kubernetes.

Pour augmenter ou diminuer le nombre de charges de travail sur les instances Compute Engine, à partir d'une taille de groupe d'instances géré minimale de zéro, consultez la page Autoscaling des groupes d'instances.

L'agent proxy de service s'appuie sur VM Manager pour s'assurer de l'installation de l'agent dans chaque VM du groupe d'instances géré. Pour en savoir plus sur les groupes d'instances et la gestion des VM, consultez les pages Groupe d'instances géré (MIG) et VM Manager.

Distributions Linux compatibles

Version d'OS	Assistance
Debian 10
Debian 9
Centos 8
Centos 7

Pour plus d'informations sur les distributions du système d'exploitation, consultez l'assistance Debian ou l'assistance CentOS.

Limites

Le plan de contrôle du maillage doit être Anthos Service Mesh version 1.9 ou ultérieure.
Seuls les groupes d'instances gérés Compute Engine créés à partir d'un modèle d'instance Compute Engine sont acceptés.
Le cluster et les VM doivent se trouver sur le même réseau, dans le même projet et utiliser une seule interface réseau.
Vous pouvez utiliser cette fonctionnalité sans abonnement GKE Enterprise, mais certains éléments d'interface utilisateur et certaines fonctionnalités de la console Google Cloud ne sont disponibles que pour les abonnés GKE Enterprise. Pour en savoir plus sur les fonctionnalités disponibles pour les abonnés et les non-abonnés, consultez la section Différences entre les interfaces utilisateur de GKE Enterprise et d'Anthos Service Mesh.

Prérequis

Avant de commencer, vérifiez les conditions préalables suivantes.

Clusters

Cette page inclut l'option permettant d'installer Anthos Service Mesh dans le cadre de sa procédure ou de mettre à jour un cluster sur lequel Anthos Service Mesh est déjà installé. Dans les deux cas, ces étapes nécessitent Anthos Service Mesh 1.9 et versions ultérieures et un cluster qui répond à ces exigences. La compatibilité d'Anthos Service Mesh présente aussi d'autres exigences :

Le plan de contrôle doit être installé dans un cluster que vous contrôlez. Les plans de contrôle gérés par Google ne sont pas compatibles. Pour plus d'informations, consultez la section Plans de contrôle gérés par Google.
Utilisation de Mesh CA comme autorité de certification.
Utilisation de Stackdriver pour la télémétrie.
Le déploiement du service canonique est activé, ce qui est automatiquement fait par le processus d'installation d'Anthos Service Mesh.

Votre cluster doit être enregistré sur une Fleet. Toutefois, si ce n'est pas déjà fait, le processus d'installation de la VM peut l'enregistrer à votre place dans le projet spécifié.

Si vous êtes abonné à GKE Enterprise, activez l'API GKE Enterprise.

Activer l'API

Outils CLI

Le processus d'installation nécessite les outils suivants, qui sont déjà installés si vous utilisez Google Cloud Shell :

gcloud
kubectl
kpt
curl
jq
awk
printf
tr
grep
tail

Télécharger le script

Cette section explique comment télécharger le script pour l'intégration de VM.

Téléchargez le script de VM pour Anthos Service Mesh 1.9.8 dans le répertoire de travail actuel :
```
curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm
```

Téléchargez le hachage SHA-256 du fichier dans le répertoire de travail actuel :

curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9.sha256 > asm_vm.sha256

Une fois les deux fichiers dans le même répertoire, validez le téléchargement avec la commande suivante :
```
sha256sum -c --ignore-missing asm_vm.sha256
```
Si la validation réussit, la commande affiche le résultat suivant : asm_vm: OK

Pour assurer la compatibilité, le fichier asm_vm.sha256 inclut la somme de contrôle deux fois pour permettre de renommer n'importe quelle version du script en asm_vm. Si vous obtenez une erreur indiquant que --ignore-missing n'existe pas, réexécutez la commande précédente sans l'option --ignore-missing.
Rendez le script exécutable :
```
chmod +x asm_vm
```

Comment en profiter ?

Cette section explique la procédure à suivre pour ajouter des instances Compute Engine à Anthos Service Mesh.

Configurer votre environnement

Utilisez gcloud pour configurer votre outil kubectl afin qu'il pointe vers le cluster que vous avez spécifié, car certaines des étapes ci-dessous nécessitent que vous apportiez des modifications directement sur le cluster.

Remarque : Utilisez --region au lieu de --zone si le cluster est un cluster régional.
```
gcloud container clusters get-credentials CLUSTER_NAME --zone CLUSTER_LOCATION --project PROJECT_ID
```

Préparer votre cluster

Configurez le cluster Anthos Service Mesh pour les VM en préparant le plan de contrôle d'Anthos Service Mesh 1.9 et versions ultérieures.

Choisissez la prochaine étape selon qu'Anthos Service Mesh 1.9 et versions ultérieures est déjà installé sur votre cluster ou non.

Non installé

Si Anthos Service Mesh 1.9 et versions ultérieures n'est pas installé sur votre cluster, l'exemple suivant montre comment ajouter les options vm et hub-meshca pour modifier les étapes d'installation habituelles d'Anthos Service Mesh fournies sur la page Installation, migration et mise à niveau pour GKE. Elle explique également comment télécharger le script install_asm utilisé dans l'exemple suivant.

Après avoir téléchargé le script install_asm, vous pouvez installer Anthos Service Mesh dans votre cluster en ajoutant les options --option hub-meshca, --option vm et --enable_all. Pour en savoir plus, consultez les pages Activer Mesh CA avec la Fleet et Options d'activation.

./install_asm --project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install --option vm --option hub-meshca \
--enable_all

Installés

Si Anthos Service Mesh 1.9 et versions ultérieures est déjà installé sur votre cluster et qu'il a l'autorité de certification Mesh avec le parc activé, mettez à jour le plan de contrôle d'Anthos Service Mesh de sorte qu'il soit compatible avec les charges de travail basées sur des VM. Ce script vous aide également à vérifier si votre installation Anthos Service Mesh dans le cluster est prête pour les charges de travail de VM. Plus précisément, la sous-commande prepare_cluster met à jour toutes les révisions d'Anthos Service Mesh 1.9 et versions ultérieurs pour qu'elles soient prêtes pour les charges de travail de VM.

Si l'option d'autorité de certification Mesh avec le parc n'est pas activée dans votre installation Anthos Service Mesh 1.9 et versions ultérieures, réinstallez ou mettez à niveau votre installation Anthos Service Mesh 1.9 et versions ultérieures en incluant les options --option hub-meshca et --option vm dans le script install_asm.

./asm_vm prepare_cluster \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION

Les étapes précédentes ont réalisé les actions suivantes :

Activez l'enregistrement automatique de VM : pour cela, définissez la variable PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION sur "true". Lorsque cette option est activée, les nouvelles instances de VM sont enregistrées auprès de WorkloadGroup et de nouvelles réponses standardisées WorkloadEntry sont créées pour acheminer le trafic vers les VM. Tous les plans de contrôle d'Anthos Service Mesh 1.9 et versions ultérieures qui sont installés avec install_asm incluent cette valeur par défaut.
Installer une passerelle d'extension : cette passerelle est nommée la passerelle eastwest et définie dans le package de configuration Anthos Service Mesh. Cela exposera également le plan de contrôle aux VM.
Installez la CRD IdentityProvider et enregistrez une réponse standardisée IdentityProvider Google pour permettre aux VM de s'authentifier auprès du plan de contrôle d'Anthos Service Mesh et de communiquer en toute sécurité avec le reste du maillage de services.
Enregistrez le cluster dans une Fleet et activez l'identité de la charge de travail si vous utilisez --enable_all ou --enable_registration dans le script install_asm.
Activer la fonctionnalité Service Mesh dans la Fleet. Cette fonctionnalité gère les règles nécessaires pour permettre aux VM de communiquer en toute sécurité avec le maillage.

Ajouter vos VM

Dans cette section, vous ajoutez des instances Compute Engine à votre réseau maillé en fonction du modèle d'instance que vous créez avec le script asm_vm. Le script génère uniquement la configuration nécessaire à l'agent du proxy de service. Pour inclure davantage de configuration votre modèle d'instance, créez un modèle d'instance source et ajoutez-le au script.

Pour ajouter des VM à votre maillage, procédez comme suit :

Définissez les variables d'environnement suivantes à utiliser lors des prochaines étapes. Définissez ces variables pour chaque charge de travail de VM :
- WORKLOAD_NAME est le nom de la charge de travail dont la VM fait partie, qui doit être un sous-domaine DNS-1123 conforme composé de caractères alphanumériques en minuscules.
- WORKLOAD_VERSION est la version de la charge de travail dont fait partie la VM. Facultatif.
- WORKLOAD_SERVICE_ACCOUNT est le compte de service GCP sur lequel la VM s'exécute.
- WORKLOAD_NAMESPACE est l'espace de noms de la charge de travail.
- ASM_INSTANCE_TEMPLATE est le nom du modèle d'instance à créer. Le nom de modèle d'instance Compute Engine n'autorise pas les traits de soulignement.
- SOURCE_INSTANCE_TEMPLATE est le nom du modèle sur lequel baser le modèle généré. Facultatif.
Créez un espace de noms pour les charges de travail de VM s'il n'existe pas déjà :
```
kubectl create ns WORKLOAD_NAMESPACE
```
Étiquetez l'espace de noms avec la révision du plan de contrôle. Pour obtenir un exemple montrant comment trouver la révision du plan de contrôle indiquée comme REVISION dans l'exemple suivant, consultez la page Déployer et redéployer des charges de travail.
```
kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```

Créez le WorkloadGroup pour que les VM soient enregistrées :

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
 name: WORKLOAD_NAME
 namespace: WORKLOAD_NAMESPACE
spec:
 metadata:
   labels:
     app.kubernetes.io/name: WORKLOAD_NAME
     app.kubernetes.io/version: WORKLOAD_VERSION
   annotations:
     security.cloud.google.com/IdentityProvider: google
 template:
   serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF

Champ	Description
`name`	Nom de la charge de travail dont fait partie la VM.
`namespace`	Espace de noms dont fait partie la charge de travail.
`app.kubernetes.io/name`	Les libellés recommandés pour les applications Kubernetes. Vous pouvez utiliser vos propres libellés pour les charges de travail des VM.
`app.kubernetes.io/version`	Les libellés recommandés pour les applications Kubernetes. Vous pouvez utiliser vos propres libellés pour les charges de travail des VM.
`serviceAccount`	L'identité du compte de service utilisée par la VM et le projet, qui sera utilisée dans le cadre de l'identité de la charge de travail au format SPIFFE. Pour en savoir plus, consultez la page sur les comptes de service.
`security.cloud.google.com/IdentityProvider`	Fournisseur d'identité que la VM utilisera, qui doit déjà être enregistré dans votre cluster. Vous devez définir `google` sur les VM Compute Engine. "IdentityProvider" indique au plan de contrôle comment authentifier les identifiants de la VM et où extraire le compte de service de la VM.

Exécutez le script asm_vm avec les options suivantes pour créer un modèle d'instance pour vos instances Anthos Service Mesh Compute Engine.

Ce script vérifie les conditions préalables du cluster, ajoute des libellés de VM pour Anthos Service Mesh, génère la configuration de métadonnées personnalisée pour l'agent du proxy de service et crée un modèle d'instance.

Si vous disposez d'un modèle d'instance sur lequel vous souhaitez baser le script, vous pouvez spécifier l'option --source_instance_template. Si vous souhaitez ajouter des VM autres que celles par défaut à votre service Anthos Service Mesh, créez un modèle d'instance avec la distribution du système d'exploitation prévue et utilisez ce modèle comme valeur de l'option --source_instance_template dans le script asm_vm. Si votre modèle d'instance existant inclut un script de démarrage qui nécessite une connectivité réseau, celui-ci doit être résilient aux problèmes temporaires de connectivité réseau. Consultez l'application de démonstration pour obtenir un exemple de méthode de résilience face à des interruptions de réseau temporaires.

./asm_vm create_gce_instance_template \
ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE

Options

Option	Description
`-p\|--project_id PROJECT_ID`	ID du projet dans lequel le cluster a été créé.
`-n\|--cluster_name CLUSTER_NAME`	Nom du cluster.
`-l\|--cluster_location CLUSTER_LOCATION`	Zone (pour les clusters à zone unique) ou région (pour les clusters régionaux) dans laquelle le cluster a été créé.
`-w\|--workload_name WORKLOAD_NAME`	Nom de la charge de travail représentée par les instances Compute Engine.
`--workload_namespace WORKLOAD_NAMESPACE`	Facultatif. Espace de noms de la charge de travail. La valeur par défaut est "default".
`-s\|--source_instance_template SOURCE_INSTANCE_TEMPLATE_NAME`	Facultatif. Modèle d'instance existant à utiliser comme base pour le modèle d'instance Compute Engine pour Anthos Service Mesh. En l'absence de spécification, un modèle d'instance disposant des valeurs par défaut est créé.

Flags

Option	Description
`-v\|--verbose`	Imprime les commandes avant et après l'exécution.
`--dry_run`	Imprime les commandes, mais ne les exécute pas.
`--only_validate`	Exécute la validation sans créer de modèle d'instance Compute Engine.
`-h\|--help`	Affiche un message d'aide décrivant les options, puis ferme.

Définissez les variables d'environnement suivantes pour chaque MIG que vous créez :
- INSTANCE_GROUP_NAME est le nom du groupe d'instances Compute Engine à créer.
- ASM_INSTANCE_TEMPLATE est le nom du modèle d'instance à créer. Le nom de modèle d'instance Compute Engine n'autorise pas les traits de soulignement.
- INSTANCE_GROUP_ZONE est la zone du groupe d'instances Compute Engine à créer.
- PROJECT_ID est l'ID du projet dans lequel le cluster a été créé.
- SIZE est la taille du groupe d'instances à créer. Elle peut être modifiée après la création du groupe d'instances.
- WORKLOAD_NAME est le nom de la charge de travail dont fait partie la VM.
- WORKLOAD_NAMESPACE est l'espace de noms de la charge de travail.
Créez un groupe d'instances géré pour les charges de travail de VM à l'aide des variables créées lors des étapes précédentes :
```
gcloud compute instance-groups managed create \
INSTANCE_GROUP_NAME \
--template ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE \
--project=PROJECT_ID \
--size=SIZE
```
Pour augmenter ou diminuer le nombre de charges de travail sur les instances Compute Engine, à partir d'une taille de MIG zonal ou régionale de zéro, consultez la section Procéder à l'autoscaling de groupes d'instances. Pour en savoir plus sur la création de groupes, consultez la page gcloud compute instance-groups managed create.

Lorsque votre instance démarre, elle s'authentifie automatiquement auprès du plan de contrôle d'Anthos Service Mesh de votre cluster, qui enregistre chaque VM en tant que WorkloadEntry.
Une fois l'instance de VM du MIG démarrée, vous pouvez afficher les VM enregistrées dans l'espace de noms de la charge de travail à l'aide de la commande suivante :
```
   kubectl get workloadentry -n WORKLOAD_NAMESPACE
```
Remarque : Si les ressources personnalisées WorkloadGroup ou IdentityProvider sont supprimées, votre VM ne pourra plus communiquer avec le maillage.
Ajoutez un service Kubernetes pour exposer les charges de travail de VM ajoutées ci-dessus. Assurez-vous que le service sélectionne le libellé correspondant sur la VM WorkloadGroup enregistrée ci-dessus en vue d'un routage approprié du trafic.

L'exemple suivant crée un service Kubernetes nommé WORKLOAD_NAME dans l'espace de noms WORKLOAD_NAMESPACE qui expose les charges de travail de VM avec le libellé app.kubernetes.io/name: WORKLOAD_NAME sous le port HTTP 80.
```
kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
 name: WORKLOAD_NAME
 namespace: WORKLOAD_NAMESPACE
 labels:
   asm_resource_type: VM
spec:
 ports:
 - port: 80
   name: http
 selector:
   app.kubernetes.io/name: WORKLOAD_NAME
EOF
```
Pour en savoir plus sur la création d'un service Kubernetes, consultez la page https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service.
Pour utiliser un exemple d'application sur votre VM, consultez la section Déployer un exemple d'application.

Mise à niveau du plan de contrôle d'Anthos Service Mesh

Mettez à niveau votre plan de contrôle Anthos Service Mesh vers une nouvelle version en suivant les instructions de la page Mettre à niveau Anthos Service Mesh vers la dernière version. Après avoir installé une nouvelle version du plan de contrôle Anthos Service Mesh, redéployez vos charges de travail Kubernetes à l'aide des instructions fournies à la page Déployer et redéployer des charges de travail.

Pour les charges de travail de VM, créez un modèle d'instance et effectuez une mise à jour progressive des VM dans votre MIG :

Exécutez la commande suivante pour localiser le libellé de révision sur istiod :
```
kubectl -n istio-system get pods -l app=istiod --show-labels
```
La sortie de la commande ressemble à ceci : Notez que le résultat de la migration est légèrement différent de celui des mises à niveau. L'exemple de résultat suivant provient d'une migration.
```
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-198-6-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-198-6-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
```
1. Dans le résultat, sous la colonne LABELS, notez la valeur du libellé de révision istiod pour la nouvelle version, à la suite du préfixe istio.io/rev=. Dans cet exemple, la valeur est asm-198-6.
2. Notez également la valeur du libellé de révision pour l'ancienne version de istiod. Vous devrez supprimer l'ancienne version de istiod lorsque vous aurez fini de déplacer les charges de travail vers la nouvelle version. Dans l'exemple de résultat, la valeur du libellé de révision pour l'ancienne version de istiod est default.
Ajoutez le libellé de révision à un espace de noms et supprimez le libellé istio-injection (s'il existe). Dans la commande suivante, remplacez REVISION par la valeur correspondant à la nouvelle révision de istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
Si "istio-injection not found" apparaît dans le résultat, vous pouvez l'ignorer. Cela signifie que l'espace de noms n'avait pas auparavant le libellé istio-injection. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.
Créez un modèle d'instance à l'aide du script asm_vm. Veillez à utiliser un nouveau nom de modèle d'instance et à inclure le même modèle d'instance source, le cas échéant.

Remarque : L'option --source_instance_template est facultative. Si vous disposez d'un modèle source, vous devez l'inclure. Dans le cas contraire, n'incluez pas l'option.
```
./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE
```
Effectuez une mise à jour progressive de votre MIG existant pour la charge de travail.

Pour en savoir plus, consultez la section Lancer une mise à jour progressive de base.
```
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE
```
Testez la charge de travail de la VM pour vous assurer qu'elle fonctionne comme prévu.

Mettre à niveau des applications de VM

Si vous avez des mises à jour de votre application, y compris des modifications apportées à WorkloadGroup et/ou à votre modèle d'instance source, un nouveau modèle d'instance est requis pour mettre à jour le MIG de vos charges de travail de VM.

Lorsque la modification WorkloadGroup est appliquée et/ou le modèle d'instance source est créé, vous créez un modèle d'instance pour Anthos Service Mesh et effectuez une mise à jour progressive sur les VM de votre MIG.

Créez un modèle d'instance à l'aide du script asm_vm. Veillez à utiliser un nouveau nom de modèle d'instance et à inclure le nouveau modèle d'instance source si vous avez créé un modèle pour la mise à jour de votre application.

./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template NEW_SOURCE_INSTANCE_TEMPLATE

Effectuez une mise à jour progressive de votre MIG existant pour la charge de travail. Pour plus d'informations sur l'utilisation de la mise à jour progressive du MIG, consultez la section Lancer une mise à jour progressive de base.
```
gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE
```
Testez la charge de travail de la VM pour vous assurer qu'elle fonctionne comme prévu.

Déploiement d'un exemple d'application

Pour démontrer que votre nouvelle configuration de réseau maillé fonctionne correctement, vous pouvez installer l'exemple d'application Bookinfo. Cet exemple exécute une base de données MySQL sur la VM et le service d'évaluation lit les valeurs d'évaluation de la base de données.

Installer Bookinfo sur le cluster

Procédez comme suit pour déployer les services de l'application Bookinfo avec des proxys side-car injectés avec chaque service. L'application BookInfo sera déployée dans l'espace de noms default.

Sur la ligne de commande de l'ordinateur sur lequel vous avez installé Anthos Service Mesh, accédez à la racine du répertoire d'installation d'Anthos Service Mesh que vous avez créé à l'étape Télécharger le script.

Pour activer l'injection side-car automatique, exécutez la commande suivante pour localiser le libellé sur istiod, qui contient la valeur de libellé de révision à utiliser lors des étapes suivantes.

kubectl -n istio-system get pods -l app=istiod --show-labels

La sortie ressemble à ceci :

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-198-6-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586
istiod-asm-198-6-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586

Dans le résultat, sous la colonne LABELS, notez la valeur du libellé de révision istiod, qui suit le préfixe istio.io/rev=. Dans cet exemple, la valeur est asm-198-6.

Appliquez le libellé de révision à l'espace de noms default. Dans la commande suivante, REVISION correspond à la valeur du libellé de révision istiod que vous avez notée à l'étape précédente.
```
kubectl label namespace default istio-injection- istio.io/rev=REVISION --overwrite
```
Vous pouvez ignorer le message "istio-injection not found" dans le résultat. Cela signifie que l'espace de noms ne portait pas précédemment le libellé istio-injection, auquel on s'attend dans de nouvelles installations d'Anthos Service Mesh ou de nouveaux déploiements. Étant donné que l'injection automatique échoue si un espace de noms possède à la fois le istio-injection et le libellé de révision, toutes les commandes kubectl label de la documentation Anthos Service Mesh incluent la suppression du libellé istio-injection.
Déployez votre application sur l'espace de noms par défaut à l'aide de kubectl :
```
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
```

Confirmez que l'application a été correctement déployée en exécutant les commandes suivantes :

kubectl get services

Résultat attendu :

NAME                       CLUSTER-IP   EXTERNAL-IP   PORT(S)              AGE
details                    10.0.0.31    <none>        9080/TCP             6m
kubernetes                 10.0.0.1     <none>        443/TCP              7d
productpage                10.0.0.120   <none>        9080/TCP             6m
ratings                    10.0.0.15    <none>        9080/TCP             6m
reviews                    10.0.0.170   <none>        9080/TCP             6m

kubectl get pod

Résultat attendu :

NAME                                        READY     STATUS    RESTARTS   AGE
details-v1-1520924117-48z17                 2/2       Running   0          6m
productpage-v1-560495357-jk1lz              2/2       Running   0          6m
ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

Enfin, définissez le routage de la passerelle d'entrée pour l'application :

kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

Résultat attendu :

gateway.networking.istio.io/bookinfo-gateway created
virtualservice.networking.istio.io/bookinfo created

Vérifiez que la page du produit est accessible.

export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}"
curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"

Résultat attendu :

<title>Simple Bookstore App</title>

Créer des instances Compute Engine et installer MySQL

Au cours de cette étape, vous allez créer un modèle d'instance Compute Engine pour l'instance MySQL exécutée sur la VM. Pour connaître les étapes plus détaillées, consultez la page Bookinfo avec une machine virtuelle.

Créez un modèle d'instance Compute Engine incluant un script de démarrage pour installer MySQL et ajoutez une base de données d'évaluations au démarrage. Notez que si vous utilisez CentOS, le préparation du serveur mariadb-server peut prendre jusqu'à 10 minutes.

Debian

cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

sudo apt-get update && sudo apt-get install -y mariadb-server

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf

cat <<EOD | sudo mysql
# Grant access to root
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

# Grant root access to other IPs
CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
quit
EOD

sudo systemctl restart mysql

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image=debian-10-buster-v20201014 \
--image-project=debian-cloud \
--boot-disk-size=10GB

CentOS

cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

sudo yum update -y && sudo yum install -y mariadb-server

# Wait until mysql is ready
while true; do
  rt=$(which mysql)
  if [[ ! -z "${rt}" ]]; then
    echo "mysql is ready"
    break
  fi
  sleep 1
done

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf

sudo systemctl restart mariadb

cat > grantaccess.sql << EOD

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
EOD

until sudo mysql < grantaccess.sql; do
   sleep 1
done

sudo systemctl restart mariadb

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.9/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud \
--image-family=centos-8 \
--boot-disk-size=30GB

Créez un fichier WorkloadGroup pour la charge de travail MySQL.

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
 name: mysql
 namespace: default
spec:
 metadata:
   labels:
     app.kubernetes.io/name: mysql
   annotations:
     security.cloud.google.com/IdentityProvider: google
 template:
   serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF

Utilisez le script de VM ci-dessus pour créer un modèle d'instance afin de préparer les instances de votre réseau maillé.

./asm_vm create_gce_instance_template \
asm-mysql-instance-template \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name mysql \
--source_instance_template mysql-instance-template

Créez un groupe d'instances géré Compute Engine à l'aide du modèle d'instance que vous venez de créer.

gcloud compute instance-groups managed create mysql-instance \
--template asm-mysql-instance-template \
--zone=us-central1-c \
--project=PROJECT_ID \
--size=1

Créer un service

Créez un service Kubernetes pour le service MySQL.

Créez un service Kubernetes à l'aide de la commande suivante :

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
 name: mysql
 namespace: default
 labels:
   asm_resource_type: VM
spec:
 ports:
 - name: mysql
   port: 3306
   protocol: TCP
   targetPort: 3306
 selector:
   app.kubernetes.io/name: mysql
EOF

Utiliser le tableau de bord de l'UI Anthos

Pour afficher le nouveau service basé sur une VM que vous avez créé, cliquez sur Anthos > Service Mesh dans la barre de navigation principale à gauche. Un tableau des services s'exécutant dans votre maillage s'affiche. Le service que vous avez ajouté doit apparaître dans le tableau, avec la valeur Type correspondant à VM et certaines métriques de haut niveau. Pour afficher d'autres données de télémétrie de votre service basé sur des VM, cliquez sur le nom du service afin d'afficher le tableau de bord au niveau du service.

Pour en savoir plus sur l'utilisation du tableau de bord de l'UI Anthos, consultez la page Explorer Anthos Service Mesh dans la console Cloud.

Gérer le trafic vers les charges de travail de VM

Vous pouvez modifier les règles de mise en réseau pour contrôler la manière dont le trafic entre et sort des VM.

Contrôler le trafic vers un nouveau service de notes (pod vers VM)

Créez un autre service de notes dans Bookinfo qui utilisera l'instance MySQL créée ci-dessus comme source de données et spécifiez une règle de routage qui oblige le service de communication d'avis à utiliser le nouveau service d'évaluation.

Créez un service d'évaluation pour utiliser l'instance MySQL.

kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
 name: ratings-v2-mysql-vm
 labels:
   app: ratings
   version: v2-mysql-vm
spec:
 replicas: 1
 selector:
   matchLabels:
     app: ratings
     version: v2-mysql-vm
 template:
   metadata:
     labels:
       app: ratings
       version: v2-mysql-vm
   spec:
     serviceAccountName: bookinfo-ratings
     containers:
     - name: ratings
       image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2
       imagePullPolicy: IfNotPresent
       env:
         - name: DB_TYPE
           value: "mysql"
         - name: MYSQL_DB_HOST
           value: mysql.default.svc.cluster.local
         - name: MYSQL_DB_PORT
           value: "3306"
         - name: MYSQL_DB_USER
           value: root
         - name: MYSQL_DB_PASSWORD
           value: password
       ports:
       - containerPort: 9080
EOF

Créez une règle de routage.

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: reviews
spec:
 hosts:
 - reviews
 http:
 - route:
   - destination:
       host: reviews
       subset: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: ratings
spec:
 hosts:
 - ratings
 http:
 - route:
   - destination:
       host: ratings
       subset: v2-mysql-vm
EOF

Appliquez des règles de destination pour les services créés.

kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: reviews
spec:
 host: reviews
 subsets:
 - name: v1
   labels:
     version: v1
 - name: v2
   labels:
     version: v2
 - name: v3
   labels:
     version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
 name: ratings
spec:
 host: ratings
 subsets:
 - name: v1
   labels:
     version: v1
 - name: v2
   labels:
     version: v2
 - name: v2-mysql
   labels:
     version: v2-mysql
 - name: v2-mysql-vm
   labels:
     version: v2-mysql-vm
EOF

Valider le déploiement de l'application

Pour vérifier si l'application Bookinfo fonctionne, vous devez envoyer du trafic à la passerelle d'entrée.

Si vous avez installé Anthos Service Mesh sur GKE, obtenez l'adresse IP externe de la passerelle d'entrée que vous avez créée aux étapes précédentes :

kubectl get svc istio-ingressgateway -n istio-system

Résultat :

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

Dans cet exemple, l'adresse IP du service d'entrée est 35.239.7.64.

Essayer l'application

Vérifiez que l'application Bookinfo s'exécute avec curl :
```
curl -I http://EXTERNAL_IP/productpage
```
Si la réponse indique 200, cela signifie que l'application fonctionne correctement avec Anthos Service Mesh.
Pour afficher la page Web de Bookinfo, saisissez l'adresse suivante dans votre navigateur :
```
http://EXTERNAL_IP/productpage
```
Sur la page d'accueil de l'application Bookinfo, vérifiez que Reviewer1 affiche cinq étoiles et Reviewer2 quatre étoiles.

Appliquer la sécurité sur les charges de travail de VM

L'application de la sécurité sur les charges de travail de VM est identique à celle de l'application de la sécurité sur les charges de travail Kubernetes. Pour plus d'informations, consultez la section Sécurité Istio.

Une fois les étapes précédentes effectuées, votre VM Compute Engine dispose d'un certificat de charge de travail délivré par Google. Dans le certificat, la valeur SubjectAlternativeName indique l'identité de la charge de travail Anthos de la VM au format spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT.

Pour en savoir plus, consultez la section Pool d'identités de charge de travail.

Activer le mode strict mTLS pour le maillage

Appliquez la configuration YAML suivante pour appliquer le protocole mTLS strict à l'échelle du maillage.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

Autorisation de trafic de service à service

Utilisez AuthorizationPolicy pour contrôler l'accès entre les applications de votre VM Compute Engine et les autres charges de travail du réseau maillé (par exemple, sur le cluster GKE).

Exemple : ne pas permettre aux charges de travail Kubernetes d'accéder aux VM Compute Engine

La règle d'autorisation suivante ne permet pas à une charge de travail Kubernetes ratings d'accéder aux charges de travail de VM Compute Engine qui diffusent le serveur MySQL ratings.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: mysql-deny
  namespace: default
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: mysql
  action: DENY
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
EOF

Après avoir appliqué l'exemple AuthorizationPolicy, vous devriez voir un message d'erreur Ratings service is currently unavailable dans la section des avis sur les livres sur la page du produit.

Installer l'agent Cloud Monitoring

Vous pouvez installer l'agent Cloud Monitoring pour collecter et surveiller les métriques du système et des applications à partir de vos instances de VM. Cela vous permet de surveiller les métriques clés, telles que l'utilisation du processeur et de la mémoire sur l'agent.

Pour en savoir plus, consultez la documentation de l'agent Cloud Monitoring.

Dépannage

Pour obtenir des conseils de dépannage, consultez la section Assistance pour le dépannage des VM.