Préparer la configuration de Cloud Service Mesh avec Envoy
La configuration de Cloud Service Mesh comprend les phases suivantes:
- Attribution des autorisations, activation de l'API Traffic Director et, si vous utilisez Compute Engine, configuration de Cloud DNS.
- Déployer vos applications avec des proxys Envoy
- Créer des services et des règles de routage qui déterminent la façon dont le trafic transite par votre maillage de services.
Ce document décrit la première phase et s'applique lorsque vous utilisez la les anciennes API. Les deuxième et troisième phases sont traitées dans le guides spécifiques à la plate-forme listés dans la section Poursuivre le processus de configuration. plus loin dans ce document.
Avant de lire ce guide, familiarisez-vous avec les Présentation de Cloud Service Mesh Si vous utilisez les API de routage de services, consultez la présentation des API de routage de services.
Prérequis
Que vous envisagiez d'utiliser Cloud Service Mesh pour configurer des proxys Envoy s'exécutant en parallèle d'applications hébergées sur des machines virtuelles (VM), de conteneurs ou des deux, vous devez d'abord effectuer les tâches suivantes :
- Activez la facturation.
- Choisissez le mode d'installation d'Envoy.
- Accordez les autorisations requises.
- Activez l'API Traffic Director pour votre projet.
- Si vous utilisez Compute Engine, activez l'API Cloud DNS et configurez Cloud DNS.
- Vérifiez que le compte de service utilisé par les proxys Envoy dispose des autorisations suffisantes pour accéder à l'API Traffic Director.
Les sections suivantes fournissent des instructions pour chaque tâche.
Activer la facturation
Vérifiez que la facturation est activée pour votre projet Google Cloud. Pour en savoir plus, consultez la section Activer, désactiver ou modifier la facturation pour un projet.
Choisir le mode d'installation d'Envoy
Cloud Service Mesh vous permet d'installer des proxys Envoy et de gérer cette couche d'infrastructure :
Sur Compute Engine, vous pouvez ajouter automatiquement Envoy aux applications exécutées sur vos VM. Vous utilisez un modèle de VM qui installe Envoy, le connecte à Cloud Service Mesh, et configure la mise en réseau de vos VM.
Sur Google Kubernetes Engine (GKE), vous pouvez ajouter automatiquement des proxys side-car Envoy aux pods de vos services. Vous installez un injecteur de side-car Envoy dans votre cluster, qui ajoute des proxys side-car Envoy, les connecte à Cloud Service Mesh configure la mise en réseau de votre conteneur.
Enfin, vous pouvez également utiliser des solutions de déploiement Envoy de fournisseurs tiers. avec Cloud Service Mesh. GetEnvoy est un exemple de ce type de solution, qui fournit une approche basée sur un gestionnaire de packages pour l'installation et la mise à jour de vos proxys Envoy.
À propos de la gestion des versions Envoy
Vous devez utiliser Envoy version 1.9.1 ou ultérieure pour fonctionner avec Cloud Service Mesh. Nous vous recommandons de toujours utiliser la version la plus récente d'Envoy pour vous assurer que les failles de sécurité connues ont été corrigées.
Si vous décidez de déployer Envoy à l'aide de l'une de nos méthodes automatisées, nous nous chargeons de cette tâche comme suit :
Lorsque vous utilisez un déploiement Envoy automatisé avec des VM Compute Engine, le nœud Envoy installée est une version que nous avons validée pour fonctionner avec Cloud Service Mesh. Lorsqu'une VM est créée à l'aide du modèle d'instance, elle reçoit la dernière version validée. Si votre VM est de longue durée, vous pouvez utiliser une mise à jour progressive pour remplacer les VM existantes et récupérer la dernière version.
Lorsque vous utilisez l'injecteur de side-car Envoy avec GKE, l'injecteur est configuré pour utiliser une version récente d'Envoy que nous avons validée pour utiliser Cloud Service Mesh. Lorsqu'un side-car est injecté avec votre pod de charge de travail, il reçoit cette version d'Envoy. Si vous souhaitez récupérer une version plus récente d'Envoy, mettez à jour l'injecteur side-car Envoy.
Pour plus d'informations sur des versions Envoy spécifiques, consultez la section Historique des versions. Pour plus d'informations sur les failles de sécurité, consultez la page Conseils de sécurité.
Accorder les autorisations Cloud IAM requises
Vous devez disposer des autorisations IAM (Identity and Access Management) suffisantes pour créer une VM
et modifier un réseau pour configurer Cloud Service Mesh. Si vous disposez du rôle de propriétaire ou d'éditeur (roles/owner
ou roles/editor
) pour le projet dans lequel vous activez Cloud Service Mesh, vous disposez automatiquement des autorisations appropriées.
Dans le cas contraire, tous les rôles IAM Compute Engine doivent être affichés dans le tableau suivant. Avec ces rôles, vous disposez alors également des autorisations associées, comme décrit dans la documentation IAM de Compute Engine.
Tâche | Rôle requis |
---|---|
Définir la stratégie IAM d'un compte de service. | Administrateur de compte de service ( roles/iam.serviceAccountAdmin ) |
Activez Cloud Service Mesh. | Administrateur Service Usage ( roles/serviceusage.serviceUsageAdmin ) |
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge. | Administrateur de réseaux Compute ( roles/compute.networkAdmin ) |
Ajouter et supprimer des règles de pare-feu. | Administrateur de sécurité de Compute ( roles/compute.securityAdmin ) |
Créer des instances. | Administrateur d'instances de Compute ( roles/compute.instanceAdmin ) |
Le pool de nœuds GKE ou les VM Compute Engine
ont la
https://www.googleapis.com/auth/cloud-platform
le champ d'application. Pour en savoir plus, consultez la page Résoudre des problèmes pour les déploiements qui utilisent Envoy.
Avec xDS v3, attribuez le rôle roles/trafficdirector.client
au compte de service utilisé par les clients Envoy de Cloud Service Mesh.
Activer l'API Traffic Director
Console
Dans Google Cloud Console, accédez à la page Bibliothèque d'API de votre projet.
Dans le champ Rechercher des API et des services, saisissez
Traffic Director
.Dans la liste des résultats de recherche, cliquez sur API Traffic Director. Si l'API Traffic Director ne figure pas dans la liste, cela signifie que vous ne disposez pas des autorisations nécessaires pour l'activer.
Sur la page API Traffic Director, cliquez sur Activer.
gcloud
Exécutez la commande suivante :
gcloud services enable trafficdirector.googleapis.com
Activer l'API Cloud DNS et configurer Cloud DNS
Suivez ces instructions si vous configurez Cloud Service Mesh sur Compute Engine. Vous devez activer l'API Cloud DNS et configurer Cloud DNS pour la résolution de noms DNS.
Pour obtenir des informations générales sur Cloud Service Mesh et la résolution DNS, consultez Cloud Service Mesh et résolution de noms DNS.
Tout d'abord, suivez les instructions ci-dessous pour activer l'API Cloud DNS.
Console
Dans Google Cloud Console, accédez à la page Bibliothèque d'API de votre projet.
Dans le champ Rechercher des API et des services, saisissez
DNS
.Dans la liste des résultats de recherche, cliquez sur API Cloud DNS. Si l'API Cloud DNS ne figure pas dans la liste, cela signifie que vous ne disposez pas des autorisations nécessaires pour l'activer.
Sur la page API Cloud DNS, cliquez sur Activer.
gcloud
Exécutez la commande suivante :
gcloud services enable dns.googleapis.com
Configurez ensuite une zone privée gérée Cloud DNS. Suivez les instructions de la section Créer une zone privée.
Permettre au compte de service d'accéder à l'API Traffic Director
Lorsque vous configurez votre plan de données et que vous le connectez à Cloud Service Mesh,
Les clients xDS (par exemple, les proxys Envoy) se connectent au
trafficdirector.googleapis.com
serveur xDS. Ces clients xDS présentent au serveur xDS une identité de compte de service afin de garantir que les communications entre le plan de données et le plan de contrôle disposent des autorisations appropriées :
- Pour une VM Compute Engine, le client xDS utilise le compte de service attribué à la VM.
- Pour GKE, si
Workload Identity
n'est pas activé, le client xDS utilise le compte de service attribué au nœud GKE sous-jacent. - Si
Workload Identity
est activé, le client xDS utilise le compte de service Google lié au compte de service Kubernetes attribué au pod.
Vous devez disposer des autorisations suivantes : Seul xDS v3 est compatible. Si vous utilisez xDS v2, vous devez migrer vers xDS v3. Pour en savoir plus sur la migration, consultez la section Migrer de xDS v2 à xDS v3.
Lorsque vous utilisez xDS v3, le compte de service utilisé par vos clients doit disposer des autorisations trafficdirector.networks.reportMetrics
et trafficdirector.networks.getConfigs
. Vous pouvez utiliser le rôle client Cloud Service Mesh d'IAM (roles/trafficdirector.client
), qui encapsule les deux autorisations.
Console
Dans la console Google Cloud, accédez à la page IAM et administration.
Sélectionnez votre projet.
Identifiez le compte de service auquel vous souhaitez ajouter un rôle :
- Si ce compte de service ne figure pas déjà sur la liste des membres, cela signifie qu'aucun rôle ne lui a encore été attribué. Cliquez sur Ajouter, puis saisissez l'adresse e-mail du compte de service.
- Si le compte de service figure déjà sur la liste des membres, il possède des rôles. Sélectionnez le compte de service, puis cliquez sur l'onglet Rôles.
Développez le rôle. Pour le compte de service que vous souhaitez modifier, cliquez sur
Modifier.Sélectionnez le rôle Autre > Client Cloud Service Mesh.
Pour appliquer le rôle au compte de service, cliquez sur Enregistrer.
gcloud
Exécutez la commande ci-dessous.
gcloud projects add-iam-policy-binding PROJECT \ --member serviceAccount:SERVICE_ACCOUNT_EMAIL \ --role=roles/trafficdirector.client
Remplacez l'élément suivant :
PROJECT
: saisissezgcloud config get-value project
SERVICE_ACCOUNT_EMAIL
: adresse e-mail associée au compte de service
Poursuivre la configuration
Maintenant que vous avez terminé les étapes préalables, vous pouvez commencer à configurer votre maillage de services.