Descripción general de Traffic Director con servicios de gRPC sin proxy

En esta guía, se brinda una descripción general de la arquitectura de Traffic Director con servicios de gRPC sin proxy, incluidos los casos de uso y los patrones de arquitectura.

Descripción general

El plano de control administrado de Traffic Director permite el enrutamiento global, el balanceo de cargas y la conmutación por error regional para los casos de uso del balanceo de cargas y la malla de servicios. Esto incluye implementaciones que incorporan proxies de sidecar y de puerta de enlace. La compatibilidad de Traffic Director para aplicaciones de gRPC sin proxy ofrece un modelo de implementación adicional en el que las aplicaciones de gRPC pueden participar en una malla de servicios sin necesidad de un proxy de sidecar. Para obtener una descripción general completa de cómo funciona Traffic Director, consulta Descripción general de Traffic Director.

En un ejemplo típico, un cliente de gRPC establece una conexión con un servidor de gRPC que aloja tu lógica de backend. Traffic Director brinda a tus clientes de gRPC información sobre con qué servidores comunicarse, cómo balancear las cargas de solicitudes entre varias instancias de un servidor y qué hacer con las solicitudes si un servidor no se está ejecutando.

Cómo funciona Traffic Director con aplicaciones de gRPC

Traffic Director configura clientes de gRPC con una versión de gRPC compatible, de manera similar a cómo se configuran los proxies de sidecar, como Envoy. Sin embargo, las aplicaciones de gRPC sin proxy conectadas directamente con Traffic Director no necesitan proxies de sidecar. En su lugar, Traffic Director usa las API de xDS v2 de código abierto para configurar aplicaciones de gRPC directamente. Estas aplicaciones de gRPC actúan como clientes de xDS, que se conectan al plano de control global de Traffic Director. Después de que se conecten, las aplicaciones de gRPC reciben la configuración dinámica del plano de control, lo que habilita el descubrimiento de extremos, el balanceo de cargas, la conmutación por error regional, las verificaciones de estado y más.

Este enfoque habilita patrones de implementación adicionales de Traffic Director. En la primera ilustración a continuación, se habilita una malla de servicios mediante un proxy de sidecar.

Una malla de servicios habilitada mediante un proxy de sidecar (haz clic para ampliar)
Una malla de servicios habilitada mediante un proxy de sidecar (haz clic para ampliar)

Traffic Director configura un proxy de sidecar mediante las API de xDS v2. El cliente de gRPC se comunica con el servidor de gRPC a través del proxy de sidecar.

En la segunda ilustración, se habilita una malla de servicios sin un proxy de sidecar mediante un cliente de gRPC sin proxy:

Una malla de servicios habilitada mediante gRPC sin proxy (haz clic para ampliar)
Una malla de servicios habilitada mediante gRPC sin proxy (haz clic para ampliar)

Si solo implementas servicios de gRPC que Traffic Director configura, puedes crear una malla de servicios sin implementar ningún proxy. Esto hace que llevar funciones de la malla de servicios a las aplicaciones de gRPC sea más fácil.

Esquema de resolución de nombres

A continuación, se muestra cómo funciona la resolución de nombres para implementaciones sin proxy:

  1. Debes establecer xds como el esquema de resolución de nombres en el canal del cliente de gRPC cuando te conectas a un servicio. El URI de destino tiene el formato xds:///hostname:port. Cuando no se especifica el puerto, el valor predeterminado es 80, por ejemplo, en el URI de destino xds:///foo.myservice.
  2. El cliente de gRPC resuelve hostname:port en el URI de destino mediante el envío de una solicitud LDS a Traffic Director.
  3. Traffic Director busca las reglas de reenvío configuradas que tienen un puerto coincidente. Luego, busca el mapa de URL correspondiente para una regla de host que coincide con hostname:port. Muestra la configuración de enrutamiento asociada con el cliente de gRPC.

Las reglas de host que configuras en Traffic Director deben ser únicas en todos los mapas de URL. Por ejemplo, foo.myservice, foo.myservice:80 y foo.myservice:8080 son reglas diferentes.

Resolución de nombres con tipos de implementación diferentes

