Configura la administración avanzada del tráfico con servicios de gRPC sin proxy

Esta configuración es compatible con los clientes de la versión preliminar, pero no la recomendamos para los usuarios nuevos de Cloud Service Mesh. Para obtener más información, consulta la descripción general del enrutamiento de servicios de Cloud Service Mesh.

En este documento, se proporcionan instrucciones para configurar Cloud Service Mesh con las siguientes funciones de administración del tráfico:

• Coincidencia de ruta
• División del tráfico
• Disyuntores
• Inyección de fallas
• Duración máxima de la transmisión
• Reintentar
• Afinidad de sesión
• Detección de valores atípicos
• Balanceo de cargas de localidad

Si bien este documento se centra en la configuración de la administración avanzada del tráfico con gRPC sin proxy en Compute Engine, la administración avanzada del tráfico también es compatible cuando usas gRPC sin proxy en Google Kubernetes Engine (GKE).

Antes de comenzar

Antes de configurar la administración avanzada de tráfico, revisa los requisitos en Prepárate para configurar la malla de servicios de Cloud con servicios de gRPC sin proxy. No puedes configurar la administración avanzada de tráfico, a menos que se cumplan todos los requisitos.

Para obtener información conceptual sobre estas características, consulta Administración avanzada del tráfico.

Acerca del ejemplo de Wallet de gRPC

Para ilustrar estas características, implementa un ejemplo de Wallet de gRPC. En este ejemplo, hay tres servicios de gRPC, grpc.examples.wallet.Wallet, grpc.examples.wallet.stats.Stats y grpc.examples.wallet.account.Account, que se implementan como tres aplicaciones diferentes.

Como se muestra en el siguiente diagrama, creas un cliente de gRPC que llama al servicio Wallet para obtener el saldo de una cuenta y al servicio Stats para de obtener el precio de una moneda. El servicio Wallet llama a los servicios Stats y Account para calcular el saldo. El servicio Stats también llama al servicio Account para obtener información del usuario.

En el ejemplo, implementas dos versiones de las implementaciones Wallet y Stats para ilustrar el enrutamiento de solicitudes según las reglas que configures. Para simular la compilación y la implementación de diferentes versiones de un servicio, usa las marcas del servidor a fin de cambiar el comportamiento de los objetos binarios que compilas una sola vez.

• La marca --port especifica el puerto en el que escucha el servicio en una instancia de VM.
• La marca --hostname_suffix especifica un valor que se agrega al nombre de host de la instancia de VM que responde a una solicitud. El valor resultante se agrega como los metadatos hostname en la respuesta. Esto te ayuda a identificar qué instancia de un grupo de instancias respondió a la solicitud del cliente.
• La marca --premium_only con el valor true especifica que el servicio es una versión premium del servicio stats.
• La marca --v1_behavior con el valor true especifica que el objeto binario de Wallet se comporta como una versión v1.

En la siguiente tabla, se muestran los valores de estas marcas para cada instancia de VM que ejecuta uno de los servicios de gRPC, la cantidad de instancias en un grupo de instancias y los servicios de backend a los que pertenecen estos grupos de instancias.

Después de implementar estos servicios, configura Cloud Service Mesh para que enrute las solicitudes a estos servicios de backend desde un cliente de prueba según las reglas de enrutamiento de la siguiente tabla. El cliente se conecta al nombre de host virtual de un servicio, como se muestra en la columna de host.

En este ejemplo, se usa una división del tráfico de 70/30 entre dos servicios existentes. Si divides el tráfico a un servicio nuevo al que no se ha hecho referencia en el mapa de URL antes, primero agrega el servicio nuevo a weightedBackendServices y asígnale un peso de 0. Luego, aumenta de forma gradual el peso asignado a ese servicio.

El cliente de prueba tiene las siguientes opciones que te permiten generar solicitudes adecuadas para demostrar las funciones de administración de tráfico.

Prepara el entorno local

A fin de configurar el entorno local para estos ejemplos, ejecuta los siguientes comandos:

1. Actualiza el objeto binario gcloud para asegurarte de tener la versión más reciente:

   gcloud components update
   

2. Descarga el repositorio de ejemplos:

   sudo apt-get install git -y
   

3. Clona el repositorio correcto para el ejemplo:

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

Crea y configura instancias de Cloud Router

En esta sección, crearás instancias de Cloud Router en cada región y las configurarás para Cloud NAT. Las VMs creadas en este ejemplo no tienen direcciones IP externas, pero necesitan tener acceso a Internet. La configuración de Cloud Router con Cloud NAT proporciona el acceso requerido.

