Comprendre l'état du client Traffic Director

Lorsque vous utilisez Traffic Director pour gérer la mise en réseau de votre application, vous devez tenir compte de deux éléments principaux:

  1. La couche d'infrastructure. La couche d'infrastructure, telle que les proxys side-car Envoy ou les bibliothèques gRPC sans proxy, est configurée pour gérer la mise en réseau au nom de vos applications.
  2. Le plan de contrôle, Traffic Director. Le plan de contrôle génère une configuration pour la couche d'infrastructure et la distribue à cette couche.

Lorsqu'un proxy ou la bibliothèque gRPC est initialisé, il se connecte à Traffic Director à l'aide des API xDS. Le proxy ou la bibliothèque agit en tant que client de Traffic Director. Une fois la connexion établie entre le client et Traffic Director, Traffic Director renvoie les informations de configuration au client et met à jour la configuration si nécessaire.

Parfois, il est utile de comprendre quels clients sont connectés à Traffic Director ou à inspecter la configuration générée par Traffic Director pour ses clients. Par exemple, vous pouvez avoir besoin de déboguer un problème ou de mieux comprendre l'impact des actions que vous avez effectuées lors de la configuration de Traffic Director sur la configuration affichée par vos clients.

Traffic Director est compatible avec l'API Client Status Discovery (CSDS). Vous devez interroger cette API à l'aide d'un client CSDS. Cela vous permet de voir quels clients sont connectés à Traffic Director et d'inspecter la configuration générée par Traffic Director pour ses clients.

Le client CSDS est un outil Open Source que vous pouvez obtenir dans le dépôt Envoy. Le schéma suivant montre comment le client CSDS interroge Traffic Director pour obtenir plus d'informations sur l'API CSDS de Traffic Director.

Obtenir des informations de configuration sur les clients Traffic Director à l'aide de l'API CSDS (cliquez pour agrandir)
Utiliser l'API CSDS pour obtenir des informations de configuration sur les clients Traffic Director (cliquez pour agrandir)

Le client CSDS se connecte à Traffic Director et présente un numéro de projet, un nom de réseau et un ensemble d'identifiants. Traffic Director peut ensuite fournir des informations sur les différents clients Traffic Director auxquels il est connecté.

Conditions préalables

Pour vous connecter à l'API CSDS, vous avez besoin d'un client CSDS. Il existe deux façons d'obtenir le client.

  1. Vous pouvez créer le client à l'aide de Cloud Shell.
  2. Vous pouvez créer le client sur un ordinateur de développement local.

Les deux sections suivantes fournissent des informations détaillées sur les deux méthodes d'obtention du client CSDS.

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:

  1. Suivez les instructions figurant dans la section Désactiver ou réinitialiser Cloud Shell pour réinitialiser Cloud Shell. Cela garantit que les configurations existantes n'interfèrent pas avec votre compilation.
  2. Dans Google Cloud Console, ouvrez une nouvelle session Cloud Shell.
  3. Exécutez la commande suivante pour obtenir le code source permettant de créer le client CSDS:

    git clone https://github.com/envoyproxy/envoy-tools.git
    
  4. Accédez au répertoire client CSDS et exécutez les commandes suivantes:

    cd envoy-tools/csds-client/
    make init
    make build
    
  5. 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 fournies dans le fichier README du dépôt Open Source. Pour ce faire, vous devez également configurer Go et l'outil make dans votre environnement. Si vous préférez ne pas le faire, suivez les instructions ci-dessus pour Cloud Shell, dans lequel Go et l'outil make sont fournis.

Conditions préalables supplémentaires

  1. Assurez-vous que l'ID de nœud de chaque client est unique au sein du 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 à Traffic Director. Si vous utilisez les packages de référence Google, vous n'avez pas besoin de définir manuellement l'ID de nœud dans vos fichiers d'amorçage. 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.
  2. Assurez-vous d'avoir accès à un compte utilisateur disposant des autorisations IAM requises pour configurer Traffic Director. Les instructions ci-dessous utilisent l'outil de ligne de commande gcloud pour générer et fournir automatiquement les identifiants requis par le client CSDS. Vous pouvez également utiliser le client CSDS et fournir directement les identifiants.

Déterminer quels clients sont actuellement connectés à Traffic Director

Avant de suivre cette procédure, vous aurez besoin des informations suivantes:

  • Numéro du projet à partir duquel les identifiants ont été générés.
  • Nom de réseau que vous avez spécifié lors de la configuration de Traffic Director. Il s'agit du nom de réseau de la règle de transfert de la carte des règles de routage.

