Anthos Service Mesh 1.11 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

1.20 (dernière version)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12

Ajouter des machines virtuelles Compute Engine à Anthos Service Mesh

Cette page explique comment ajouter des VM Compute Engine à Anthos Service Mesh sur Google Kubernetes Engine (GKE). Cette page explique comment installer Anthos Service Mesh 1.11.8 avec l'option qui prépare le cluster pour l'ajout d'une VM.

Si Anthos Service Mesh 1.9 or a 1.10 patch release est déjà installé, cette page explique comment passer à Anthos Service Mesh 1.11.8 avec l'option requise pour ajouter une VM.
Si vous disposez d'Anthos Service Mesh 1.9 et que vous ne souhaitez pas effectuer de mise à niveau, consultez le guide Anthos Service Mesh 1.9 pour obtenir des instructions sur l'ajout de VM à Anthos Service Mesh 1.9.
Si vous disposez d'une version antérieure d'Anthos Service Mesh, vous devez d'abord mettre à niveau Anthos Service Mesh vers la version 1.9 ou ultérieure.

Cette page fournit la ligne de commande permettant d'installer le plan de contrôle au sein du cluster ou le plan de contrôle géré par Google.

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

Anthos Service Mesh 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 faire en sorte qu'Anthos Service Mesh achemine le trafic vers l'instance de VM de la même manière qu'un 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 Anthos, mais certains éléments d'interface utilisateur et certaines fonctionnalités de la console Google Cloud ne sont disponibles que pour les abonnés Anthos. Pour en savoir plus sur ce qui est disponible pour les abonnés et les non-abonnés, consultez la section Différences entre les interfaces utilisateur Anthos et Anthos Service Mesh.
Bien que vous puissiez déployer à la fois le plan de contrôle géré par Google et le plan de données géré par Google sur votre cluster, le plan de données géré par Google ne gère pas les proxys sur les VM.

Prérequis

Avant de commencer :

Examinez le projet Cloud, les licences Anthos et les exigences générales décrites dans la section Conditions préalables.

Configuration requise pour les clusters

Avant de continuer, assurez-vous que votre cluster remplit les exigences GKE. En outre, la compatibilité avec les VM d'Anthos Service Mesh nécessite les éléments suivants :

Vous spécifiez Mesh CA comme autorité de certification lorsque vous installez Anthos Service Mesh.
Vous ne remplacez pas Stackdriver pour la télémétrie. Stackdriver est configuré par défaut lorsque vous installez Anthos Service Mesh.
Votre cluster est enregistré dans un parc. Toutefois, si le cluster n'est pas enregistré, le processus d'installation de la VM enregistre le cluster dans votre projet spécifié.

Premiers pas

Suivez la procédure de la section Premiers pas pour :

Si vous n'avez pas installé Anthos Service Mesh, passez à la section suivante. Si vous disposez déjà d'une installation Anthos Service Mesh, suivez les étapes décrites dans la section Installations existantes.

Nouvelle installation

Configurez le cluster Anthos Service Mesh pour les VM en préparant le plan de contrôle 1.11 d'Anthos Service Mesh La commande que vous exécutez dépend du type de plan de contrôle Anthos Service Mesh que vous souhaitez installer sur votre cluster.

Dans le cluster

La commande suivante montre comment installer le plan de contrôle Anthos Service Mesh dans un cluster avec --option vm, qui prépare le plan de contrôle pour l'ajout de VM.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm

--project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
--enable_all : permet au script d'effectuer les opérations suivantes :
- Accorder les autorisations IAM requises.
- Activer les API Google requises.
- Définir un libellé sur le cluster qui identifie le réseau maillé.
- Enregistrer le cluster dans le parc si ce n'est déjà fait.
--ca mesh_ca : utiliser Mesh CA comme autorité de certification. asmcli configure Mesh CA pour utiliser l'identité de charge de travail de parc.
--option vm : prépare le cluster pour inclure une VM dans le maillage de services.