Crea la verificación de estado de gRPC y la regla de firewall

En esta sección, crearás una verificación de estado de gRPC y una regla de firewall para permitir que las solicitudes de verificación de estado de gRPC lleguen a tu red. Luego, se asocia la verificación de estado de gRPC a los servicios de backend para verificar el estado de los backends en esos servicios de backend.

Crea la plantilla de instancias.

En esta sección, crearás una plantilla de instancias para implementar el servicio de gRPC account que se expone en el puerto 50053.

Crea el grupo de instancias administrado

Los grupos de instancias administrados (MIG) usan el ajuste de escala automático para crear instancias de VM nuevas según sea necesario. En esta sección, crearás un MIG mediante la plantilla de instancias que creaste en la sección anterior.

Configura el puerto con nombre

En esta sección, configurarás el puerto con nombre para el servicio de gRPC. El puerto con nombre es el puerto en el que el servicio de gRPC escucha las solicitudes. En este ejemplo, el puerto con nombre es el puerto 50053.

Crea el servicio de backend.

En esta sección, crearás un servicio de backend global con un esquema de balanceo de cargas de INTERNAL_SELF_MANAGED y el protocolo GRPC. Luego, asociarás la verificación de estado y el grupo de instancias con el servicio de backend. En este ejemplo, usarás el MIG que creaste en Crea el grupo de instancias administrado. Este MIG ejecuta el servicio de gRPC account. El puerto en la marca --port-name es el puerto con nombre que creaste en Configura el puerto con nombre.

Los pasos para crear los servicios de backend restantes que se usan en el ejemplo de Wallet de gRPC son similares a los pasos anteriores. Crea los servicios restantes mediante la ejecución de una secuencia de comandos de shell. La secuencia de comandos implementa los siguientes servicios de backend:

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

Ejecuta la secuencia de comandos de shell que crea los servicios de backend adicionales:

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

Crea las reglas de enrutamiento

En esta sección, crearás un mapa de URL que se usa para demostrar varias funciones de administración del tráfico. El mapa de URL especifica los nombres de host virtuales de los servicios de este ejemplo y las reglas de enrutamiento asociadas. Para obtener más información, consulta Mapas de reglas de enrutamiento.

En el mapa de URL, hostRules especifica los nombres de host virtuales de los servicios del ejemplo. Estos son los nombres que un cliente usa en el URI del canal para conectarse a un servicio específico. Por ejemplo, para enviar una solicitud al servicio account, un cliente usa xds:///account.grpcwallet.io en el URI del canal. En hostRules, configura una entrada hosts con el valor account.grpcwallet.io.

El pathMatcher asociado con una entrada de hosts especifica el nombre de un pathMatcher que contiene todas las reglas de enrutamiento para ese host virtual. ApathMatcher consiste en reglas de coincidencia y reglas de acción correspondientes, como se describe enAcerca del ejemplo de Billet de gRPC.

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

Crea el proxy de destino y la regla de reenvío

En esta sección, crearás el proxy de gRPC de destino y una regla de reenvío.

El proxy de gRPC de destino hace referencia al mapa de URL que creaste en el paso anterior. Con la marca --validate-for-proxyless, se habilitan las verificaciones de configuración para que no habilites de manera accidental una función que no sea compatible con implementaciones de gRPC sin proxy.

La regla de reenvío hace referencia al proxy de gRPC de destino que creaste. El esquema de balanceo de cargas se establece en INTERNAL_SELF_MANAGED para indicar que Cloud Service Mesh usa esta regla de reenvío. Debe ser una regla de reenvío global. La dirección IP se configura como 0.0.0.0 porque un cliente de gRPC sin proxy resuelve el hostname:port en el URI de destino mediante el envío de una solicitud LDS a la malla de servicios de Cloud en lugar de realizar una búsqueda de DNS. Para obtener más información, consulta Esquema de resolución de nombres.

Cuando no se especifica un puerto en el URI de destino, el valor predeterminado es 80. Por ejemplo, un URI de destino xds:///foo.myservice:8080 coincide con una regla de reenvío configurada con el puerto 8080. En este ejemplo, la regla de reenvío se configura con el puerto 80.

Verifica la configuración

Cuando se complete el proceso de configuración, verifica que los servicios de backend que configuraste estén disponibles. Para ello, revisa la página de Cloud Service Mesh en la consola de Google Cloud. Confirma que los servicios de backend y los backends asociados estén en buen estado. Esto puede tardar varios minutos.

