Descripción general de mapas de reglas de enrutamiento

Este documento se aplica solo a Cloud Service Mesh con las APIs de balanceo de cargas. Mié te recomendamos que utilices APIs de Service Enrutamiento.

Un mapa de reglas de enrutamiento consiste en lo siguiente:

Cuando creas y configuras estos recursos para Cloud Service Mesh, Cloud Service Mesh usa los valores para crear la configuración que envía al plano de datos, que incluye clientes xDS como Envoy y 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 Cloud Service Mesh, el balanceo de cargas El esquema debe configurarse como 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

Cloud Service Mesh 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 Cloud Service Mesh 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 Cloud Service Mesh.

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 de gRPC sin proxy se conecta a Cloud Service Mesh, Cloud Service Mesh envía la información correspondiente al servicio de la siguiente manera:

  • Cloud Service Mesh 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.
  • Cloud Service Mesh busca el proxy de gRPC de destino o el proxy HTTP de destino para cada una de estas reglas de reenvío.
  • Cloud Service Mesh encuentra los mapas de URL a los que hacen referencia estos proxies HTTP o gRPC de destino.
  • Cloud Service Mesh 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, Cloud Service Mesh devuelve reglas de enrutamiento y información del servicio al cliente de 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 hacen referencia las reglas de reenvío que especifican el mismo puerto de red.

¿Qué sigue?