Si des charges de travail existantes sont en cours d'exécution sur votre cluster, redéployez les charges de travail, puis revenez sur cette page pour ajouter vos VM.

Maillage de services géré

La commande suivante montre comment déployer le plan de contrôle géré par Google d'Anthos Service Mesh avec --option vm, qui prépare le plan de contrôle pour l'ajout de VM. Pour en savoir plus sur les autres options disponibles, consultez la section Appliquer le plan de contrôle géré par Google. Bien que la documentation Anthos Service Mesh géré utilise le script install_asm plutôt que asmcli install, vous spécifiez les options de la même manière avec les deux scripts d'installation.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm \
  --managed

--project_id, --cluster_name et --cluster_location : spécifiez l'ID du projet dans lequel se trouve le cluster, son nom, ainsi que la zone ou la région du cluster.
--output_dir : incluez cette option pour spécifier un répertoire dans lequel asmcli télécharge le package anthos-service-mesh et extrait le fichier d'installation, qui contient istioctl, des exemples et des fichiers manifestes. Sinon, asmcli télécharge les fichiers dans un répertoire tmp. Vous pouvez spécifier un chemin d'accès relatif ou complet. La variable d'environnement $PWD ne fonctionne pas ici.
--enable_all : permet au script d'effectuer les opérations suivantes :
- Accorder les autorisations IAM requises.
- Activer les API Google requises.
- Définir un libellé sur le cluster qui identifie le réseau maillé.
- Enregistrer le cluster dans le parc si ce n'est déjà fait.
--ca mesh_ca : utiliser Mesh CA comme autorité de certification. asmcli configure Mesh CA pour utiliser l'identité de charge de travail de parc.
--option vm : prépare le cluster pour inclure une VM dans le maillage de services.
--managed : déployer le plan de contrôle géré par Google.

Installations existantes

Si Anthos Service Mesh a déjà été installé sur votre cluster, procédez comme suit :

Enregistrez votre cluster dans le parc si ce n'est pas déjà fait.
Exécutez la commande suivante pour préparer votre installation d'Anthos Service Mesh et vérifier qu'elle est prête pour les charges de travail de VM. Vous exécutez la même commande pour les plans de contrôle internes au cluster et gérés par Google.
```
./asmcli experimental vm prepare-cluster \
    --project_id PROJECT_ID \
    --cluster_name CLUSTER_NAME \
    --cluster_location CLUSTER_LOCATION
```
En cas de réussite, la commande génère le résultat suivant :
```
The cluster is ready for adding VM workloads.
Please follow the Anthos Service Mesh for Compute Engine VM user guide to add
Compute Engine VMs to your mesh.
```

La commande :

Dans le cluster

Activer l'enregistrement automatique de VM : cette opération s'effectue en définissant les variables PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION et PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY 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 installés avec asmcli ont l'enregistrement automatique de VM activé 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 asmcli.
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.

Maillage de services géré

Activer l'enregistrement automatique des VM : l'enregistrement automatique des VM sera activé par défaut sur tous les plans de contrôle gérés par Google Service Mesh.
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 asmcli.
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.

Installer des passerelles d'entrée

Anthos Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé recevant des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé.

Créez un espace de noms pour la passerelle d'entrée si vous n'en possédez pas déjà un. Les passerelles sont des charges de travail d'utilisateur. Il est déconseillé de les déployer dans l'espace de noms du plan de contrôle. Remplacez GATEWAY_NAMESPACE par le nom de votre espace de noms.
```
kubectl create namespace GATEWAY_NAMESPACE
```
Activez l'injection automatique sur la passerelle en appliquant un libellé de révision sur l'espace de noms de la passerelle. Le libellé de révision est utilisé par le webhook d'injecteur side-car pour associer les proxys injectés à une révision du plan de contrôle particulière. Le libellé de révision que vous utilisez varie selon que vous avez déployé Anthos Service Mesh géré ou le plan de contrôle dans le cluster.
Dans le cluster
1. Exécutez la commande suivante pour localiser le libellé de révision sur istiod :
```
kubectl get deploy -n istio-system -l app=istiod -o \
  jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
```
2. Appliquez le libellé de révision à l'espace de noms. 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 GATEWAY_NAMESPACE \
  istio-injection- istio.io/rev=REVISION --overwrite