Pour déterminer les clients connectés à Traffic Director, procédez comme suit:

  1. À partir d'un compte disposant des autorisations appropriées, exécutez la commande suivante:

    gcloud auth application-default login --billing-project BILLING_PROJECT_ID
    
  2. Créez un fichier au format YAML avec le contenu suivant, en remplaçant PROJECT_NUMBER et NETWORK_NAME par les valeurs appropriées pour votre déploiement:

      node_matchers:
        - node_metadatas:
            - path:
                - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
              value:
                string_match:
                  exact: "PROJECT_NUMBER" # e.g.,: "314053285323"
            - path:
                - key: TRAFFICDIRECTOR_NETWORK_NAME
              value:
                string_match:
                  exact: "NETWORK_NAME" # e.g.,: "default"
      

  3. Exécutez le client CSDS, qui utilise les identifiants générés par l'outil de ligne de commande gcloud. 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 v2 \
        -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 clients des clients connectés à Traffic Director. Ces valeurs sont fournies à l'aide du champ node id du fichier d'amorçage utilisé par Envoy ou gRPC sans proxy lorsqu'elles se connectent à Traffic Director.

Inspecter la configuration pour un client Traffic Director spécifique

Vous pouvez inspecter la configuration envoyée par Traffic Director à un client particulier à l'aide de l'ID du client, obtenu dans la section précédente.

Pour inspecter la configuration, procédez comme suit:

  1. Mettez à jour le fichier YAML que vous avez créé précédemment et définissez la valeur de node_id sur l'ID client:

      node_matchers:
        - node_id:
            exact: "CLIENT_ID" # e.g.,: "f38a59c1-4428-42f1-be81-e02eb994f9dd~10.128.0.6"
          node_metadatas:
            - path:
                - key: TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
              value:
                string_match:
                  exact: "PROJECT_NUMBER" # e.g.,: "314053285323"
            - path:
                - key: TRAFFICDIRECTOR_NETWORK_NAME
              value:
                string_match:
                  exact: "NETWORK_NAME" # e.g.,: "default"
      

  2. Exécutez le client CSDS. Cela génère un fichier JSON contenant la configuration envoyée au client Traffic Director.

    csds-client \
       -service_uri trafficdirector.googleapis.com:443 \
       -platform gcp \
       -authn_mode auto \
       -api_version v2 \
       -request_file PATH_TO_CSDS_REQUEST_YAML_FILE \
       -output_file FILENAME.json
    

    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 la configuration xDS détaillée en consultant le fichier .json. Cette sortie contient l'état des configurations xDS individuelles envoyées par Traffic Director au client à l'aide d'un flux gRPC agrégé (ADS).

Valeurs d'état

Voici les valeurs d'état de la configuration xDS que vous pourriez voir:

  • UNKNOWN (PAR DÉFAUT) : les informations sur l'état ne sont pas disponibles/inconnus.
  • SYNCED: ⁣Traffic Director a envoyé la configuration au client et a reçu un ACK du client.
  • ERROR: ⁣Traffic Director a envoyé la configuration au client et a reçu un NACK du client.
  • STALE: Traffic Director a envoyé la configuration au client, mais n'a reçu ni ACK ni 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 de 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. Le fichier README du dépôt Open Source contient plus d'informations sur ces fonctionnalités.

Message d'erreur

Vous pouvez voir le message d'erreur suivant du client CSDS si vous activez l'API Traffic Director uniquement dans votre projet:

rpc error: code = NotFound desc = Requested entity was not found.

Ce comportement est normal. La configuration de Traffic Director 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

  • Traffic Director n'est compatible qu'avec l'API CSDS v2.
  • 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 v2.
  • Si vous travaillez dans un environnement VPC partagé, vous devez spécifier le numéro du projet hôte et recevoir les autorisations appropriées sur le projet hôte pour utiliser l'outil.
  • L'ID de nœud de chaque client doit être unique au sein du 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 à Traffic Director.
  • Vous verrez parfois une barre oblique inverse (\) dans le champ "Identifiant du nœud" du fichier yaml. Dans ce cas, échappez la barre oblique inverse à l'aide d'une barre oblique inverse supplémentaire lorsque vous interrogez l'API CSDS pour obtenir des informations de configuration. C'est un problème connu.

Étape suivante

Pour en savoir plus sur le client CSDS, consultez les ressources suivantes: