Cette page explique comment ajouter des machines virtuelles (VM) Compute Engine à Anthos Service Mesh sur Google Kubernetes Engine (GKE). Cette page explique comment installer Anthos Service Mesh 1.10.6 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.10.6 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 dans le cluster.
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 leWorkloadGroup
et acheminer le trafic ASM vers l'instance de VM de la même manière que versPod
. 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 :
Passez en revue le projet Cloud, les licences GKE Enterprise et les exigences générales décrites dans la section Prérequis.
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é.
Comment en profiter ?
Suivez la procédure de la section Premiers pas pour :
- Installer les outils nécessaires
- Télécharger
asmcli
- Accorder des autorisations d'administrateur de cluster
- Valider votre projet et votre cluster
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.10 d'Anthos Service Mesh
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 lequelasmcli
télécharge le packageanthos-service-mesh
et extrait le fichier d'installation, qui contientistioctl
, des exemples et des fichiers manifestes. Sinon,asmcli
télécharge les fichiers dans un répertoiretmp
. 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.
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.
./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 :
Activer l'enregistrement automatique de VM : cette opération s'effectue en définissant les variables
PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION
etPILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY
sur "true". Lorsque cette option est activée, les nouvelles instances de VM sont enregistrées auprès deWorkloadGroup
et de nouvelles réponses standardiséesWorkloadEntry
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 avecasmcli
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éeIdentityProvider
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 scriptasmcli
.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.
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 ressemble à ceci :
NAME READY STATUS RESTARTS AGE LABELS istiod-asm-1106-2-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586 istiod-asm-1106-2-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
Dans le résultat, sous la colonne
LABELS
, notez la valeur du libellé de révisionistiod
, qui suit le préfixeistio.io/rev=
. Dans cet exemple, la valeur estasm-1106-2
.Appliquez le libellé de révision à l'espace de noms. Dans la commande suivante,
REVISION
correspond à la valeur du libellé de révisionistiod
que vous avez notée à l'étape précédente.kubectl label namespace GATEWAY_NAMESPACE 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 leistio-injection
et le libellé de révision, toutes les commandeskubectl label
de la documentation Anthos Service Mesh incluent la suppression du libelléistio-injection
.Accédez au répertoire que vous avez spécifié dans
--output_dir
.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 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.
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. LeIdentityProvider
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
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-1106-2-85d86774f7-flrt2 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=85d86774f7 istiod-asm-1106-2-85d86774f7-tcwtn 1/1 Running 0 26m app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=85d86774f7
Dans le résultat, sous la colonne
LABELS
, notez la valeur du libellé de révisionistiod
pour la nouvelle version, à la suite du préfixeistio.io/rev=
. Dans cet exemple, la valeur estasm-1106-2
.Notez également la valeur du libellé de révision pour l'ancienne version de
istiod
. Vous devrez supprimer l'ancienne version deistiod
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 deistiod
estdefault
.
Ajoutez le libellé de révision à un espace de noms et supprimez le libellé
istio-injection
(s'il existe). Dans la commande suivante, remplacezREVISION
par la valeur correspondant à la nouvelle révision deistiod
.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 leistio-injection
et le libellé de révision, toutes les commandeskubectl 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.
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-1106-2-5788d57586-bljj4 1/1 Running 0 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586 istiod-asm-1106-2-5788d57586-vsklm 1/1 Running 1 23h app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
Dans le résultat, sous la colonne
LABELS
, notez la valeur du libellé de révisionistiod
, qui suit le préfixeistio.io/rev=
. Dans cet exemple, la valeur estasm-1106-2
.Appliquez le libellé de révision à l'espace de noms
default
.Dans la commande suivante,
REVISION
correspond à la valeur du libellé de révisionistiod
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 leistio-injection
et le libellé de révision, toutes les commandeskubectl 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
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
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.10/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.10/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'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 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 etReviewer2
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.