Verifica la configuración de enrutamiento

En esta sección, verificarás que la configuración de enrutamiento funcione de forma correcta. Usa la herramienta de grpcurl para probar la configuración.

Para acceder a los servicios sin un proxy de sidecar, el cliente de gRPC debe usar el esquema de resolución de nombres de xds. Este esquema indica a la biblioteca de gRPC que se usa en el cliente que debe usar un servidor xDS para resolver el nombre de host. Para ello, se requiere una configuración de arranque.

La secuencia de comandos de inicio de la sección anterior configura la variable de entorno GRPC_XDS_BOOTSTRAP y usa una secuencia de comandos auxiliar para generar el archivo de arranque. Los valores para TRAFFICDIRECTOR_GCP_PROJECT_NUMBER, TRAFFICDIRECTOR_NETWORK_NAME y la zona del archivo de arranque generado se obtienen del servidor de metadatos que conoce estos detalles de las instancias de VM de Compute Engine. Puedes proporcionar estos valores a la secuencia de comandos auxiliar de forma manual con las opciones -gcp-project-number y -vpc-network-name.

Verifica la configuración mediante la herramienta de grpcurl

Ejecuta los siguientes comandos en la shell de SSH para verificar que wallet-service, stats-service y account-service estén en ejecución:

./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

Verás los siguientes resultados:

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

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

{
  "price": "10295"
}

{
  "balance": "5089953"
}

Verifica con los clientes grpc-wallet

Usa las siguientes instrucciones específicas para cada lenguaje a fin de verificar la configuración. Los comandos envían varias RPC, algunas con metadatos adicionales, para mostrar que las solicitudes se enrutan a servicios de backend en función de las reglas de coincidencia del mapa de URL. El comando también imprime el nombre de host de la instancia de VM para cada respuesta a fin de mostrar a qué instancia de VM se enruta la solicitud.

Configura opciones más avanzadas

Puedes configurar opciones avanzadas de enrutamiento de tráfico adicionales con las instrucciones de las siguientes secciones.

Disyuntores

La interrupción de circuitos te permite establecer umbrales de fallas para evitar que las solicitudes del cliente sobrecarguen tus servicios de backend. Cuando la cantidad de solicitudes pendientes alcanza el límite que estableciste, el cliente deja de enviar solicitudes adicionales, lo que le da tiempo a los servicios de backend para recuperarse.

De esta manera, la interrupción de circuitos evita errores en cascada, ya que muestra un error al cliente en vez de sobrecargar un servicio backend. Esto permite que se entregue parte del tráfico mientras se proporciona tiempo para administrar la situación de sobrecarga, como controlar un aumento repentino de tráfico mediante el aumento de la capacidad a través del ajuste de escala automático.

Cuando creas el servicio de backend para stats-service, la secuencia de comandos create_service.sh incluye las siguientes líneas en su configuración:

circuitBreakers:
  maxRequests: 1

Este parámetro de configuración limita a los clientes a una solicitud pendiente a stats-service a la vez. Debido a que solo hay un servicio de wallet-v2, ejecutar dos operaciones de WatchBalance simultáneas del cliente de Wallet presenta fallas desde la segunda instancia.

Inyección de fallas

Presenta errores cuando se entregan solicitudes para simular fallas, incluida la latencia alta, la sobrecarga del servicio, las fallas del servicio y la partición de la red. Esta característica es útil para probar la resiliencia de un servicio ante fallas simuladas.

Cuando creaste el mapa de URL, configuraste la política de inserción de fallas para que falle el 50% de las RPC enviadas a wallet.grpcwallet.io con el encabezado route=fault.

Para demostrar la inserción de errores, usa el código en los siguientes lenguajes.

Duración máxima de la transmisión

La duración máxima de transmisión permite que se aplique un tiempo de espera máximo a todas las RPC. Esto evita que los clientes que olvidan establecer un plazo o que establecen un plazo excesivo desperdicien recursos del servidor.

Cuando creaste el mapa de URL, estableciste una duración máxima de transmisión de 5 segundos para las RPC a wallet.grpcwallet.io con el encabezado route=timeout.

Para demostrar los tiempos de espera, primero debemos detener el servicio wallet-v2.

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

El siguiente comando se detendría para siempre, porque no hay un servicio de backend que lo maneje y la aplicación no establece un plazo límite.

Sin embargo, el siguiente comando que usa la ruta timeout falla después de 5 segundos debido a la configuración maxStreamDuration.

Reinicia el servicio wallet-v2:

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

Reintentar

