Configurer la gestion avancée du trafic avec des services gRPC sans proxy

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Google Cloud et non avec les API Istio. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette configuration est compatible avec les clients Preview, mais nous ne la recommandons pas aux nouveaux utilisateurs de Cloud Service Mesh. Pour en savoir plus, consultez la présentation du routage des services Cloud Service Mesh.

Ce document fournit des instructions pour configurer Cloud Service Mesh avec les fonctionnalités de gestion du trafic suivantes:

• Mise en correspondance des routes
• Répartition du trafic
• Ruptures de circuit
• Injection de pannes
• Durée maximale du flux
• Réessayer
• Affinité de session
• Détection des anomalies
• Équilibrage de charge de la zone

Bien que ce document se concentre sur la configuration de la gestion avancée du trafic avec gRPC sans proxy sur Compute Engine, la gestion avancée du trafic est également disponible lorsque vous utilisez gRPC sans proxy sur Google Kubernetes Engine (GKE).

Avant de commencer

Avant de configurer la gestion avancée du trafic, examinez les conditions requises répertoriées dans la section Préparer la configuration de Cloud Service Mesh avec des services gRPC sans proxy. Vous ne pouvez configurer la gestion avancée du trafic que si toutes les conditions préalables sont remplies.

Pour obtenir des informations conceptuelles sur ces fonctionnalités, consultez la page sur la gestion avancée du trafic.

À propos de l'exemple de portefeuille gRPC

Pour illustrer ces fonctionnalités, vous devez déployer un exemple de portefeuille gRPC. Dans cet exemple, trois services gRPC, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats et grpc.examples.wallet.account.Account, sont déployés en tant qu'applications distinctes.

Comme le montre le schéma suivant, vous créez un client gRPC qui appelle le service Wallet, pour obtenir le solde d'un compte, et le service Stats pour obtenir la valeur d'une cryptomonnaie. Le service Wallet appelle les services Stats et Account pour calculer le solde. Le service Stats appelle également le service Account pour obtenir des informations sur l'utilisateur.

Exemple de configuration de routage du trafic de portefeuille gRPC (cliquez pour agrandir)

Dans cet exemple, vous déployez deux versions des implémentations de Wallet et de Stats pour illustrer le routage des requêtes en fonction des règles que vous configurez. Pour simuler la création et le déploiement de différentes versions d'un service, vous utilisez des options de serveur afin de modifier le comportement des binaires que vous compilez une seule fois.

• L'option --port spécifie le port d'écoute du service sur une instance de VM.
• L'option --hostname_suffix spécifie une valeur ajoutée au nom d'hôte de l'instance de VM qui répond à une requête. La valeur obtenue est ajoutée en tant que métadonnées hostname dans la réponse. Cela vous permet d'identifier, au sein d'un groupe d'instances, l'instance qui a répondu à la requête du client.
• L'option --premium_only avec la valeur true indique que le service est une version premium du service stats.
• L'option --v1_behavior avec la valeur true indique que le binaire du portefeuille se comporte comme une version v1.

Le tableau suivant indique les valeurs de ces options pour chaque instance de VM qui exécute l'un des services gRPC, le nombre d'instances dans un groupe d'instances et les services de backend auxquels ces groupes d'instances appartiennent.

Remarque : Par souci de concision, le préfixe et le suffixe communs dans les noms des services de backend et des groupes d'instances ne sont pas affichés. Par exemple, le service de backend grpcwallet-wallet-v1-service est indiqué sous la forme wallet-v1.

Service backend	Groupe d'instances	Instances	Options de serveur
account	account	2	--port=50053 --hostname_suffix="account"
stats	stats	2	--port=50052 --hostname_suffix="stats" --account_server="xds:///account.grpcwallet.io"
stats-premium	stats-premium	2	--port=50052 --hostname_suffix="stats_premium" --account_server="xds:///account.grpcwallet.io" --premium_only=true
wallet-v1 wallet-v1-affinity	wallet-v1	2	--port=50051 --hostname_suffix="wallet_v1" --v1_behavior=true --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"
wallet-v2	wallet-v2	1	--port=50051 --hostname_suffix "wallet_v2" --account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"

Une fois ces services déployés, configurez Cloud Service Mesh pour acheminer les requêtes vers ces services de backend à partir d'un client de test, en fonction des règles de routage du tableau suivant. Le client se connecte au nom d'hôte virtuel d'un service, comme indiqué dans la colonne Hôte.

Remarque : Le pseudo-en-tête HTTP/2 :path dans une requête gRPC est au format /ServiceName/MethodName, où ServiceName correspond au nom du service gRPC appelé dans la requête gRPC, et MethodName est la méthode dans ce service.

Hôte	Règles de correspondance	Action de routage
wallet.grpcwallet.io	Préfixe de chemin d'accès : "/" En-tête présent : "session_id"	Routage vers wallet-v1-affinity
	Préfixe de chemin d'accès : "/" En-tête : {"route": "timeout"}	Définition d'un délai d'expiration de cinq secondes et routage vers wallet-v2
	Préfixe de chemin d'accès : "/" En-tête : {"route": "fault"}	Échec de 50 % des requêtes et routage du reste vers wallet-v2
	Préfixe de chemin d'accès : "/" En-tête : {"membership": "premium"}	Routage vers wallet-v1 et jusqu'à trois nouvelles tentatives en cas d'échec
	Chemin complet : /grpc.examples.wallet.Wallet/FetchBalance	Routage vers : wallet-v1 : 70 % wallet-v2 : 30 %
	Par défaut	Routage vers wallet-v1
stats.grpcwallet.io	Préfixe de chemin d'accès : "/" En-tête : {"membership": "premium"}	Routage vers stats-premium
	Par défaut	Routage vers stats
account.grpcwallet.io	Préfixe de chemin d'accès : "/" En-tête : {"route": "account-fault"}	Échec de 30 % des requêtes et routage du reste vers account
	Par défaut	account

Cet exemple utilise une répartition du trafic à 70/30 entre deux services existants. Si vous répartissez le trafic vers un nouveau service qui n'a pas encore été référencé par le mappage d'URL, ajoutez d'abord le nouveau service à weightedBackendServices et attribuez-lui une pondération de 0. Ensuite, augmentez progressivement la pondération attribuée à ce service.