El esquema de resolución de nombres es diferente para las implementaciones sin proxy y las que usan proxies de Envoy.

El cliente de gRPC usa el esquema de resolución de nombres de xds para conectarse a un servicio, lo que le permite al cliente recibir la configuración del servicio de Traffic Director. Luego, el cliente de gRPC se comunica directamente con el servidor de gRPC.

Puedes combinar patrones de implementación de archivo adicional y sin proxy para aumentar la flexibilidad. Esto es muy útil cuando la organización y la red admiten varios equipos con diferentes requisitos de funciones, necesidades operativas y versiones de gRPC.

En la siguiente ilustración, los clientes de gRPC sin proxy y los clientes de gRPC con un proxy de sidecar se comunican con un servidor de gRPC.

Una malla de servicios compuesta por clientes de gRPC sin proxy y clientes de gRPC con proxies de sidecar (haz clic para ampliar)
Una malla de servicios compuesta por clientes de gRPC sin proxy y clientes de gRPC con proxies de sidecar (haz clic para ampliar)

Los clientes de gRPC con proxies de sidecar usan el esquema de resolución de nombres de dns.

Casos de uso

En estos ejemplos, se ilustran cómo puedes adoptar una malla de servicios con los servicios de gRPC sin proxy.

Los siguientes casos de uso te ayudan a comprender cuándo es posible que desees usar Traffic Director con aplicaciones de gRPC sin proxy. Ten en cuenta que tu implementación puede incluir aplicaciones de gRPC sin proxy, aplicaciones de gRPC con archivos adicionales o una combinación.

Eficiencia de recursos en una malla de servicios a gran escala

Si tu malla de servicios incluye cientos o miles de clientes y backends, es posible que aumente el consumo total de recursos por la ejecución de proxies de sidecar. Cuando usas aplicaciones de gRPC sin proxy, no necesitas ingresar proxies de sidecar a la implementación. Un enfoque sin proxy puede generar mejoras en la eficiencia.

Aplicaciones de gRPC de alto rendimiento

En algunos casos de uso, cada milisegundo de latencia de solicitud y respuesta es importante. En ese caso, tal vez encuentres una latencia reducida cuando uses una aplicación de gRPC sin proxy, en lugar de pasar cada solicitud a través de un proxy de sidecar del lado del cliente y, posiblemente, un proxy de sidecar del lado del servidor.

Malla de servicios para entornos en los que no puedes implementar proxies de sidecar

En algunos entornos, es posible que no puedas ejecutar un proxy de sidecar como proceso adicional junto con el cliente o la aplicación de servidor. O es posible que no puedas configurar la pila de redes de una máquina para la intercepción y el redireccionamiento de solicitudes, por ejemplo, mediante iptables. En este caso, puedes usar Traffic Director con aplicaciones de gRPC sin proxy para ingresar funciones de malla de servicios en las aplicaciones de gRPC.

Malla de servicios heterogénea

Debido a que las aplicaciones de gRPC sin proxy y Envoy se comunican con Traffic Director, la malla de servicios puede incluir ambos modelos de implementación. Esto te permite satisfacer las necesidades particulares operativas, de rendimiento y de características de diferentes aplicaciones y equipos de desarrollo.

Migra desde una malla de servicios con proxies a una sin proxies

Si ya tienes una aplicación de gRPC con un archivo adicional configurado por Traffic Director, puedes pasar a una aplicación de gRPC sin proxy.

Cuando se implementa un cliente de gRPC con un proxy de sidecar, usa DNS para resolver el nombre de host al que se conecta. El proxy de sidecar se intercepta el tráfico para proporcionar la funcionalidad de la malla de servicios.

Puedes definir si un cliente de gRPC usa la ruta sin proxy o la ruta del archivo adicional para comunicarse con un servidor gRPC si modificas el esquema de resolución de nombres que usa. Los clientes sin proxy usan el esquema de resolución de nombres de xds, mientras que los proxies de sidecar usan el esquema de resolución de nombres de dns. Algunos clientes de gRPC incluso pueden usar la ruta sin proxy cuando se comunican con un servidor de gRPC, pero la ruta del archivo adicional cuando se comunica con otro servidor de gRPC. Esto te permite migrar de forma gradual a una implementación sin proxy.