Los reintentos te ayudan a mejorar la disponibilidad del servicio, ya que permiten que las aplicaciones de gRPC reintenten las solicitudes salientes según una política de reintento. En una política de reintento, puedes configurar las condiciones en las que se debe reintentar una solicitud con errores y la cantidad máxima de reintentos, por ejemplo, cuando falla una solicitud con un código de respuesta específico.

Cuando creaste el mapa de URL, estableciste una política de reintento para las RPC en el método FetchBalance con el encabezado membership=premium. Esta política reintenta las RPC que fallan con el código de estado unavailable hasta un máximo de 3 veces. También estableciste una política de inserción de fallas para RPC en account.grpcwallet.io con el encabezado route=account-fault que falla en el 30% de las RPC del servicio Wallet al servicio Account. Como resultado, el 30% de las RPC del cliente de prueba con el encabezado membership=normal fallan, mientras que la tasa de fallas para las RPC con el encabezado membership=premium es inferior al 1%.

Para demostrar los reintentos, usa el código en los siguientes lenguajes.

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

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

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

Afinidad de sesión

La afinidad de sesión hace su mejor esfuerzo para enviar solicitudes con características particulares (encabezados HTTP) a la misma instancia, siempre que la instancia esté en buen estado y tenga capacidad. Esto es útil para los servidores de aplicaciones con estado que se benefician del rendimiento y la eficiencia mejorados cuando las solicitudes de un cliente en particular se envían a la misma instancia, en lugar de, por ejemplo, la distribución round robin a instancias diferentes.

Cuando creaste el servicio de backend grpcwallet-wallet-v1-affinity-service, en la secuencia de comandos create_service.sh, localityLbPolicy se configuró como ROUND_ROBIN. En este ejemplo, aplicarás la siguiente configuración para cambiar localityLbPolicy a RING_HASH.

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

Para demostrar la afinidad de sesión, usa el código en los siguientes lenguajes. Con la marca --affinity=true, el cliente inserta un encabezado session-id con un valor único para cada usuario. Se usa un hash de este valor para enviar la solicitud a una instancia en particular en el grupo de instancias del servicio de backend grpcwallet-wallet-v1-affinity-service.

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

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

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

Restablece la configuración del servicio de backend grpcwallet-wallet-v1-affinity-service.

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

Detección de valores atípicos

Para mejorar la disponibilidad del servicio, configura la detección de valores atípicos. Esta función te permite identificar y expulsar temporalmente los hosts en mal estado del grupo de balanceo de cargas. Estos hosts no saludables se denominan valores atípicos.

gRPC evalúa los hosts en función de la tasa de éxito, que es la frecuencia con la que un host controla correctamente las solicitudes. La tasa se ve afectada por fallas, como errores de gRPC, errores de HTTP, tiempos de espera y otros problemas.

Cuando configuras la detección de valores atípicos a través de Cloud Service Mesh, puedes ajustar cómo gRPC evalúa los hosts y cómo controla los valores atípicos. Por ejemplo, puedes especificar criterios como los siguientes:

• Es la cantidad de solicitudes que un host debe recibir antes de que gRPC lo analice en busca de un posible estado de valor atípico.

• El grado en que un host puede desviarse de la tasa de éxito promedio antes de que se considere un valor atípico.

• Es el porcentaje máximo de hosts que se puede expulsar en cualquier momento del grupo de balanceo de cargas.

• Es la cantidad de tiempo durante la cual se excluye un valor atípico del grupo de balanceo de cargas.

Para obtener más información sobre los parámetros disponibles, consulta la referencia de REST Resource: backendServices. Sin embargo, existen algunas limitaciones para gRPC, como se describe en la siguiente sección.

Limitaciones

Los siguientes campos no son compatibles con los clientes de gRPC:

• outlierDetection.consecutiveErrors

• outlierDetection.enforcingConsecutiveErrors

• outlierDetection.consecutiveGatewayFailure

• outlierDetection.enforcingConsecutiveGatewayFailure

Configura la detección de valores atípicos

En el siguiente procedimiento, se muestra cómo configurar la detección de valores atípicos para un servicio que usa un grupo de instancias como backend. Este procedimiento establece la siguiente configuración:

• El análisis de detección de valores atípicos se ejecuta cada segundo. Para configurar este comportamiento, usa el campo interval.
• Los valores atípicos se expulsan del grupo de balanceo de cargas en incrementos de 30 segundos, de la siguiente manera:
  • Si un host nunca se expulsó antes, se expulsará solo por 30 segundos.
  • Si se expulsó un host anteriormente, el tiempo aumenta en 30 segundos por cada expulsión anterior. Por ejemplo, cuando se expulsa un host por tercera vez, se expulsa durante 90 segundos. Para configurar este comportamiento, usa el campo baseEjectionTime.