Le client de test dispose des options suivantes qui vous permettent de générer des requêtes appropriées pour démontrer les fonctionnalités de gestion du trafic.

Option	Description
--watch=true	Appeler des méthodes de streaming pour surveiller le solde/la valeur
--unary_watch=true	Appeler des méthodes unaires de manière répétée pour surveiller le solde ou la valeur
--user=Alice	Injecter l'en-tête {"membership": "premium"}
--user=Bob	Injecter l'en-tête {"membership": "normal"}
--route=value	Injecter l'en-tête {"route": "value"}
--affinity=true	Injecter l'en-tête {"session_id": "value"}

Préparer votre environnement local

Pour configurer l'environnement local pour ces exemples, exécutez les commandes suivantes :

1. Mettez à jour le binaire gcloud pour vous assurer que vous disposez de la dernière version :

   gcloud components update
   

2. Téléchargez le dépôt d'exemples :

   sudo apt-get install git -y
   

3. Clonez le dépôt approprié pour l'exemple :

   export EXAMPLES_VERSION=v1.1.x
   git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
     https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
   

Créer et configurer des instances Cloud Router

Dans cette section, vous allez créer des instances Cloud Router dans chaque région et les configurer pour Cloud NAT. Les VM créées dans cet exemple n'ont pas d'adresses IP externes, mais elles doivent avoir accès à Internet. La configuration de Cloud Router avec Cloud NAT fournit l'accès requis.

gcloud

1. Créez les instances Cloud Router. :

   gcloud compute routers create nat-router-us-central1 \
       --network=default \
       --region=us-central1
   

2. Configurez les routeurs pour Cloud NAT :

   gcloud compute routers nats create nat-config \
       --router-region=us-central1 \
       --router=nat-router-us-central1 \
       --nat-all-subnet-ip-ranges \
       --auto-allocate-nat-external-ips
   

Créer la vérification de l'état et la règle de pare-feu gRPC

Dans cette section, vous allez créer une vérification de l'état gRPC et une règle de pare-feu pour permettre aux requêtes de vérification d'état gRPC d'atteindre votre réseau. La vérification de l'état gRPC sera ensuite associée aux services de backend, afin qu'elle puisse vérifier l'état des instances backend de ces services de backend.

gcloud

1. Créez la vérification d'état :

   gcloud compute health-checks create grpc grpcwallet-health-check \
       --use-serving-port
   

2. Créez la règle de pare-feu pour la vérification de l'état :

   gcloud compute firewall-rules create grpcwallet-allow-health-checks \
       --network default --action allow --direction INGRESS \
       --source-ranges 35.191.0.0/16,130.211.0.0/22 \
       --target-tags allow-health-checks \
       --rules tcp:50051-50053
   

Créer le modèle d'instance

Dans cette section, vous créez un modèle d'instance pour déployer le service gRPC account exposé sur le port 50053.

gcloud