Para hacer esto, crea un servicio de Traffic Director nuevo que use el cliente de gRPC sin proxy. Puedes configurar Traffic Director para las versiones nuevas y existentes mediante las mismas API.

Malla de servicios con un cliente de gRPC que se comunica con los distintos servicios mediante mecanismos sin proxy y basados en proxy (haz clic para ampliar)
Malla de servicios con un cliente de gRPC que se comunica con los distintos servicios mediante mecanismos sin proxy y basados en proxy (haz clic para ampliar)

Arquitectura y recursos

El modelo de datos de configuración para los servicios de gRPC sin proxy extiende el modelo de configuración de Traffic Director, con algunas adiciones y limitaciones que se describen en esta guía. Algunas de estas limitaciones son temporales, ya que gRPC sin proxy aún no admite todas las características de Envoy y otras son inherentes al uso de RPC. Por ejemplo, los redireccionamientos HTTP no son compatibles con gRPC. Recomendamos que te familiarices con los conceptos y la configuración de Traffic Director para ayudarte a comprender el modelo de configuración en esta guía.

En el siguiente diagrama, se muestran los recursos que debes configurar para las aplicaciones de gRPC sin proxy.

Recursos compatibles con gRPC sin proxy para el balanceo de cargas (haz clic a fin de ampliar)
Recursos compatibles con gRPC sin proxy para el balanceo de cargas (haz clic a fin de ampliar)

Mapas de reglas de enrutamiento

Un mapa de reglas de enrutamiento define cómo se enrutan las solicitudes en la malla. Consiste en una regla de reenvío, un proxy de gRPC de destino y una asignación de URL.

Regla de reenvío

Por lo general, la regla de reenvío se crea mediante la dirección IP virtual y el puerto del servicio que estás configurando. Un cliente de gRPC que usa el esquema de resolución de nombres de xds no realiza la búsqueda de DNS para resolver el nombre de host en el URI del canal. En su lugar, este cliente resuelve el nombre de host[:port] en el URI de destino mediante el envío de una solicitud LDS a Traffic Director. No hay ninguna búsqueda de DNS involucrada y no se requiere una entrada de DNS para el nombre de host. Como resultado, Traffic Director solo usa el puerto especificado en el URI para buscar la regla de reenvío, sin importar la dirección IP. El valor predeterminado del puerto es 80. Luego, Traffic Director busca una regla de host que coincida en el mapa de URL asociado con el proxy de destino al que hace referencia la regla de reenvío.

Por lo tanto, una regla de reenvío que hace referencia a un proxy de gRPC de destino con el campo validateForProxyless configurado en TRUE debe tener su dirección IP configurada en 0.0.0.0. Cuando se configura validateForProxyless como TRUE, se rechaza la configuración que especifica una dirección IP que no sea 0.0.0.0.

Ten en cuenta lo siguiente:

  • El esquema de balanceo de cargas para la regla de reenvío debe ser INTERNAL_SELF_MANAGED.
  • Puedes tener varias reglas de reenvío, pero el IP:port de cada regla de reenvío debe ser único y el puerto debe coincidir con el especificado en la regla de host.
  • Si más de una regla de reenvío tiene un puerto que coincide con el puerto en el URI de destino, Traffic Director busca un hostname[:port] que coincida en las reglas del host de los mapas de URL a los que hacen referencia esas reglas de reenvío. Traffic Director busca una coincidencia exacta entre el hostname[:port] en la regla de host y el hostname[:port] especificado en el URI de destino. Se omiten las reglas de host y las predeterminadas que contienen caracteres comodín.

Ten en cuenta que, si se encuentra más de una coincidencia, el comportamiento es indefinido y puede provocar un comportamiento impredecible. Por lo general, esto ocurre cuando se cumplen las siguientes condiciones:

  • Se usa el mismo nombre de host en varios mapas de URL.
  • Varias reglas de reenvío con el esquema de balanceo de cargas INTERNAL_SELF_MANAGED especifican el mismo puerto.