• Un host se considera inestable si su tasa de éxito es una desviación estándar inferior al promedio durante el intervalo de tiempo seleccionado (en este caso, 1 segundo). Para configurar la desviación estándar máxima, usa el campo successRateStdevFactor.

Para configurar la detección de valores atípicos de esta manera, sigue estos pasos.

Balanceo de cargas de localidad

Para hacer un uso más eficiente de tus recursos, configura el balanceo de cargas de localidad. Esta función te ayuda a conservar recursos, ya que distribuye de manera uniforme las solicitudes de los clientes entre tus backends.

Cuando configures el balanceo de cargas de localidad, puedes usar las opciones que se describen en la siguiente tabla. Todas las opciones requieren que configures el recurso backendServices.

Puedes usar cualquier combinación de las opciones anteriores. Sin embargo, si configuras localityLbPolicy y localityLbPolicies, gRPC primero intenta usar tu configuración de localityLbPolicies.

Si no configuras el balanceo de cargas de localidad, Cloud Service Mesh usa la política ROUND_ROBIN.

Para obtener información sobre ROUND_ROBIN y otras políticas integradas, consulta la descripción de localityLbPolicy en la página backendServices.

Usa una política integrada

Si deseas que todos tus clientes usen una sola política integrada, puedes configurar el campo localityLbPolicy para seleccionarla.

Cuando configures este campo, podrás elegir entre las siguientes políticas:

• LEAST_REQUEST (solo para clientes de Java)
• RING_HASH
• ROUND_ROBIN

Si no todos tus clientes pueden usar la misma política, consulta Cómo definir una lista de políticas preferidas.

Usa una política personalizada

Si corresponde, puedes usar una política de balanceo de cargas personalizada que hayas creado y implementado con gRPC. Esta función está disponible para clientes de Java que usan la versión 1.47 o posterior de gRPC. Úsalo solo en una malla que incluya todos los clientes de gRPC.

Cuando crees una política personalizada, la siguiente documentación podría serte útil:

• Para que tu política personalizada sea más sofisticada, puedes usar las APIs de Open Request Aggregation (ORCA). Estas APIs te permiten capturar métricas sobre el costo de las consultas y el uso del servidor. Para usar estas APIs, se requiere la versión 1.48.1 o posterior de gRPC. Para obtener más información, consulta el ejemplo de ORCA de gRPC.

• Para obtener información sobre cómo xDS entrega configuraciones de balanceo de cargas personalizadas a gRPC, consulta Configuración del balanceador de cargas personalizado de xDS de gRPC.

Para configurar Cloud Service Mesh para que use tu política personalizada, identifica la política con el campo localityLbPolicies.

En los siguientes pasos, se demuestra este proceso. En este procedimiento, actualizarás la configuración del servicio de backend grpcwallet-wallet-v2-service para que los clientes que se conecten a él usen una política personalizada llamada example.ExampleLoadBalancer.

Define una lista de políticas preferidas

Si tienes varios clientes que no admiten una sola política de balanceo de cargas, crea una lista de políticas que tus clientes puedan usar. Con esta opción, si un cliente en particular no puede usar tu primera política preferida, gRPC recurre a la siguiente política de la lista.

Cuando creas una lista de políticas preferidas, las opciones válidas incluyen las políticas personalizadas, ROUND_ROBIN y, para los clientes de Java, LEAST_REQUEST. Puedes enumerar hasta 10 políticas.

Esta función solo está disponible para los clientes de Java que usan la versión 1.47 o posterior de gRPC. Úsalo solo en una malla que incluya todos los clientes de gRPC.

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

Limpia los recursos

Para limpiar los recursos, ejecuta el siguiente comando desde tu sistema local:

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

Bloquea el tráfico entre servicios

Si deseas bloquear el tráfico entre el servicio A y el servicio B, y la implementación está en GKE, configura la seguridad del servicio y usa una política de autorización para bloquear el tráfico entre servicios. Para obtener instrucciones completas, consulta Seguridad del servicio de la malla de servicios de Cloud y las instrucciones de configuración con Envoy y gRPC sin proxy.

¿Qué sigue?

• Para ayudarte a resolver problemas de configuración de Cloud Service Mesh, consulta Soluciona problemas de implementaciones que usan gRPC sin proxy.