Version 1.9 :

Ajouter des machines virtuelles Compute Engine à Anthos Service Mesh

Présentation

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 Google Cloud Console

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.

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.
  • Seul le système d'exploitation Debian est compatible avec Compute Engine. Pour en savoir plus, consultez la page dédiée à l'assistance Debian.
  • 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'UI et certaines fonctionnalités de Google Cloud Console 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.

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

Le cluster doit être enregistré dans un environnement. 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é à Anthos, activez l'API Anthos.

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.

  1. Téléchargez le script de VM pour Anthos Service Mesh 1.9.2 dans le répertoire de travail actuel :

    curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm
    
  2. 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
    
  3. 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 asm_vm: OK. Pour plus de compatibilité, la commande précédente inclut l'option --ignore-missing permettant de renommer n'importe quelle version du script en asm_vm.

  4. Rendez le script exécutable :

    chmod +x asm_vm
    

Premiers pas

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

Configurer votre environnement

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

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

Choisissez la prochaine étape en fonction de si Anthos Service Mesh 1.9 est déjà installé sur votre cluster ou non.

Non installé

Si Anthos Service Mesh 1.9 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 Environ 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é

Si Anthos Service Mesh 1.9 est déjà installé sur votre cluster, mettez simplement à jour le plan de contrôle d'Anthos Service Mesh pour accepter 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 pour qu'elles soient prêtes pour les charges de travail de VM.

./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 :

  1. 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 installés avec install_asm incluent cette valeur par défaut.

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

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

  4. Enregistrez le cluster dans Environ et activez l'identité de la charge de travail si vous utilisez --enable_all ou --enable_registration dans le script install_asm.

  5. Activer la fonctionnalité Service Mesh dans Environ. 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 :

  1. 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.
  2. 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
    
  3. É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
    
  4. 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.
  5. 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 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.
  6. 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.
  7. 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.

  8. 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
    
  9. 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.

  10. 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 :

  1. 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-192-1-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-192-1,istio=istiod,pod-template-hash=85d86774f7
    istiod-asm-192-1-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-192-1,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-192-1.

    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.

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

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

    ./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
    
  4. 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
    
  5. 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.

  1. 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
    
  2. 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
    
  3. 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.

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

  2. 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-192-1-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-192-1,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-192-1-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-192-1,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-192-1.

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

  4. 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
    
  5. 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

    et

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

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

    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
    
  2. 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
    
  3. 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
    
  4. 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.

  1. 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 Cloud Console.

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.

  1. 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
    
  2. 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
    
  3. 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
    

    Sortie :

    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

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

  2. Pour afficher la page Web de Bookinfo, saisissez l'adresse suivante dans votre navigateur :

    http://EXTERNAL_IP/productpage
    
  3. 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: ratings
      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.