```
Maillage de services géré
Appliquez le libellé de révision asm-managed à l'espace de noms :
```
kubectl label namespace GATEWAY_NAMESPACE \
  istio-injection- istio.io/rev=asm-managed --overwrite
```
Ce libellé correspond à la version disponible d'Anthos Service Mesh géré pour la version d'Anthos Service Mesh.
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.
Vous pouvez déployer l'exemple de configuration de passerelle d'entrée situé dans le répertoire samples/gateways/istio-ingressgateway/ ou le modifier si nécessaire.
```
kubectl apply -n GATEWAY_NAMESPACE \
  -f DIR_PATH/samples/gateways/istio-ingressgateway
```

Découvrez les bonnes pratiques liées aux passerelles.

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 gcloud. gcloud ne génère que la configuration nécessaire pour l'agent du proxy de service. Pour inclure plus de configurations dans votre modèle d'instance, consultez le guide de référence gcloud pour en savoir plus.

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.
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.
Dans le cluster
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
```
Maillage de services géré
Pour obtenir un exemple définissant la révision asm-managed dans l'exemple suivant, consultez la section Déployer des applications.
```
kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=asm-managed --overwrite
```
Remarque : L'ajout de VM au plan de contrôle géré par Google n'est possible que sur le canal de publication Standard.

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. Le `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 la commande gcloud beta compute instance-templates create avec l'option --mesh afin de créer un modèle d'instance pour vos instances Compute Engine d'Anthos Service Mesh.

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

Pour en savoir plus sur la création de modèles d'instances, consultez la section Créer des modèles d'instances.
```
gcloud beta compute instance-templates create \
ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID
```
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 groupe d'instances géré zonal ou régional de zéro, consultez la page Autoscaling des 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.

Redéployer des charges de travail après une mise à niveau du plan de contrôle dans le cluster

Si vous avez mis à niveau Anthos Service Mesh à la section précédente et que des charges de travail sont en cours d'exécution sur votre cluster, activez-les dans le nouveau plan de contrôle.

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-1118-4-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1118-4-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1118-4,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-1118-4.
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 de gcloud. Veillez à inclure la même configuration si vous disposiez d'un modèle d'instance pour la même charge de travail.

gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

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 configuration de modèle d'instance, 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 de gcloud.

gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

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, choisissez l'instruction ci-dessous en fonction de votre type de plan de contrôle Anthos Service Mesh.
Dans le cluster
Exécutez la commande suivante pour localiser le libellé sur istiod, qui contient la valeur du 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-1118-4-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1118-4-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1118-4,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-1118-4.
Maillage de services géré
Utilisez la révision asm-managed pour ajouter des VM.
Appliquez le libellé de révision à l'espace de noms default.
Dans le cluster
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.
Maillage de services géré
```
kubectl label namespace default istio-injection- istio.io/rev=asm-managed --overwrite
```
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. Dans la commande suivante, GATEWAY_NAMESPACE est l'espace de noms de votre passerelle Istio.

export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE 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 script de démarrage pour installer MySQL et ajouter une base de données de notes au démarrage. Notez que si vous utilisez CentOS, la 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

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns 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.11/samples/bookinfo/src/mysql/mysqldb-init.sql

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

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

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns 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.11/samples/bookinfo/src/mysql/mysqldb-init.sql

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

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 gcloud pour créer un modèle d'instance afin de préparer les instances pour votre maillage et d'inclure le script de démarrage créé ci-dessus.

Debian

gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB

CentOS

gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB

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 à 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'interface utilisateur 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 GATEWAY_NAMESPACE

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.