Descripción general de mapas de reglas de enrutamiento

En este documento, se describen los mapas de reglas de enrutamiento y cómo estos administran el tráfico en las implementaciones de Traffic Director que usan las API más antiguas. Si usas las API de enrutamiento de servicios nuevas, que están en vista previa, consulta la Descripción general de las API de enrutamiento de servicios nuevas.

Un mapa de reglas de enrutamiento consiste en lo siguiente:

Cuando creas y configuras estos recursos para Traffic Director, Traffic Director usa los valores a fin de crear la configuración que envía al plano de datos, incluidos los clientes xDS, como los proxies de Envoy y las aplicaciones de gRPC sin proxy. Luego, el plano de datos controla el tráfico según esta configuración.

Una regla de reenvío hace referencia a un proxy de destino y tiene una dirección IP y un puerto. Para las implementaciones de Traffic Director, el esquema de balanceo de cargas de la regla de reenvío debe establecerse en INTERNAL_SELF_MANAGED. A su vez, el proxy de destino hace referencia a un mapa de URL. Estos tres recursos se combinan para formar un mapa de reglas de enrutamiento.

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.

El mapa de reglas de enrutamiento define la forma en que el tráfico pasa de los clientes a los servidores dentro de una malla de servicios.

Tipos de proxy de destino admitidos

Traffic Director admite los siguientes tipos de proxy de destino:

  • Proxy HTTP de destino, que configuras cuando los clientes y los servidores envían o reciben tráfico HTTP o HTTP/2.
  • Proxy HTTPS de destino, que configuras cuando los clientes y los servidores envían o reciben tráfico HTTPS. Esto es necesario cuando configuras la seguridad del servicio con proxies de Envoy.
  • Proxy de TCP de destino, que configuras cuando los clientes y los servidores envían o reciben tráfico de TCP.
  • Proxy de gRPC de destino, que configuras cuando los clientes y los servidores envían o reciben tráfico de gRPC. Los proxies de gRPC de destino contienen el campo validateForProxyless, que se establece en TRUE cuando implementas servicios de gRPC sin proxy.

Enrutamiento del tráfico con proxies de sidecar de Envoy

Cuando usas Traffic Director con proxies de sidecar de Envoy, las solicitudes de clientes se enrutan de la siguiente manera:

  • La pila de red intercepta la solicitud y la redirecciona al proxy de sidecar de Envoy.
  • El proxy de sidecar de Envoy busca la dirección IP y el puerto de la solicitud.
  • La dirección IP y el par de puertos se verifican con la IP y el puerto especificados en cualquier regla de reenvío que tenga el esquema de balanceo de cargas configurado como INTERNAL_SELF_MANAGED.
  • Si se encuentra una regla de reenvío con una dirección IP y un puerto coincidentes, Envoy observa el proxy de gRPC o HTTP de destino al que hace referencia la regla de reenvío.
  • Envoy verifica el mapa de URL al que hace referencia el proxy de destino.
  • Envoy enruta la solicitud según las reglas especificadas en el mapa de URL.

Para obtener información sobre cómo se enruta el tráfico con un proxy de TCP de destino, consulta Enruta el tráfico de TCP con Traffic Director.

Enrutamiento del tráfico con aplicaciones de gRPC sin proxy

Este comportamiento es diferente en las aplicaciones de gRPC sin proxy. Cuando configuras un cliente gRPC, especificas el URI de destino para el servicio con el que el cliente debe comunicarse. En este URI, se usa el esquema de agente de resolución de nombres xds y el formato hostname:port, por ejemplo xds:///example.hostname:8080.

Cuando el cliente gRPC sin proxy se conecta a Traffic Director, Traffic Director le envía la información correspondiente al servicio de la siguiente manera:

  • Traffic Director busca reglas de reenvío con esquema de balanceo de cargas configurado como INTERNAL_SELF_MANAGED para encontrar reglas de reenvío cuyo puerto coincida con el puerto especificado en el URI de destino.
  • Traffic Director encuentra el proxy de gRPC de destino o el proxy HTTP de destino para cada una de estas reglas de reenvío.
  • Traffic Director encuentra los mapas de URL a los que hacen referencia estos proxies de gRPC de destino o proxies HTTP de destino.
  • Traffic Director verifica las reglas de host en el mapa de URL, que también tienen el formato hostname[:port], y busca una coincidencia.
  • Cuando se encuentra una coincidencia, Traffic Director muestra reglas de enrutamiento y la información del servicio al cliente gRPC.

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.

¿Qué sigue?