Comprendre l'état du client Cloud Service Mesh
Lorsque vous utilisez Cloud Service Mesh pour gérer la mise en réseau de vos applications, tenez compte des deux composants principaux suivants:
- La couche d'infrastructure. La couche d'infrastructure, qui inclut les proxys side-car Envoy ou les bibliothèques gRPC sans proxy, est configurée pour gérer la mise en réseau pour le compte de vos applications.
- Le plan de contrôle, Cloud Service Mesh. Le plan de contrôle génère une configuration pour la couche d'infrastructure et la lui distribue.
Lorsqu'un proxy Envoy ou la bibliothèque gRPC est initialisé, il utilise les API xDS pour se connecter à Cloud Service Mesh. Le proxy ou la bibliothèque agit en tant que client auprès de Cloud Service Mesh. Une fois la connexion établie entre le client et Cloud Service Mesh, Cloud Service Mesh renvoie les informations de configuration au client et met à jour la configuration si nécessaire.
Il est parfois utile de comprendre quels clients sont connectés à Cloud Service Mesh ou d'inspecter la configuration générée par Cloud Service Mesh pour ses clients. Par exemple, vous pouvez vouloir déboguer un problème ou comprendre l'impact des actions que vous avez effectuées lors de la configuration de Cloud Service Mesh sur la configuration visible de vos clients.
Cloud Service Mesh est compatible avec l'API Client Status Discovery Service (CSDS). Vous devez utiliser un client CSDS pour interroger cette API. Cela vous permet de voir quels clients sont connectés à Cloud Service Mesh et d'inspecter la configuration générée par Cloud Service Mesh pour ses clients.
Le client CSDS est un outil Open Source que vous pouvez obtenir à partir du dépôt Envoy. Le schéma suivant montre comment le client CSDS interroge Cloud Service Mesh pour en savoir plus sur son API CSDS.
Le client CSDS se connecte à Cloud Service Mesh et présente un numéro de projet et un nom de réseau ainsi qu'un ensemble d'identifiants. Cloud Service Mesh peut ensuite répondre avec des informations sur les différents clients Cloud Service Mesh auxquels il est connecté.
Pour plus d'informations sur le client CSDS, consultez le fichier README.
Prérequis
Pour vous connecter à l'API CSDS, vous aurez besoin d'un client CSDS. Vous pouvez obtenir le client de l'une des deux manières suivantes :
- Vous pouvez créer ce client à l'aide de Cloud Shell.
- Vous pouvez créer le client sur un ordinateur de développement local.
Créer le client CSDS à l'aide de Cloud Shell
Pour utiliser Cloud Shell afin de créer le client CSDS, procédez comme suit :
- Réinitialisez Cloud Shell en suivant les instructions de la section Désactiver ou réinitialiser Cloud Shell. Cela garantit que les configurations existantes n'interfèrent pas avec votre build.
- Dans Google Cloud Console, ouvrez une nouvelle session Cloud Shell.
Exécutez la commande suivante pour obtenir le code source que vous utiliserez pour créer le client CSDS :
git clone https://github.com/envoyproxy/envoy-tools.git
Accédez au répertoire client CSDS et exécutez les commandes suivantes :
cd envoy-tools/csds-client/ make init make build
Une fois la compilation terminée, testez-la avec la commande suivante :
csds-client -help
Si la compilation réussit, le texte d'aide du client s'affiche.
Créer le client CSDS sur un ordinateur de développement local
Vous pouvez télécharger et créer un client CSDS sur un ordinateur local en suivant les instructions du fichier README dans le dépôt Open Source. Pour ce faire, vous devez également avoir installé Go et l'outil make
doit être configuré dans votre environnement. Si vous préférez ne pas le faire, suivez plutôt les instructions précédentes pour Cloud Shell (qui inclut Go et l'outil make
).
Conditions préalables supplémentaires
Assurez-vous que l'ID de nœud de chaque client est unique dans le maillage de services. Si plusieurs clients partagent le même ID de nœud, une seule configuration est renvoyée. Il s'agit de la configuration du client qui s'est connecté le plus récemment à Cloud Service Mesh.
Si vous utilisez les packages de référence Google, vous n'avez pas besoin de définir manuellement l'ID du nœud dans vos fichiers d'amorçage car un ID de nœud est généré pour vous. Si vous n'utilisez pas les packages de référence, vous devez définir manuellement l'ID de nœud dans chacun de vos fichiers d'amorçage.
Assurez-vous d'avoir accès à un compte utilisateur disposant des autorisations IAM (Identity and Access Management) requises pour configurer Cloud Service Mesh. Les instructions suivantes font appel à Google Cloud CLI pour générer et fournir automatiquement les identifiants requis par le client CSDS. Vous pouvez également utiliser le client CSDS et fournir les identifiants directement.
Déterminer quels clients sont actuellement connectés à Cloud Service Mesh
Le client CSDS vous permet de déterminer les clients connectés à votre configuration Cloud Service Mesh.
Pour obtenir ces informations, vous avez besoin des informations suivantes :
ID du projet à partir duquel les identifiants ont été générés.
Si vous utilisez les API de routage de services, l'une des options suivantes, selon la ressource que le client xDS récupère :
Si vous utilisez les anciennes API, indiquez le nom du réseau VPC que vous avez spécifié lors de la configuration de Cloud Service Mesh. Ce réseau est celui spécifié par la règle de transfert de la carte des règles de routage.
API de routage de services
En utilisant un compte disposant des autorisations appropriées, exécutez la commande suivante :
gcloud auth application-default login \ --billing-project=BILLING_PROJECT_ID
Créez un fichier au format YAML avec le contenu suivant.
node_matchers: - node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_MESH_SCOPE_NAME value: string_match: exact: "MESH_OR_SCOPE"
Remplacez les valeurs suivantes :
PROJECT_NUMBER
: ID du projetMESH_OR_SCOPE
: si le client xDS récupère une ressource Mesh, utilisez un préfixemesh:
suivi du nom réel du maillage. Si le client xDS récupère une ressource de passerelle, utilisez un préfixescope:
suivi du nom du paramètre de champ d'application.
Exécutez le client CSDS, qui utilise les identifiants générés par gcloud CLI. Remplacez
PATH_TO_CSDS_REQUEST_YAML_FILE
par le chemin d'accès au fichier YAML que vous avez créé à l'étape précédente.csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE
La sortie obtenue doit ressembler à ceci :
Client ID xDS stream type Config status 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 ADS N/A 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 LRS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 LRS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 ADS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 LRS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 ADS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 LRS N/A
La colonne
Client ID
affiche les ID des clients connectés à Cloud Service Mesh. Ces ID clients sont fournis à l'aide du champnode_id
du fichier d'amorçage utilisé par Envoy ou gRPC sans proxy lorsqu'ils se connectent à Cloud Service Mesh.
Anciennes API
En utilisant un compte disposant des autorisations appropriées, exécutez la commande suivante :
gcloud auth application-default login \ --billing-project=BILLING_PROJECT_ID
Créez un fichier au format YAML avec le contenu suivant.
node_matchers: - node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_NETWORK_NAME value: string_match: exact: "NETWORK_NAME"
Remplacez les valeurs suivantes :
PROJECT_NUMBER
: ID unique du projet Google Cloud.NETWORK_NAME
: réseau VPC spécifié par la règle de transfert de la carte des règles de routage
Exécutez le client CSDS, qui utilise les identifiants générés par gcloud CLI. Remplacez
PATH_TO_CSDS_REQUEST_YAML_FILE
par le chemin d'accès au fichier YAML que vous avez créé à l'étape précédente.csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE
La sortie obtenue doit ressembler à ceci :
Client ID xDS stream type Config status 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 ADS N/A 603e3524-d1d6-4a9e-9b26-39bcd633a7cb~10.128.0.5 LRS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS N/A 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 LRS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 ADS N/A d9577b61-fa3a-41d6-90bd-11c4fdd2f8c0~10.128.0.4 LRS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 ADS N/A f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6 LRS N/A
La colonne
Client ID
affiche les ID des clients connectés à Cloud Service Mesh. Ces ID clients sont fournis à l'aide du champnode_id
du fichier d'amorçage utilisé par Envoy ou gRPC sans proxy lorsqu'ils se connectent à Cloud Service Mesh.
Inspecter la configuration d'un client Cloud Service Mesh spécifique
Vous pouvez inspecter la configuration envoyée par Cloud Service Mesh à un client particulier en utilisant l'ID client que vous avez obtenu dans la section précédente.
Vous pouvez examiner la configuration détaillée du proto de ressources pour déterminer la version de l'API xDS utilisée par un client spécifique. Par exemple, si vous voyez envoy.api.v2.Cluster
dans la configuration, cela signifie que le client utilise l'API v2.
Si envoy.api.v3.Cluster
s'affiche dans la configuration, cela signifie que le client utilise l'API v3. Seule la version 3 de xDS est prise en charge. Pour savoir comment passer de la version 2 à la version 3, consultez la page Migrer de xDS v2 à xDS v3.
API de routage de services
Mettez à jour le fichier YAML que vous avez créé dans la section Déterminer les clients actuellement connectés à Cloud Service Mesh. Ajoutez un champ
node-id
en utilisant l'ID client comme valeur.node_matchers: - node_id: exact: "CLIENT_ID" node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_MESH_SCOPE_NAME value: string_match: exact: "MESH_OR_SCOPE_NAME"
Remplacez les valeurs suivantes :
CLIENT_ID
: ID du client dont vous inspectez la configuration, par exempleprojects/000000/networks/mesh:mesh1/nodes/00000000-0000-0000-0000-00000000~127.0.0.1
PROJECT_NUMBER
: ID unique du projet Google Cloud.MESH_OR_SCOPE
: si le client xDS récupère une ressource Mesh, utilisez un préfixemesh:
suivi du nom réel du maillage. Si le client xDS récupère une ressource de passerelle, utilisez un préfixescope:
suivi du nom du paramètre de champ d'application.
Exécutez le client CSDS. L'exécution du client génère un fichier JSON. Ce fichier contient la configuration envoyée au client Cloud Service Mesh.
csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE \ -output_file FILENAME.JSON
Remplacez les valeurs suivantes :
PATH_TO_CSDS_REQUEST_YAML_FILE
: chemin d'accès à votre fichier YAML.FILENAME.JSON
: nom du fichier contenant la sortie du client CSDS.
La sortie obtenue doit ressembler à ceci :
Client ID xDS stream type Config status 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS LDS SYNCED RDS SYNCED CDS STALE Config has been saved to FILENAME.JSON
Vous pouvez inspecter une configuration xDS détaillée en consultant le fichier JSON. Ce résultat contient l'état des configurations xDS individuelles envoyées par Cloud Service Mesh au client à l'aide d'un flux gRPC agrégé (ADS).
Anciennes API
Mettez à jour le fichier YAML que vous avez créé dans la section Déterminer les clients actuellement connectés à Cloud Service Mesh. Ajoutez un champ
node-id
en utilisant l'ID client comme valeur.node_matchers: - node_id: exact: "CLIENT_ID" node_metadatas: - path: - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER value: string_match: exact: "PROJECT_NUMBER" - path: - key: TRAFFICDIRECTOR_NETWORK_NAME value: string_match: exact: "NETWORK_NAME"
Remplacez les valeurs suivantes :
CLIENT_ID
: ID du client dont vous inspectez la configuration, par exemplef38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6
PROJECT_NUMBER
: ID unique du projet Google Cloud.NETWORK_NAME
: réseau VPC spécifié par la règle de transfert de la carte des règles de routage.
Exécutez le client CSDS. L'exécution du client génère un fichier JSON. Ce fichier contient la configuration envoyée au client Cloud Service Mesh.
csds-client \ -service_uri trafficdirector.googleapis.com:443 \ -platform gcp \ -authn_mode auto \ -api_version v3 \ -request_file PATH_TO_CSDS_REQUEST_YAML_FILE \ -output_file FILENAME.JSON
Remplacez les valeurs suivantes :
PATH_TO_CSDS_REQUEST_YAML_FILE
: chemin d'accès à votre fichier YAML.FILENAME.JSON
: nom du fichier contenant la sortie du client CSDS.
La sortie obtenue doit ressembler à ceci :
Client ID xDS stream type Config status 8576d4bf-8f10-40b2-920b-bb6a7cf9f34a~10.168.0.3 ADS LDS SYNCED RDS SYNCED CDS STALE Config has been saved to FILENAME.JSON
Vous pouvez inspecter une configuration xDS détaillée en consultant le fichier JSON. Ce résultat contient l'état des configurations xDS individuelles envoyées par Cloud Service Mesh au client à l'aide d'un flux gRPC agrégé (ADS).
Valeurs d'état
Le tableau suivant répertorie les valeurs d'état de configuration xDS que vous pouvez rencontrez.
Valeur | Description |
---|---|
UNKNOWN |
(Par défaut) Les informations sur l'état ne sont pas disponibles ou sont inconnues. |
SYNCED |
Cloud Service Mesh a envoyé la configuration au client et a reçu un ACK du client. |
ERROR |
Cloud Service Mesh a envoyé la configuration au client et a reçu un NACK du client. |
STALE |
Cloud Service Mesh a envoyé la configuration au client, mais n'a pas reçu de ACK ni de NACK de la part du client. |
NOT_SENT |
La configuration n'a pas été envoyée. |
N/A |
Le client CSDS n'a pas inclus l'ID du nœud. Tous les flux connectés sont renvoyés, mais l'état de la configuration n'est pas disponible. |
Visualisation et surveillance
L'outil Open Source du client CSDS offre des fonctionnalités supplémentaires que vous pouvez utiliser, telles que la visualisation et la surveillance continue. Pour en savoir plus sur ces fonctionnalités, consultez le fichier README dans le dépôt Open Source.
Message d'erreur
Vous pouvez voir le message d'erreur suivant du client CSDS si vous activez l'API Cloud Service Mesh uniquement dans votre projet:
rpc error: code = NotFound desc = Requested entity was not found.
Ce comportement est normal. La configuration de Cloud Service Mesh est limitée par réseau. Si vous n'avez pas encore créé de réseau et que vous exécutez le client CSDS, ce message d'erreur s'affiche.
Limites
- Les informations sur les points de terminaison ne sont pas incluses dans la réponse CSDS, car elles ne sont pas disponibles dans l'API CSDS v3.
- L'ID de nœud de chaque client doit être unique dans le maillage de services. Si plusieurs clients partagent le même ID de nœud, une seule configuration est renvoyée. Il s'agit de la configuration du client qui s'est connecté le plus récemment à Cloud Service Mesh.
- Une barre oblique inverse (\) peut parfois apparaître dans le champ d'ID de nœud du fichier YAML. Dans ce cas, échappez la barre oblique inverse en utilisant une barre oblique inverse supplémentaire lorsque vous interrogez l'API CSDS pour obtenir des informations de configuration. Il s'agit d'un problème connu.
Étape suivante
- Pour obtenir des informations de dépannage générales sur Cloud Service Mesh, consultez la page Résoudre les problèmes pour les déploiements qui utilisent Envoy.
- Pour résoudre les problèmes de configuration lorsque vous déployez des services gRPC sans proxy, consultez la page Résoudre les problèmes de déploiement qui utilisent gRPC sans proxy.