Reglas de reenvío para Traffic Director

Este documento solo se aplica a Traffic Director con las APIs de balanceo de cargas. Te recomendamos que uses las APIs de enrutamiento de servicios o las APIs de Google Kubernetes Engine Gateway para implementar Traffic Director.

Traffic Director usa la regla de reenvío para determinar el proxy de destino al que se enruta el tráfico en la malla.

Cada regla de reenvío proporciona una dirección IPv4 global única para un servicio. Puedes usar esa dirección a fin de crear registros DNS internos para tu servicio (por ejemplo, mediante una zona privada y administrada de Cloud DNS). Los filtros de metadatos en la regla de reenvío especifican los criterios para los que un proxy de sidecar compatible con xDS recibe la configuración.

Nota: En esta página, solo se analizan las reglas de reenvío en el contexto de Traffic Director. Las reglas de reenvío también se usan para proporcionar información de reenvío en el plano de control de lo siguiente: reenvío de protocolos, puertas de enlace de VPN clásica y balanceadores de cargas de Google Cloud. Para obtener una descripción general más completa de las reglas de reenvío, consulta la descripción general de las reglas de reenvío de Cloud Load Balancing.

Para el plano de control de Traffic Director, la regla de reenvío interna, autoadministrada y global enruta el tráfico por dirección IP, puerto y protocolo a un proxy de destino. El proxy de destino apunta a un mapa de URL que contiene reglas que determinan el destino del tráfico. El mapa de URL también especifica el servicio de backend predeterminado. Este servicio de backend especifica una verificación de estado y determina el backend adecuado, como un grupo de instancias administrado (MIG) que contiene instancias de máquina virtual (VM) o ungrupo de extremos de red (NEG) que contiene Pods de backend de Google Kubernetes Engine (GKE).

En el siguiente diagrama, se muestra cómo una regla de reenvío se ajusta a la arquitectura de Traffic Director.

Regla de reenvío de Traffic Director destacada (haz clic para ampliar)

Propiedades de las reglas de reenvío

Un recurso de regla de reenvío contiene las siguientes propiedades que se aplican a Traffic Director. La regla de reenvío controla el tráfico que coincide con la dirección IP de destino, el protocolo y el número de puerto.

Una dirección IP 0.0.0.0 en una regla de reenvío es una de las opciones cuando se usa Traffic Director. Una dirección IP 0.0.0.0 significa cualquier dirección IP.

• Con una implementación de proxy, una dirección IP 0.0.0.0 permite que un proxy coincida con cualquier tráfico entrante si no se encuentra otra coincidencia específica.

• Con una implementación sin proxy, una dirección IP 0.0.0.0 proporciona una forma de especificar que no se requiere una dirección IP. A continuación, se brindan más detalles sobre el uso de direcciones IP 0.0.0.0 con un proxy de gRPC de destino.

En la siguiente tabla, se describen las propiedades de las reglas de reenvío con más detalle.

Propiedad	Requeridos	Descripción
name	✔	El nombre de la regla de reenvío. El nombre debe ser único en este proyecto, debe tener de 1 a 63 caracteres y coincidir con la expresión regular: [a-z]([-a-z0-9]*[a-z0-9])? Esto significa que el primer carácter debe ser una letra minúscula y todos los siguientes deben ser un guion, una letra minúscula o un dígito, excepto el último carácter, que no puede ser un guion.
IPAddress	✔	Una de las siguientes opciones: 0.0.0.0 o 127.0.0.1, o cualquier dirección RFC 1918. No es necesario que las direcciones IP de las reglas de reenvío de Traffic Director correspondan a rangos de direcciones IP de subredes en la red de nube privada virtual (VPC). Para una red de VPC, una dirección IP y un puerto determinados, solo puedes tener una regla de reenvío interna autoadministrada. Por ejemplo, en la misma red de VPC, no puedes crear dos reglas de reenvío que usen la dirección IP 0.0.0.0 y el puerto 80.
IPAddress con un proxy de gRPC de destino		Una regla de reenvío que hace referencia a un proxy de gRPC de destino con el campo validateForProxyless configurado en TRUE y la dirección IP configurada en 0.0.0.0. Un cliente de gRPC que usa el esquema xds no realiza una búsqueda de DNS para resolver el nombre de host en el URI de canal. En su lugar, este cliente resuelve 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. 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 usa la dirección IP 0.0.0.0 y el puerto (80 predeterminado) especificado en el URI para buscar la regla de reenvío. Luego, Traffic Director busca una regla de host que coincida en el mapa de URL del proxy de destino al que hace referencia la regla de reenvío.
target	✔	El proxy de destino al que dirige el tráfico esta regla de reenvío. Traffic Director es compatible con target-http-proxy, target-https-proxy y target-grpc-proxy. When you use the Google Cloud console to configure the forwarding rule, the target proxy is configured automatically. When you use the Google Cloud CLI or the API, the target proxy must exist before you create your forwarding rule. You can use more than one forwarding rule with a given proxy.
IPProtocol	✔	El tipo de protocolo con el que coincide esta regla de reenvío. El único valor admitido es TCP.
loadBalancingScheme	✔	Especifica cómo se usa la regla de reenvío. El valor válido para Traffic Director es INTERNAL_SELF_MANAGED.
portRange	✔	Un puerto o un rango de puertos unido por un guion. Los paquetes del protocolo especificado enviado a estos puertos se reenvían al backend correspondiente. Puedes especificar un solo número dentro de un rango, por ejemplo, 80 o 80-8080. Para una red de VPC, una dirección IP y un puerto determinados, solo puedes tener una regla de reenvío interna autoadministrada. Por ejemplo, en la misma red de VPC, no puedes crear dos reglas de reenvío que usen la dirección IP 0.0.0.0 y el puerto 80. Con los servicios de gRPC sin proxy, el puerto en la regla de reenvío coincide con el puerto especificado en el URI que usa una aplicación de gRPC para conectarse a un servicio. Si no se especifica un puerto en el URI, entonces 80 es el puerto predeterminado.
network	✔	Especifica la red de VPC en la que se encuentran las VM de Google Cloud que ejecutan proxies de Envoy. Los proxies de Envoy leen la configuración de Traffic Director que defines para la misma red en la que se implementan los proxies. Puedes usar la red de VPC llamada default o una red personalizada. Traffic Director admite el balanceo de cargas para los clientes solo dentro de la red de Google Cloud. Debes especificar el nombre de la red en la regla de reenvío. No se admite el intercambio de tráfico de red de VPC.

Agrega una regla de reenvío global

Para obtener información sobre cómo configurar una regla de reenvío dentro de la configuración general de Traffic Director, consulta lo siguiente:

• Configura Traffic Director para VM de Compute Engine con implementación automática de Envoy
• Configura Traffic Director para VM de Compute Engine con implementación manual de Envoy
• Configura Traffic Director para Pods de GKE con inserción automática de Envoy
• Configura Traffic Director para Pods de GKE con inserción manual de Envoy
• Configura Traffic Director para VM de Compute Engine y servicios de gRPC sin proxy
• Configura Traffic Director para Pods de GKE y servicios de gRPC sin proxy

¿Qué sigue?

• Para usar filtros de metadatos a fin de controlar qué proxies de sidecar reciben la configuración adjunta a la regla de reenvío, consulta Configura el filtrado de configuración según la coincidencia de MetadataFilter.
• Para enrutar el tráfico, consulta Descripción general de los mapas de reglas de enrutamiento de Traffic Director.
• Para obtener más información sobre Traffic Director, consulta la descripción general de Traffic Director.