Proxies de destino para Traffic Director

Cuando configuras Traffic Director, el proxy de destino es uno de los recursos que configuras.

En el contexto de Traffic Director, los proxies de destino tienen dos propósitos principales:

  1. Tienen un tipo específico. Este tipo se usa para que los clientes de Traffic Director sepan qué protocolo usar cuando se abre una conexión a los backends/extremos asociados con un servicio.

  2. Se combinan con otros recursos (por ejemplo, reglas de reenvío y mapas de URL) para crear un mapa de reglas de enrutamiento. La asignación de reglas de enrutamiento proporciona capacidades adicionales (como reglas de enrutamiento), según el tipo de proxy de destino. Las selecciones no válidas suelen estar ocultas de la interfaz de usuario o la API las rechaza.

Los tipos de proxy de destino corresponden a distintos protocolos de solicitud

Traffic Director genera una configuración diferente para sus clientes según el tipo de proxy de destino que configures. Cuando configuras un tipo de proxy de destino diferente, el cliente usa un protocolo de solicitud específico.

  • Proxies HTTP de destino: Los clientes de Traffic Director comenzarán las conexiones HTTP
  • Proxies de gRPC de destino: Los clientes de Traffic Director iniciarán conexiones de gRPC.
  • Proxies TCP de destino: Los clientes de Traffic Director iniciarán conexiones TCP

Tenga en cuenta que no se limita a elegir solo un tipo. Por ejemplo, tu aplicación podría querer usar HTTP cuando se abordan algunos servicios, pero usa TCP cuando se dirige a otros servicios. Para este caso práctico, tendrías que crear un proxy HTTP de destino y un proxy TCP de destino.

Combinaciones de recursos válidas en un mapa de reglas de enrutamiento

Para evitar configuraciones incorrectas, Traffic Director solo te permite crear mapas de reglas de enrutamiento que se ven de la siguiente manera:

  • Regla de reenvío -> Proxy HTTP de destino global -> Mapa de URL -> (uno o más servicios de backend)
  • Regla de reenvío -> Proxy de destino global -> -> Mapa de URL -> (uno o más servicios de backend)
  • Regla de reenvío -> Proxy TCP de destino global -> un servicio de backend

Ten en cuenta que las verificaciones de estado y los grupos de backend no se muestran en la lista anterior.

Si usas Google Cloud Console para configurar un proxy HTTP de destino, el proxy de destino se configura de forma implícita como parte de la configuración de la asignación de reglas de enrutamiento. Ten en cuenta que la configuración del proxy TCP aún no se admite en la consola.

Si usas la interfaz de línea de comandos de gcloud o las API, debes configurar el proxy de destino de forma explícita.

Controla el tráfico cuando uses un proxy HTTP de destino

Cuando configuras servicios basados en HTTP, por lo general, cada instancia de servicio tendrá un proxy Envoy implementado junto a él. Este proxy se configura mediante Traffic Director, es parte del plano de datos de la malla de servicios y controla el tráfico de la siguiente manera.

El proxy Envoy recibe la solicitud saliente y compara la IP y el puerto de destino de la solicitud con la IP y el puerto que se configura en cada regla de reenvío que hace referencia a un proxy HTTP de destino. Si se encuentra una coincidencia, el proxy de Envoy evaluará la solicitud según el mapa de URL correspondiente del proxy HTTP de destino.

Controla el tráfico cuando uses un proxy HTTP de destino

Cuando configuras servicios basados en HTTP, por lo general, cada instancia de servicio tendrá un proxy Envoy implementado junto a él. Este proxy se configura mediante Traffic Director, es parte del plano de datos de la malla de servicios y controla el tráfico de la siguiente manera.

El proxy Envoy recibe la solicitud saliente y compara la IP y el puerto de destino de la solicitud con la IP y el puerto que se configura en cada regla de reenvío que hace referencia a un proxy HTTP de destino. Cada regla de reenvío enruta el tráfico de TCP a un proxy de destino, que apunta a un servicio de backend predeterminado, que especifica una verificación de estado y determina el backend apropiado.

Controla el tráfico cuando uses un proxy de gRPC de destino

Cuando configuras servicios basados en gRPC, por lo general, las instancias de servicio, no tienen proxies Envoy implementados junto con ellas. En cambio, la biblioteca de gRPC se configura con Traffic Director, es parte del plano de datos de la malla de servicios y maneja el tráfico de la siguiente manera.

La biblioteca de gRPC compara el hostname[:port] especificado en el URI con las reglas de host en todos los mapas de URL a los que hace referencia un proxy de gRPC de destino. Si se encuentra una coincidencia, la biblioteca de gRPC evaluará la solicitud según las reglas de ruta de acceso asociadas a la regla de host correspondiente.

Configura la intercepción del tráfico de la puerta de enlace y los proxies intermedios

Por lo general, en una malla de servicios, tienes lo siguiente:

  • Las instancias de servicio tienen un proxy de archivo adicional Envoy o una biblioteca de gRPC dedicada.
    • Si usas Envoy, las instancias de servicio están configuradas para interceptar y redireccionar solicitudes salientes al proxy de Envoy.
  • El proxy Envoy o la biblioteca de gRPC controlan las solicitudes salientes.

Sin embargo, también puedes usar Traffic Director para configurar una puerta de enlace o un proxy intermedio. En esta configuración, el proxy de Envoy está separado de tus instancias de servicio. Detecta las solicitudes entrantes en un puerto y maneja las solicitudes cuando las recibe.

Para este tipo de configuración, no necesitas configurar la intercepción ni el redireccionamiento. En su lugar, puedes simplemente habilitar la marca --proxy-bind en el proxy HTTP de destino. Esto configura la intercepción de tráfico entrante y hace que el proxy de Envoy detecte las solicitudes entrantes en la dirección IP y el puerto (configurados en la regla de reenvío).

Recuerda que la regla de reenvío hace referencia a un proxy de destino. Entonces, si habilitas --proxy-bind en un proxy HTTP de destino, el proxy escucha en la dirección IP y el puerto de la regla de reenvío que hace referencia a este proxy HTTP de destino.

Ten en cuenta lo siguiente:

  • Si usas Traffic Director para una malla de servicios, no necesitas usar --proxy-bind, ya que los proxy de sidecar suelen recibir y reenviar el tráfico saliente.
  • La marca --proxy-bind no está disponible para los proxies de gRPC de destino.

Recursos del proxy de destino

Para agregar, borrar, enumerar y obtener información sobre los proxies de destino, puedes usar la API de REST o el SDK de gcloud.

Sin embargo, puedes usar los siguientes comandos de gcloud para obtener información sobre un proxy de destino:

gcloud compute [target-http-proxies | target-tcp-proxies | target-grpc-proxies ] list
gcloud compute [target-http-proxies | target-tcp-proxies | target-grpc-proxies ] describe target-proxy-name

API

Para obtener descripciones de las propiedades y los métodos disponibles cuando trabajas con proxies de destino a través de la API de REST, consulta las siguientes páginas:

SDK de gcloud

Para obtener información sobre la herramienta de línea de comandos de gcloud, consulta las siguientes páginas:

Próximos pasos

Para obtener más información, consulte: