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. En esta guía, se abordan las API de Traffic Director anteriores. Para obtener más información sobre las APIs de enrutamiento de servicios, consulta la 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.

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.

Para obtener una descripción general completa de cómo funciona Traffic Director, consulta Descripción general de Traffic Director.

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 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 y las verificaciones de estado. Este enfoque habilita patrones de implementación adicionales de Traffic Director.

En la primera ilustración, se habilita una malla de servicios mediante un proxy de sidecar.

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

Para configurar un proxy de sidecar, Traffic Director usa las API de xDS. Los clientes se comunican con el servidor 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.
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

La resolución de nombres funciona para implementaciones sin proxy de las siguientes maneras:

  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:///example.hostname.
  2. El cliente de gRPC resuelve el hostname:port en el URI de destino mediante el envío de una solicitud de servicio de detección de objetos de escucha (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, example.hostname, example.hostname:80 y example.hostname: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 de sidecar 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. Los clientes de gRPC con proxies de sidecar usan el esquema de resolución de nombres de dns.

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

Casos de uso

Los siguientes casos de uso te ayudan a comprender cuándo es posible que desees usar Traffic Director con aplicaciones de gRPC sin proxy. Tu implementación puede incluir aplicaciones de gRPC sin proxy, aplicaciones de gRPC con proxies de sidecar o una combinación de ambas.

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. La inclusión de ambos modelos 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 proxy de sidecar configurado por Traffic Director, puedes pasar a una aplicación 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 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 usan la ruta del proxy de sidecar cuando se comunican con otro servidor de gRPC. Esto te permite migrar de forma gradual a una implementación sin proxy.

Para migrar de una malla de servicios con proxies a una sin proxies, crea un servicio de Traffic Director nuevo que tu cliente de gRPC sin proxy usa. Puedes usar las mismas API a fin de configurar Traffic Director para las versiones nuevas y existentes.

Malla de servicios con un cliente de gRPC que se comunica con los distintos servicios mediante mecanismos sin proxy y basados en proxy.
Malla de servicios con un cliente de gRPC que se comunica con los diferentes 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 porque gRPC sin proxy no es compatible con todas las funciones de Envoy y otras son inherentes al uso de RPC. Por ejemplo, los redireccionamientos HTTP que usan gRPC no son compatibles. Para ayudarte a comprender el modelo de configuración en esta guía, te recomendamos que te familiarices con los conceptos y la configuración de Traffic Director.

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.
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. Los mapas de reglas de enrutamiento se aplican solo a las implementaciones que usan las API de balanceo de cargas. No se aplican con las APIs de enrutamiento de servicios ni con las APIs de Gateway.

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 hostname[: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. Esta verificación no detecta reglas de reenvío duplicadas con el mismo puerto en otros mapas de reglas de enrutamiento.

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 predeterminadas que contienen caracteres comodín.

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 dos 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 CLI de Google Cloud, 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. La validación de la configuración se realiza según las funciones 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.

Si no especificas un puerto en el URI de destino, se usa 80 como valor predeterminado. Esto implica lo siguiente:

  • El URI de destino xds:///myservice coincide con la regla de host del mapa de URL myservice.
  • El URI de destino xds:///myservice:80 coincide con la regla de host del mapa de URL myservice:80.
  • 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 comprobar el estado de un servicio de gRPC que se ejecuta en una instancia de máquina virtual (VM) de backend o en un grupo de extremos de red (NEG).

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 NEG zonales en Google Kubernetes Engine como backends para alojar las instancias del servidor de gRPC.

¿Qué sigue?