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

Ce document fournit des instructions pour configurer Traffic Director avec les fonctionnalités suivantes de gestion du trafic :

  • 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 Traffic Director 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.
Exemple de configuration de routage du trafic de Wallet gRPC (cliquez pour agrandir)

Dans cet exemple, vous déployez deux versions des mises en œuvre 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.

Service de 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 Traffic Director 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.

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: "/"
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: "/"
En-tête: {"route": "fault"}
Échec de 50 % des requêtes et
routage du reste vers wallet-v2
Préfixe de chemin: "/"
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 Acheminer vers:
wallet-v1: 70%
wallet-v2: 30%
Par défaut Routage vers wallet-v1
stats.grpcwallet.io Préfixe de chemin: "/"
En-tête: {"membership": "premium"}
Routage vers stats-premium
Par défaut Routage vers stats
account.grpcwallet.io Préfixe de chemin: "/"
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 Traffic Director. 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 à Traffic Director 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 Traffic Director dans Google Cloud Console. 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.11.0.tar.gz | tar -xz
    ./td-grpc-bootstrap-0.11.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.

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.

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}"
    

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'exclure temporairement les hôtes non opérationnels du pool d'équilibrage de charge. Ces hôtes non opérationnels sont appelés anomalies.

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. Ce 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 des anomalies via Traffic Director, vous pouvez affiner la manière 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étecter un éventuel état d'anomalie.

  • La mesure dans laquelle un hôte peut s'écarter du taux de réussite moyen avant d'être considéré comme une valeur aberrante.

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

  • 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 compatibles avec 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 d'anomalies pour un service qui utilise un groupe d'instances comme 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 anomalies sont exclues du pool d'équilibrage de charge par incréments de 30 secondes, comme suit :
    • Si un hôte n'a jamais été exclu, il n'est exclu que pendant 30 secondes.
    • Si un hôte a déjà été exclu, le temps augmente de 30 secondes pour chaque exclusion précédente. Par exemple, lorsqu'un hôte est exclu une troisième fois, il est exclu pendant 90 secondes. Ce comportement est configuré à l'aide du champ baseEjectionTime.
  • Un hôte est considéré comme non opérationnel si son taux de réussite est inférieur d'un écart type à la moyenne 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 anomalies:

    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

Équilibrage de charge de la zone

Pour utiliser au mieux vos ressources, configurez l'équilibrage de charge par localité. Cette fonctionnalité vous aide à préserver les ressources en répartissant équitablement les requêtes client entre vos backends.

Lorsque vous configurez l'équilibrage de charge de localité, vous pouvez utiliser les options décrites dans le tableau suivant. Toutes les options nécessitent que vous configuriez 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 utilisant gRPC version 1.47 ou ultérieure, dans un maillage comprenant uniquement des clients gRPC localityLbPolicies
Définir une liste de stratégies préférées Clients Java utilisant gRPC version 1.47 ou ultérieure, dans un maillage comprenant uniquement des clients gRPC localityLbPolicies

Vous pouvez combiner les options précédentes comme vous le souhaitez. 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 de localité, Traffic Director 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 pouvez choisir parmi 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 Définir une liste de règles 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 des règles personnalisées

Si nécessaire, 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 en version 1.47 ou ultérieure. Utilisez-le uniquement dans un maillage incluant tous les clients gRPC.

Lors de la création d'une règle personnalisée, la documentation suivante peut vous être utile:

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

  • Pour en savoir plus sur la diffusion des configurations d'équilibrage de charge personnalisées à gRPC par xDS, consultez la section Configuration de l'équilibreur de charge personnalisé de gRPC xDS.

Pour configurer Traffic Director afin qu'il utilise votre règle personnalisée, identifiez la règle à l'aide du champ localityLbPolicies.

Les étapes suivantes illustrent ce processus. Dans cette procédure, vous allez mettre à 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.

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 règle 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 ("Hello load-Balance world!" s'affiche) s'affiche.

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

Si plusieurs de vos clients n'acceptent pas tous une seule règle d'équilibrage de charge, créez une liste de règles que vos clients peuvent utiliser. Avec cette option, si votre première stratégie préférée ne peut pas être utilisée par un client particulier, gRPC passe à la stratégie suivante dans la liste.

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

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

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 le champ localityLbPolicies. Remplissez-le avec des entrées représentant les règles suivantes:

    • Une 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
    
  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
    

    En réponse, gRPC tente sans succès de trouver example.InvalidLoadBalancer. Ensuite, il revient à l'utilisation de example.ExampleLoadBalancer et le message que vous avez inclus dans la configuration ("Hello load-balancer world!" s'affiche) s'affiche. La journalisation gRPC sur le client inclut un message indiquant que example.InvalidLoadBalancer est introuvable.

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 Traffic Director et les instructions de configuration avec Envoy et gRPC sans proxy.

Étapes suivantes