Por esta razón, te recomendamos que no vuelvas a usar el mismo nombre de host en varios mapas de URL a los que se hace referencia mediante reglas de reenvío que especifican el mismo puerto.

Proxy de gRPC de destino

Los proxies de destino apuntan a mapas de URL, que, a su vez, contienen reglas usadas para enrutar el tráfico al backend correcto. Cuando configures Traffic Director para aplicaciones de gRPC, usa un proxy de gRPC de destino, no un proxy HTTP de destino, independientemente de si usas aplicaciones de gRPC sin proxy o aplicaciones de gRPC que usan Envoy.

Los proxies de gRPC de destino tienen un campo llamado validateForProxyless en la API de REST. El valor predeterminado es FALSE. Si se configura este campo en TRUE, se habilitan las verificaciones de configuración para que no habilites de forma accidental una función que no sea compatible con gRPC sin proxy.

En la herramienta de línea de comandos de gcloud, la marca --validate-for-proxyless es el equivalente del campo validateForProxyless.

Debido a que la compatibilidad con Traffic Director para aplicaciones de gRPC sin proxy no incluye el rango completo de funciones disponibles para las aplicaciones de gRPC con un proxy de sidecar, puedes usar este campo a fin de garantizar que se rechacen las configuraciones no válidas, que podrían especificarse en el mapa de URL o en el servicio de backend. Además, ten en cuenta que la validación de la configuración se realiza según las características que admite Traffic Director con la versión más reciente de gRPC.

Mapa de URL

El mapa de URL define las reglas de enrutamiento que usan los clientes de gRPC sin proxy para enviar tráfico. El mapa de URL contiene una o más reglas de host en el formato hostname:port. Cada una de estas reglas de host se resuelve como un servicio.

Cuando configuras tu cliente de gRPC, especificas el URI de destino para el servicio con el que el cliente debe comunicarse. Este URI también usa el formato hostname:port. Este URI corresponde a la entrada de la regla de host en el mapa de URL.

Por ejemplo, si configuras el URI de destino xds:///myservice:8080 en el cliente de gRPC, Traffic Director envía la configuración correspondiente a la regla de host del mapa de URL para myservice:8080. En esta configuración se incluye, entre otra información, una lista de extremos, que son un par de dirección IP:puerto correspondiente a instancias específicas del servidor de gRPC.

  • El URI de destino xds:///myservice coincide con la regla de host del mapa de URL myservice.
  • El URI de destino xds:///myservice no coincide con la regla de host del mapa de URL myservice:80.
  • El URI de destino xds:///myservice:80 no coincide con la regla de host del mapa de URL myservice.

La string en el URI de destino y la string en la regla de host del mapa de URL deben ser idénticas.

Para obtener información adicional, consulta Limitaciones del mapa de URL.

Verificaciones de estado

Una verificación de estado de gRPC puede verificar el estado de un servicio de gRPC que se ejecuta en un NEG o una VM de backend.

Si no se puede usar una verificación de estado de gRPC porque el servidor de gRPC no implementa el protocolo de verificación de estado de gRPC, usa una verificación de estado TCP. No uses una verificación de estado HTTP, HTTPS o HTTP/2.

Si deseas obtener más información, consulta Verificación de estado de gRPC y Marca adicional para verificaciones de estado de gRPC.

Servicio de backend

El servicio de backend define la manera en que un cliente de gRPC se comunica con un servidor de gRPC. Cuando crees un servicio de backend para gRPC, configura el campo de protocolo en GRPC.

  • Las aplicaciones de gRPC también pueden acceder a un servicio de backend configurado con el protocolo de GRPC a través de un proxy de sidecar. En ese caso, el cliente de gRPC no debe usar el esquema de resolución de nombres de xds.

  • En todas las implementaciones de Traffic Director, el esquema de balanceo de cargas del servicio de backend debe ser INTERNAL_SELF_MANAGED.

Backends

Los backends alojan tus instancias de servidor de gRPC. Puedes usar grupos de instancias administrados o no administrados en Compute Engine y grupos de extremos de red zonales (NEG) en Google Kubernetes Engine como backends para alojar las instancias del servidor de gRPC.

Próximos pasos