• Créez le modèle d'instance :

  gcloud compute instance-templates create grpcwallet-account-template \
     --scopes=https://www.googleapis.com/auth/cloud-platform \
     --tags=allow-health-checks \
     --network-interface=no-address \
     --image-family=debian-10 \
     --image-project=debian-cloud \
     --metadata-from-file=startup-script=<(echo "#! /bin/bash
  set -ex
  cd /root
  export HOME=/root
  sudo apt-get update -y
  pushd \$(mktemp -d)
  sudo apt-get install -y wget git
  wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz
  sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz
  sudo cp /usr/local/go/bin/go /usr/bin/go
  popd
  git clone -b $EXAMPLES_VERSION --single-branch --depth=1 https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
  cd traffic-director-grpc-examples/go/account_server/
  go build .
  sudo systemd-run ./account_server --port 50053 --hostname_suffix account")
  

Créer le groupe d'instances géré

Les groupes d'instances gérés (MIG) utilisent l'autoscaling pour créer des instances de VM en fonction des besoins. Dans cette section, vous créez un MIG à l'aide du modèle d'instance que vous avez créé à la section précédente.

gcloud

• Créez le groupe d'instances :

  gcloud compute instance-groups managed create grpcwallet-account-mig-us-central1 \
     --zone=us-central1-a \
     --size=2 \
     --template=grpcwallet-account-template
  

Configurer le port nommé

Dans cette section, vous configurez le port nommé pour le service gRPC. Le port nommé est le port sur lequel le service gRPC écoute les requêtes. Dans cet exemple, le port nommé est le port 50053.

gcloud

• Créez le port nommé :

  gcloud compute instance-groups set-named-ports grpcwallet-account-mig-us-central1 \
     --named-ports=grpcwallet-account-port:50053 \
     --zone=us-central1-a
  

Créez le service de backend :

Dans cette section, vous allez créer un service de backend global avec un schéma d'équilibrage de charge INTERNAL_SELF_MANAGED et le protocole GRPC. Vous allez ensuite associer la vérification d'état et le groupe d'instances au service de backend. Dans cet exemple, vous utilisez le MIG que vous avez créé dans la section Créer le groupe d'instances géré. Ce MIG exécute le service gRPC account. Le port correspondant à l'option --port-name est le port nommé que vous avez créé dans Configurer le port nommé.

gcloud

1. Créez le service de backend et associez la vérification de l'état au nouveau service de backend :

   gcloud compute backend-services create grpcwallet-account-service \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --protocol=GRPC \
       --port-name=grpcwallet-account-port \
       --health-checks=grpcwallet-health-check
   

2. Ajoutez le groupe d'instances géré en tant que backend :

   gcloud compute backend-services add-backend grpcwallet-account-service \
       --instance-group=grpcwallet-account-mig-us-central1 \
       --instance-group-zone=us-central1-a \
       --global
   

La procédure de création des services de backend restants utilisés dans l'exemple de portefeuille gRPC est semblable à celle décrite ci-dessus. Pour créer les services restants, exécutez un script shell. Le script déploie les services de backend suivants :

• stats
• stats-premium
• wallet-v1
• wallet-v1-affinity
• wallet-v2

Exécutez le script shell qui crée les services de backend supplémentaires :

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats '--account_server="xds:///account.grpcwallet.io"'

traffic-director-grpc-examples/scripts/create_service.sh go stats 50052 stats-premium '--account_server="xds:///account.grpcwallet.io" --premium_only=true'

# This command creates wallet-v1 and wallet-v1-affinity backend services.
traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v1 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io" --v1_behavior=true'

traffic-director-grpc-examples/scripts/create_service.sh java wallet 50051 wallet-v2 '--account_server="xds:///account.grpcwallet.io" --stats_server="xds:///stats.grpcwallet.io"'

Créer les règles de routage

Dans cette section, vous allez créer un mappage d'URL qui servira à illustrer diverses fonctionnalités de gestion du trafic. Le mappage d'URL spécifie les noms d'hôte virtuels des services de cet exemple, et les règles de routage associées. Pour plus d'informations, consultez la page sur les cartes des règles de routage.

Dans le mappage d'URL, hostRules spécifie les noms d'hôte virtuel des services de l'exemple. Il s'agit des noms qu'un client utilise dans l'URI du canal pour se connecter à un service spécifique. Par exemple, pour envoyer une requête au service account, un client utilise xds:///account.grpcwallet.io dans l'URI du canal. Dans le fichier hostRules, configurez une entrée hosts avec la valeur account.grpcwallet.io.

Le paramètre pathMatcher associé à une entrée hosts spécifie le nom de la ressource pathMatcher contenant toutes les règles de routage de cet hôte virtuel. Une configuration pathMatcher se compose de règles de correspondance et de règles d'action correspondantes, comme décrit dans la section À propos de l'exemple de portefeuille gRPC.

gcloud

Créez le mappage d'URL :

export PROJECT_ID=$(gcloud config list --format 'value(core.project)')
export BS_PREFIX=projects/$PROJECT_ID/global/backendServices/grpcwallet

gcloud compute url-maps import grpcwallet-url-map << EOF
name: grpcwallet-url-map
defaultService: $BS_PREFIX-account-service

hostRules:
- hosts:
  - account.grpcwallet.io
  pathMatcher: grpcwallet-account-path-matcher
- hosts:
  - stats.grpcwallet.io
  pathMatcher: grpcwallet-stats-path-matcher
- hosts:
  - wallet.grpcwallet.io
  pathMatcher: grpcwallet-wallet-path-matcher

pathMatchers:
- name: grpcwallet-account-path-matcher
  defaultService: $BS_PREFIX-account-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: account-fault
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-account-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 30

- name: grpcwallet-stats-path-matcher
  defaultService: $BS_PREFIX-stats-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 0
    service: $BS_PREFIX-stats-premium-service

- name: grpcwallet-wallet-path-matcher
  defaultService: $BS_PREFIX-wallet-v1-service
  routeRules:
  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: session_id
        presentMatch: true
    priority: 0
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-affinity-service
        weight: 100

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: timeout
    priority: 1
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      maxStreamDuration:
        seconds: 5

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: route
        exactMatch: fault
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
      faultInjectionPolicy:
        abort:
          httpStatus: 503
          percentage: 50

  - matchRules:
    - prefixMatch: /
      headerMatches:
      - headerName: membership
        exactMatch: premium
    priority: 3
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 100
      retryPolicy:
        retryConditions:
          - unavailable
        numRetries: 3

  - matchRules:
    - fullPathMatch: /grpc.examples.wallet.Wallet/FetchBalance
    priority: 4
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v1-service
        weight: 70
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 30

  - matchRules:
    - prefixMatch: /grpc.examples.wallet.Wallet/
    priority: 5
    routeAction:
      weightedBackendServices:
      - backendService: $BS_PREFIX-wallet-v2-service
        weight: 100
EOF

Créer le proxy cible et la règle de transfert

Dans cette section, vous créez le proxy gRPC cible et une règle de transfert.

Le proxy gRPC cible référence le mappage d'URL que vous avez créé à l'étape précédente. L'option --validate-for-proxyless active les vérifications de configuration afin de ne pas activer accidentellement une fonctionnalité qui n'est pas compatible avec les déploiements gRPC sans proxy.

gcloud

• Créez le proxy gRPC cible :

  gcloud compute target-grpc-proxies create grpcwallet-proxy \
     --url-map=grpcwallet-url-map \
     --validate-for-proxyless
  

La règle de transfert fait référence au proxy gRPC cible que vous avez créé. Le schéma d'équilibrage de charge est défini sur INTERNAL_SELF_MANAGED pour indiquer que cette règle de transfert est utilisée par Cloud Service Mesh. Il doit s'agir d'une règle de transfert globale. L'adresse IP est définie sur 0.0.0.0, car un client gRPC sans proxy résout le hostname:port dans l'URI cible en envoyant une requête LDS à Cloud Service Mesh au lieu d'effectuer une résolution DNS. Pour en savoir plus, consultez la section Schéma de résolution des noms.

Lorsqu'il n'y a pas de port spécifié dans l'URI cible, la valeur par défaut est 80. Par exemple, un URI cible xds:///foo.myservice:8080 correspond à une règle de transfert configurée avec le port 8080. Dans cet exemple, la règle de transfert est configurée avec le port 80.

gcloud

• Créez la règle de transfert :

  gcloud compute forwarding-rules create grpcwallet-forwarding-rule \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --address=0.0.0.0 \
     --address-region=us-central1 \
     --target-grpc-proxy=grpcwallet-proxy \
     --ports=80 \
     --network=default
  

Vérifier la configuration

Une fois le processus de configuration terminé, vérifiez que les services de backend que vous avez configurés sont disponibles en consultant la page Cloud Service Mesh dans la console Google Cloud. Vérifiez que les services de backend et les backends associés sont signalés comme étant opérationnels. L'actualisation de l'état peut prendre plusieurs minutes.

Vérifier la configuration du routage

Dans cette section, vous vérifiez que la configuration de routage fonctionne correctement. Utilisez l'outil grpcurl pour tester la configuration.

gcloud

1. Créez une VM cliente sur laquelle vous exécutez les clients pour tester le service. Vous pouvez également inclure l'option --network-interface=no-address.

   gcloud compute instances create grpc-wallet-client \
       --zone=us-central1-a \
       --scopes=https://www.googleapis.com/auth/cloud-platform \
       --image-family=debian-10 \
       --image-project=debian-cloud \
       --metadata-from-file=startup-script=<(echo '#! /bin/bash
   set -e
   export GRPC_XDS_BOOTSTRAP=/run/td-grpc-bootstrap.json
   # Expose bootstrap variable to SSH connections
   echo export GRPC_XDS_BOOTSTRAP=$GRPC_XDS_BOOTSTRAP | sudo tee /etc/profile.d/grpc-xds-bootstrap.sh
   # Create the bootstrap file
   curl -L https://storage.googleapis.com/traffic-director/td-grpc-bootstrap-0.16.0.tar.gz | tar -xz
   ./td-grpc-bootstrap-0.16.0/td-grpc-bootstrap | sudo tee $GRPC_XDS_BOOTSTRAP')
   

2. Accédez à la VM via SSH et exécutez les commandes suivantes pour la préparer :

   export EXAMPLES_VERSION=v1.1.x
   sudo apt-get update
   sudo apt-get install git -y
   

3. Exécutez les commandes suivantes :

   git clone -b $EXAMPLES_VERSION --single-branch --depth=1 \
      https://github.com/GoogleCloudPlatform/traffic-director-grpc-examples.git
   curl -L https://github.com/fullstorydev/grpcurl/releases/download/v1.6.1/grpcurl_1.6.1_linux_x86_64.tar.gz | tar -xz
   chmod +x grpcurl
   

Pour accéder aux services sans proxy side-car, le client gRPC doit utiliser le schéma de résolution de noms xds. Ce schéma indique à la bibliothèque gRPC utilisée dans le client qu'elle doit utiliser un serveur xDS pour résoudre le nom d'hôte. Pour ce faire, une configuration d'amorçage est nécessaire.

Le script de démarrage de la section précédente définit la variable d'environnement GRPC_XDS_BOOTSTRAP et utilise un script d'aide pour générer le fichier d'amorçage. Les valeurs de TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME et de la zone du fichier d'amorçage généré sont obtenues auprès du serveur de métadonnées qui connaissent ces détails sur vos instances de VM Compute Engine. Vous pouvez fournir manuellement ces valeurs au script d'aide en utilisant les options -gcp-project-number et -vpc-network-name.

Remarque :Conformément à nos règles, nous encourageons les utilisateurs à vérifier les mises à jour du générateur d'amorçage gRPC de TD une fois par an.

Vérifier la configuration à l'aide de l'outil grpcurl

Exécutez les commandes suivantes dans l'interface système SSH pour vérifier que les services wallet-service, stats-service et account-service sont en cours d'exécution :

./grpcurl -plaintext xds:///account.grpcwallet.io list
./grpcurl -plaintext -d '{"token": "2bd806c9"}' xds:///account.grpcwallet.io grpc.examples.wallet.account.Account/GetUserInfo
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' xds:///stats.grpcwallet.io grpc.examples.wallet.stats.Stats/FetchPrice
./grpcurl -plaintext -H 'authorization:2bd806c9' -H 'membership:premium' -d '{"include_balance_per_address": true}' xds:///wallet.grpcwallet.io grpc.examples.wallet.Wallet/FetchBalance

Les résultats suivants s'affichent :

grpc.examples.wallet.account.Account
grpc.health.v1.Health
grpc.reflection.v1alpha.ServerReflection

{
  "name": "Alice",
  "membership": "PREMIUM"
}

{
  "price": "10295"
}

{
  "balance": "5089953"
}

Vérifier avec les clients grpc-wallet

Suivez les instructions par langage ci-dessous pour vérifier la configuration. Les commandes envoient plusieurs RPC, certains avec des métadonnées supplémentaires, pour indiquer que les requêtes sont acheminées vers des services de backend en fonction des règles de correspondance du mappage d'URL. La commande imprime également le nom d'hôte de l'instance de VM pour chaque réponse, afin d'afficher l'instance de VM vers laquelle la requête a été acheminée.

Java

1. Pour vérifier le service avec un client Java gRPC, exécutez la commande suivante :

   sudo apt-get install -y openjdk-11-jdk-headless
   

2. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/java
   ./gradlew installDist
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests are
   # sent to 'wallet-v2'.
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium and Bob's go to regular.
   ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
   ./build/install/wallet/bin/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
   

Go

1. Pour vérifier le service avec un client Go gRPC, installez golang ou suivez les instructions officielles :

   sudo apt-get install -y wget
   wget https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz
   sudo tar -C /usr/local -xvf go1.16.5.linux-amd64.tar.gz
   sudo ln -s /usr/local/go/bin/go /usr/bin/go
   

2. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/go/wallet_client
   go build
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance' from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests
   # are sent to 'wallet-v2'.
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium and Bob's go to regular.
   ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Bob
   ./wallet_client price --stats_server="xds:///stats.grpcwallet.io" --watch --user=Alice
   

C++

1. Pour vérifier le service avec un client gRPC C++, exécutez la commande suivante :

   sudo apt-get install -y build-essential
   

2. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/cpp
   ../tools/bazel build :client
   
   # This command calls 'FetchBalance' from 'wallet-service' in a loop,
   # to demonstrate that 'FetchBalance' gets responses from 'wallet-v1' (70%)
   # and 'wallet-v2' (30%).
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob
   
   # This command calls the streaming RPC 'WatchBalance'  from 'wallet-service'.
   # The RPC path matches the service prefix, so all requests are sent to 'wallet-v2'.
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   
   # This command calls 'WatchPrice' from 'stats-service'. It sends the
   # user's membership (premium or not) in metadata. Premium requests are
   # all sent to 'stats-premium' and get faster responses. Alice's requests
   # always go to premium, and Bob's go to regular.
   ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Bob
   ../bazel-bin/cpp/client price --stats_server="xds:///stats.grpcwallet.io" --watch=true --user=Alice
   

Configurer d'autres options avancées

Vous pouvez configurer d'autres options avancées de routage du trafic en suivant les instructions des sections suivantes.

Ruptures de circuit

La rupture de circuit vous permet de définir des seuils de défaillance pour empêcher les requêtes client de surcharger vos services de backend. Une fois que le nombre de requêtes en attente atteint une limite que vous avez définie, le client arrête d'envoyer des requêtes supplémentaires, ce qui laisse le temps à vos services de backend de revenir à l'état normal de fonctionnement.

La rupture de circuit évite les défaillances en cascade en renvoyant une erreur au client plutôt que de surcharger un service de backend. Cela permet de diffuser du trafic tout en gérant la situation de surcharge. Ce fonctionnement est comparable à la gestion d'un pic de trafic via l'augmentation de la capacité (par le biais de l'autoscaling).

Lorsque vous créez le service de backend pour le service stats-service, le script create_service.sh inclut les lignes suivantes dans sa configuration :

circuitBreakers:
  maxRequests: 1

Ce paramètre limite les clients à une requête en attente à la fois sur le service stats-service. Étant donné qu'il n'y a qu'un seul service wallet-v2, l'exécution simultanée de deux opérations WatchBalance de client de portefeuille présente des défaillances en provenance de la deuxième instance.

Java

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob  2>/dev/null 1>/dev/null &
   
   sleep 10 # Wait a few seconds to allow the watch to begin.
   
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. La sortie ressemble à ceci :

   io.grpc.examples.wallet.Client run
   INFO: Will try to run balance
   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=INTERNAL, description=RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded, cause=null}
   

3. Exécutez la commande kill :

   kill %%
   

Go

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob 2> /dev/null 1> /dev/null &
   
   sleep 10 # Wait a few seconds to allow the watch to begin.
   
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   

2. La sortie ressemble à ceci :

   server host: error: no hostname
   failed to fetch balance: rpc error: code = Internal desc = RPC to stats server failed:
   UNAVAILABLE: Cluster max concurrent requests limit exceeded
   

3. Exécutez la commande kill :

   kill %%
   

C++

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob 2>/dev/null 1>/dev/null &
   
   sleep 10 # Wait a few seconds to allow the watch to begin.
   
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. La sortie ressemble à ceci :

   Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server:
   localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route:
   13: RPC to stats server failed: UNAVAILABLE: Cluster max concurrent requests limit exceeded
   

3. Exécutez la commande kill :

   kill %%
   

Injection de pannes

L'injection de pannes introduit des erreurs lors du traitement de requêtes afin de simuler des pannes, y compris une latence élevée, une surcharge du service, des défaillances du service et un partitionnement du réseau. Cette fonctionnalité est utile pour tester la résilience d'un service aux pannes simulées.

Lorsque vous avez créé le mappage d'URL précédemment, vous avez défini la règle d'injection de pannes sur 50 % des RPC envoyés à wallet.grpcwallet.io avec l'en-tête route=fault.

Pour démontrer l'injection de pannes, utilisez le code dans les langages suivants.

Java

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
   

2. La sortie ressemble à ceci :

   server host: grpcwallet-wallet-v2-mig-us-central1-zznc
   total balance: 10340491
   - address: 148de9c5, balance: 2549839
   - address: 2e7d2c03, balance: 7790652
   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=UNAVAILABLE, description=RPC terminated due to fault injection: HTTP status code 503, cause=null}
   

Go

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch --user=Bob --route=fault
   

2. La sortie ressemble à ceci :

    server host: grpcwallet-wallet-v1-mig-us-central1-bm1t_wallet-v1
    user: Bob, total grpc-coin balance: 10452589.
     - address: 2e7d2c03, balance: 7875108.
     - address: 148de9c5, balance: 2577481.
    failed to fetch balance: rpc error: code = Unavailable desc = RPC terminated due to fault injection
   

C++

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=fault
   

2. La sortie ressemble à ceci :

   Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io,
   stats_server: localhost:18882, user: Bob, watch: 0 ,unary_watch: 1, observability_project: ,
   route: fault server host: grpcwallet-wallet-v2-mig-us-central1-1lm6
   user: Bob total grpc-coin balance: 10211908
    - address: 148de9c5, balance: 2518132
    - address: 2e7d2c03, balance: 7693776
   14: Fault injected
   

Durée maximale du flux

La durée maximale du flux permet d'appliquer un délai maximal à tous les RPC. Vous évitez ainsi les cas où les clients oublient de définir un délai ou définissent un délai excessif, ce qui consomme inutilement les ressources du serveur.

Lorsque vous avez créé le mappage d'URL ci-dessus, vous avez défini une durée maximale de flux de cinq secondes pour les RPC envoyés à wallet.grpcwallet.io avec l'en-tête route=timeout.

Pour démontrer l'expiration de délai, nous devons d'abord arrêter le service wallet-v2.

gcloud

gcloud compute instance-groups managed resize \
    --size=0 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

La commande suivante serait bloquée indéfiniment, car il n'existe aucun service de backend à même de la gérer et l'application ne définit aucun délai.

Java

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. La commande cesse de répondre. Appuyez sur ^C pour interrompre la commande.

Go

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob
   

2. La commande cesse de répondre. Appuyez sur ^C pour interrompre la commande.

C++

1. Exécutez les commandes suivantes :

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

2. La commande cesse de répondre. Appuyez sur ^C pour interrompre la commande.

Cependant, la commande suivante qui utilise la route timeout échoue après cinq secondes en raison du paramètre maxStreamDuration.

Java

1. Exécutez la commande suivante :

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
   

2. La sortie ressemble à ceci :

   io.grpc.examples.wallet.Client run
   WARNING: RPC failed: Status{code=DEADLINE_EXCEEDED, description=deadline exceeded after 4.999594070s.         [wait_for_ready, buffered_nanos=5000553401, waiting_for_connection], cause=null}
   

Go

1. Exécutez la commande suivante :

   cd ~/traffic-director-grpc-examples/go/wallet_client
   ./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch --user=Bob --route=timeout
   

2. La sortie ressemble à ceci :

   failed to create stream: rpc error: code = DeadlineExceeded desc = context deadline exceeded.
   

C++

1. Exécutez la commande suivante :

   cd ~/traffic-director-grpc-examples/cpp
   ../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob --route=timeout
   

2. La sortie ressemble à ceci :

   Client arguments: command: balance, wallet_server: xds:///wallet.grpcwallet.io, stats_server:
   localhost:18882, user: Bob, watch: 1 ,unary_watch: 0, observability_project: , route: timeout
   4: Deadline Exceeded
   

Redémarrez le service wallet-v2.

gcloud

gcloud compute instance-groups managed resize \
    --size=1 grpcwallet-wallet-v2-mig-us-central1 \
    --zone=us-central1-a

Réessayer

Les nouvelles tentatives vous aident à améliorer la disponibilité des services en permettant à vos applications gRPC de relancer les requêtes sortantes en fonction d'une stratégie de nouvelle tentative. Dans une stratégie de nouvelle tentative, vous pouvez configurer les conditions dans lesquelles une requête échouée doit être relancée et le nombre maximal de nouvelles tentatives, par exemple lorsqu'une requête échoue avec un code de réponse particulier.

Lorsque vous avez créé le mappage d'URL précédemment, vous avez défini une stratégie de nouvelle tentative pour les RPC sur la méthode FetchBalance avec l'en-tête membership=premium. Cette stratégie relance jusqu'à trois fois les RPC qui échouent avec le code d'état unavailable. Vous avez également défini une règle d'injection de pannes pour les RPC sur account.grpcwallet.io avec l'en-tête route=account-fault, qui fait échouer 30 % des RPC du service Wallet vers le service Account. Par conséquent, 30 % des RPC du client de test avec l'en-tête membership=normal vont échouer, alors que le taux d'échec pour les RPC avec l'en-tête membership=premium est inférieur à 1 %.

Pour illustrer les nouvelles tentatives, utilisez le code dans les langages suivants.

Java

Exécutez les commandes suivantes :

cd ~/traffic-director-grpc-examples/java
# 30% of the requests fail because Bob is a normal user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

Go

Exécutez les commandes suivantes :

cd ~/traffic-director-grpc-examples/go/wallet_client
# 30% of the requests fail because Bob is a normal user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

C++

Exécutez les commandes suivantes :

cd ~/traffic-director-grpc-examples/cpp
# 30% of the requests fail because Bob is a normal user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Bob --route=account-fault
# Less than 1% of the requests fail because Alice is a premium user.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --route=account-fault

Affinité de session

L'affinité de session consiste en une tentative la plus optimale possible d'envoi de requêtes ayant des caractéristiques particulières (en-têtes HTTP) à la même instance, tant que celle-ci est opérationnelle et qu'elle dispose d'une capacité suffisante. Cela s'avère utile pour les serveurs d'applications avec état qui bénéficient de performances et d'une efficacité améliorées lorsque les requêtes d'un client particulier sont envoyées à la même instance, plutôt que d'effectuer par exemple une distribution round-robin vers différentes instances.

Remarque :Un client gRPC qui n'est pas compatible avec la règle d'équilibrage de charge RING_HASH va renvoyer un accusé de réception négatif (NACK) sur la configuration de Cloud Service Mesh lorsqu'un mappage d'URL fait référence à un service de backend avec localityLbPolicy=RING_HASH. Le canal client passe alors à un état d'erreur transitoire jusqu'à ce que la configuration soit corrigée. Pour en savoir plus, consultez la section Limitation des services de backend.

Lorsque vous avez créé le service de backend grpcwallet-wallet-v1-affinity-service, dans le script create_service.sh, localityLbPolicy a été défini sur ROUND_ROBIN. Dans cet exemple, vous allez appliquer la configuration suivante pour définir localityLbPolicy sur RING_HASH.

sessionAffinity: HEADER_FIELD
localityLbPolicy: RING_HASH
consistentHash:
  httpHeaderName: "session_id"

gcloud

1. Enregistrez la configuration du service de backend grpcwallet-wallet-v1-affinity-service :

   gcloud compute backend-services export grpcwallet-wallet-v1-affinity-service \
    --destination=bs_config.yaml \
    --global
   

2. Mettez à jour le service de backend grpcwallet-wallet-v1-affinity-service :

   project_id="$(gcloud config list --format 'value(core.project)')"
   backend_config="
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: projects/${project_id}/zones/us-central1-a/instanceGroups/grpcwallet-wallet-v1-mig-us-central1
   connectionDraining:
     drainingTimeoutSec: 0
   healthChecks:
   - projects/${project_id}/global/healthChecks/grpcwallet-health-check
   loadBalancingScheme: INTERNAL_SELF_MANAGED
   name: grpcwallet-wallet-v1-affinity-service
   portName: grpcwallet-wallet-port
   protocol: GRPC
   sessionAffinity: HEADER_FIELD
   localityLbPolicy: RING_HASH
   consistentHash:
     httpHeaderName: session_id"
   gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service --global <<< "${backend_config}"
   

Remarque : La mise à jour du service de backend peut prendre plusieurs minutes pour se propager aux clients.

Pour démontrer l'affinité de session, utilisez le code dans les langages suivants. Avec l'option --affinity=true, le client insère un en-tête session-id avec une valeur unique pour chaque utilisateur. Un hachage de cette valeur est utilisé pour envoyer la requête à une instance particulière du groupe d'instances du service de backend grpcwallet-wallet-v1-affinity-service.

Java

Exécutez les commandes suivantes :

cd ~/traffic-director-grpc-examples/java
# Without affinity, requests are sent to both instances.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

Go

Exécutez les commandes suivantes :

cd ~/traffic-director-grpc-examples/go/wallet_client
# Without affinity, requests are sent to both instances.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
./wallet_client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

C++

Exécutez les commandes suivantes :

cd ~/traffic-director-grpc-examples/cpp
# Without affinity, requests are sent to both instances.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice
# With affinity, requests are sent to only one instance.
../bazel-bin/cpp/client balance --wallet_server="xds:///wallet.grpcwallet.io" --unary_watch=true --user=Alice --affinity=true

Restaurez la configuration du service de backend grpcwallet-wallet-v1-affinity-service.

gcloud

gcloud compute backend-services import grpcwallet-wallet-v1-affinity-service \
  --source=bs_config.yaml \
  --global

Détection des anomalies

Pour améliorer la disponibilité du service, configurez la détection des anomalies. Cette fonctionnalité vous permet d'identifier et d'éjecter temporairement les hôtes défaillants du pool d'équilibrage de charge. Ces hôtes non fiables sont appelés valeurs aberrantes.

gRPC évalue les hôtes en fonction du taux de réussite, c'est-à-dire de la fréquence à laquelle un hôte traite les requêtes. Le taux est affecté par les échecs tels que les erreurs gRPC, les erreurs HTTP, les délais avant expiration et d'autres problèmes.

Lorsque vous configurez la détection d'anomalies via Cloud Service Mesh, vous pouvez affiner la façon dont gRPC évalue les hôtes et gère les anomalies. Par exemple, vous pouvez spécifier des critères tels que les suivants:

• Nombre de requêtes qu'un hôte doit recevoir avant que gRPC l'analyse pour déterminer s'il s'agit d'une valeur aberrante.

• Extent to which an host can deviate from the mean success rate before it's considered an outlier.

• Pourcentage maximal d'hôtes pouvant être exclus à la fois du pool d'équilibrage de charge.

• Durée pendant laquelle une anomalie est exclue du pool d'équilibrage de charge.

Pour en savoir plus sur les paramètres disponibles, consultez la documentation de référence sur REST Resource: backendServices. Toutefois, gRPC présente certaines limites, comme décrit dans la section suivante.

Limites

Les champs suivants ne sont pas acceptés pour les clients gRPC:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Configurer la détection des anomalies

La procédure suivante montre comment configurer la détection des anomalies pour un service qui utilise un groupe d'instances en tant que backend. Cette procédure établit la configuration suivante:

• L'analyse de détection des anomalies s'exécute toutes les secondes. Vous configurez ce comportement à l'aide du champ interval.
• Les valeurs aberrantes sont exclues du pool d'équilibrage de charge par incréments de 30 secondes, comme suit :
  • Si un hôte n'a jamais été éjecté auparavant, il n'est éjecté que pendant 30 secondes.
  • Si un hôte a déjà été éjecté, le délai est augmenté de 30 secondes pour chaque éjection précédente. Par exemple, lorsqu'un hôte est éjecté pour la troisième fois, il est éjecté pendant 90 secondes. Vous configurez ce comportement à l'aide du champ baseEjectionTime.
• Un hôte est considéré comme non opérationnel si son taux de réussite est inférieur à la moyenne d'une déviation standard pendant l'intervalle de temps sélectionné (dans ce cas, une seconde). Vous configurez l'écart type maximal à l'aide du champ successRateStdevFactor.

Pour configurer la détection des anomalies de cette manière, procédez comme suit.

gcloud

1. Exportez le fichier de configuration du service de backend grpcwallet-wallet-v2-service à l'aide de la commande gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
    --destination=bs_config.yaml \
    --global
   

2. Dans le fichier bs_config.yaml, mettez à jour la configuration grpcwallet-wallet-v2-service pour inclure les champs de détection des valeurs aberrantes:

   outlierDetection:
    interval:
      seconds: 1
      nanos: 0
    baseEjectionTime:
      seconds: 30
      nanos: 0
    successRateStdevFactor: 1000
   

3. Importez le fichier mis à jour à l'aide de la commande gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service \
    --source=bs_config.yaml \
    --global

Remarque :L'exemple de portefeuille n'est pas conçu pour inclure des hôtes défaillants. Pour cette raison, les hôtes grpcwallet-wallet-v2-service ne sont généralement pas supprimés, même si vous configurez correctement la détection des anomalies.

Équilibrage de charge de la zone

Pour utiliser vos ressources de manière optimale, configurez l'équilibrage de charge de la zone. Cette fonctionnalité vous aide à préserver vos ressources en répartissant uniformément les requêtes client entre vos backends.

Lorsque vous configurez l'équilibrage de charge par localité, vous pouvez utiliser les options décrites dans le tableau suivant. Toutes les options nécessitent de configurer la ressource backendServices.

Option	Disponible pour	Champ de configuration pertinent
Utiliser une règle intégrée	Tous les clients gRPC	localityLbPolicy
Utiliser une règle personnalisée	Clients Java qui utilisent gRPC version 1.47 ou ultérieure, dans un réseau maillé qui n'inclut que des clients gRPC	localityLbPolicies
Définir une liste de stratégies préférées	Clients Java qui utilisent gRPC version 1.47 ou ultérieure, dans un réseau maillé qui n'inclut que des clients gRPC	localityLbPolicies

Vous pouvez utiliser n'importe quelle combinaison des options précédentes. Toutefois, si vous configurez à la fois localityLbPolicy et localityLbPolicies, gRPC tente d'abord d'utiliser votre configuration localityLbPolicies.

Si vous ne configurez pas l'équilibrage de charge par localité, Cloud Service Mesh utilise la règle ROUND_ROBIN.

Pour en savoir plus sur ROUND_ROBIN et les autres règles intégrées, consultez la description de localityLbPolicy sur la page backendServices.

Utiliser une règle intégrée

Si vous souhaitez que tous vos clients utilisent une seule règle intégrée, vous pouvez la sélectionner en configurant le champ localityLbPolicy.

Lorsque vous configurez ce champ, vous avez le choix entre les règles suivantes:

• LEAST_REQUEST (clients Java uniquement)
• RING_HASH
• ROUND_ROBIN

Si tous vos clients ne peuvent pas utiliser la même stratégie, consultez la section Définir une liste de stratégies préférées.

gcloud

1. Exportez le fichier de configuration du service de backend grpcwallet-wallet-v2-service à l'aide de la commande gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
   --destination=bs_config.yaml \
   --global
   

2. Mettez à jour le fichier bs_config.yaml exporté pour inclure les lignes suivantes:

   localityLbPolicy:
    -- policy
       name: RING_HASH
   

3. Importez le fichier mis à jour à l'aide de la commande gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

Utiliser une règle personnalisée

Le cas échéant, vous pouvez utiliser une règle d'équilibrage de charge personnalisée que vous avez créée et déployée avec gRPC. Cette fonctionnalité est disponible pour les clients Java qui utilisent gRPC version 1.47 ou ultérieure. N'utilisez-le que dans un maillage qui inclut tous les clients gRPC.

Lorsque vous créez une règle personnalisée, la documentation suivante peut vous être utile:

• Pour rendre votre règle personnalisée plus sophistiquée, vous pouvez utiliser les API Open Request Cost Aggregation (ORCA). Ces API vous permettent de capturer des métriques sur le coût des requêtes et l'utilisation des serveurs. L'utilisation de ces API nécessite gRPC version 1.48.1 ou ultérieure. Pour en savoir plus, consultez l'exemple gRPC ORCA.

• Pour en savoir plus sur la façon dont les configurations d'équilibrage de charge personnalisées sont transmises à gRPC par xDS, consultez la section Configuration de l'équilibreur de charge personnalisé gRPC xDS.

Pour configurer Cloud Service Mesh pour qu'il utilise votre stratégie personnalisée, identifiez-la à l'aide du champ localityLbPolicies.

La procédure suivante illustre ce processus. Dans cette procédure, vous mettez à jour la configuration du service de backend grpcwallet-wallet-v2-service afin que les clients qui s'y connectent utilisent une règle personnalisée appelée example.ExampleLoadBalancer.

Attention :Cette fonctionnalité est destinée à être utilisée dans un service mesh qui n'inclut que des clients gRPC. Les proxys Envoy ne peuvent pas utiliser les services de backend qui ont cette configuration.

gcloud

1. Exportez le fichier de configuration du service de backend grpcwallet-wallet-v2-service à l'aide de la commande gcloud compute backend-services export:

   gcloud compute backend-services export grpcwallet-wallet-v2-service \
   --destination=bs_config.yaml \
   --global
   

2. Mettez à jour le fichier bs_config.yaml exporté pour référencer la stratégie example.ExampleLoadBalancer. Incluez les lignes suivantes:

   localityLbPolicies:
     - customPolicy:
         name: example.ExampleLoadBalancer
         data: '{ "message": "Hello load-balancing world!" }'
   

3. Importez le fichier mis à jour à l'aide de la commande gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

4. Facultatif: Testez la configuration de l'équilibrage de charge:

   Java

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

   Si vous avez correctement configuré la règle d'équilibrage de charge personnalisée, le message que vous avez inclus dans la configuration s'affiche ("Hello load-balancing world!").

Définir une liste de règles préférées

Si plusieurs clients ne sont pas tous compatibles avec une seule stratégie d'équilibrage de charge, créez une liste des stratégies que vos clients peuvent utiliser. Avec cette option, si la première règle préférée ne peut pas être utilisée par un client particulier, gRPC utilise la règle suivante de la liste.

Lorsque vous créez une liste de règles préférées, les options valides incluent les règles personnalisées, ROUND_ROBIN et, pour les clients Java, LEAST_REQUEST. Vous pouvez lister jusqu'à 10 règles.

Cette fonctionnalité n'est disponible que pour les clients Java qui utilisent gRPC version 1.47 ou ultérieure. N'utilisez-le que dans un maillage qui inclut tous les clients gRPC.

Attention :Cette fonctionnalité est destinée à être utilisée dans un service mesh qui n'inclut que des clients gRPC. Les proxys Envoy ne peuvent pas utiliser les services de backend qui ont cette configuration.

gcloud

1. Exportez le fichier de configuration du service de backend grpcwallet-wallet-v2-service à l'aide de la commande gcloud compute backend-services export:

gcloud compute backend-services export grpcwallet-wallet-v2-service \
  --destination=bs_config.yaml \
  --global

1. Mettez à jour le fichier bs_config.yaml exporté pour inclure le champ localityLbPolicies. Remplissez-le avec des entrées qui représentent les règles suivantes:

   • Règle personnalisée non valide (example.InvalidLoadBalancer)
   • Une règle personnalisée valide (example.ExampleLoadBalancer)
   • Une règle intégrée compatible (LEAST_REQUEST)

   localityLbPolicies:
     - customPolicy:
         name: example.InvalidLoadBalancer
         data: '{ "message": "This load-balancing policy doesn't work!" }'
     - customPolicy:
         name: example.ExampleLoadBalancer
         data: '{ "message": "Hello load-balancing world!" }'
     - policy:
         name: LEAST_REQUEST
   

2. Importez le fichier mis à jour à l'aide de la commande gcloud compute backend-services import:

   gcloud compute backend-services import grpcwallet-wallet-v2-service --source=bs_config.yaml --global
   

3. Facultatif: Testez la configuration de l'équilibrage de charge:

   Java

   cd ~/traffic-director-grpc-examples/java
   ./build/install/wallet/bin/client balance --wallet_server="xds:///wallet.grpcwallet.io" --watch=true --user=Bob
   

   En réponse, gRPC tente de trouver example.InvalidLoadBalancer, mais échoue. Par la suite, il revient à l'utilisation de example.ExampleLoadBalancer, et le message que vous avez inclus dans la configuration ("Hello load-balancing world!") s'affiche. La journalisation gRPC sur le client inclut un message indiquant que example.InvalidLoadBalancer n'a pas été trouvé.

Nettoyer les ressources

Pour nettoyer les ressources, exécutez la commande suivante à partir de votre système local :

traffic-director-grpc-examples/scripts/cleanup.sh

Bloquer le trafic entre les services

Si vous souhaitez bloquer le trafic entre le service A et le service B, et que votre déploiement se trouve sur GKE, configurez la sécurité du service et utilisez une règle d'autorisation pour bloquer le trafic entre les services. Pour obtenir des instructions complètes, consultez la page Sécurité du service Cloud Service Mesh et les instructions de configuration avec Envoy et gRPC sans proxy.

Étape suivante

• Pour vous aider à résoudre les problèmes de configuration de Cloud Service Mesh, consultez la page Résoudre les problèmes de déploiement qui utilisent gRPC sans proxy.