Información general sobre los mapas de reglas de enrutamiento

Este documento solo se aplica a Cloud Service Mesh con las APIs de balanceo de carga. Te recomendamos que uses las APIs de enrutamiento de servicios.

Un mapa de reglas de enrutamiento consta de 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 a tu plano de datos, que incluye clientes xDS, como proxies de Envoy y aplicaciones gRPC sin proxy. A continuación, el plano de datos gestiona 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. En las implementaciones de Cloud Service Mesh, el esquema de balanceo de carga de la regla de reenvío debe ser INTERNAL_SELF_MANAGED. El proxy de destino, a su vez, hace referencia a un mapa de URLs. Estos tres recursos se combinan para formar un mapa de reglas de enrutamiento.

Una regla de reenvío que haga referencia a un proxy gRPC de destino con el campo validateForProxyless definido como TRUE debe tener la dirección IP definida como 0.0.0.0. Si validateForProxyless está configurado como TRUE, se rechazarán las configuraciones que especifiquen una dirección IP distinta de 0.0.0.0.

El mapa de reglas de enrutamiento define cómo se transfiere el tráfico 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: se configura cuando los clientes y los servidores envían o reciben tráfico HTTP o HTTP/2.
  • Proxy HTTPS de destino: se configura cuando los clientes y los servidores envían o reciben tráfico HTTPS. Este paso es obligatorio cuando configuras la seguridad del servicio con proxies de Envoy.
  • Proxy TCP de destino: se configura cuando los clientes y los servidores envían o reciben tráfico TCP.
  • Proxy gRPC de destino: se configura cuando los clientes y los servidores envían o reciben tráfico gRPC. Los proxies gRPC de destino contienen el campo validateForProxyless, que se define como TRUE cuando despliegas servicios gRPC sin proxy.

Enrutamiento del tráfico con proxies de sidecar de Envoy

Cuando usas Cloud Service Mesh con proxies sidecar de Envoy, las solicitudes de los clientes se enrutan de la siguiente manera:

  • La pila de red intercepta la solicitud y la redirige a tu proxy sidecar de Envoy.
  • El proxy sidecar de Envoy examina la dirección IP y el puerto de la solicitud.
  • La combinación de dirección IP y puerto se compara con la dirección IP y el puerto especificados en las reglas de reenvío que tienen el esquema de balanceo de carga definido como INTERNAL_SELF_MANAGED.
  • Si se encuentra una regla de reenvío con una dirección IP y un puerto coincidentes, Envoy busca el proxy HTTP de destino o el proxy gRPC de destino al que hace referencia la regla de reenvío.
  • Envoy comprueba el mapa de URLs al que hace referencia el proxy de destino.
  • Envoy enruta la solicitud según las reglas especificadas en el mapa de URLs.

Para obtener información sobre cómo se enruta el tráfico con un proxy TCP de destino, consulta Enrutar tráfico TCP con Cloud Service Mesh.

Enrutamiento del tráfico con aplicaciones gRPC sin proxy

Este comportamiento es diferente en las aplicaciones gRPC sin proxy. Cuando configuras un cliente gRPC, especificas el URI de destino del servicio con el que debe ponerse en contacto el cliente. Este URI usa el esquema 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 le envía información correspondiente al servicio de la siguiente manera:

  • Cloud Service Mesh busca reglas de reenvío con el esquema de balanceo de carga definido 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 gRPC o el proxy HTTP de destino de cada una de estas reglas de reenvío.
  • Cloud Service Mesh busca los mapas de URLs a los que hacen referencia estos proxies gRPC de destino o proxies HTTP de destino.
  • Cloud Service Mesh comprueba las reglas de host en el mapa de URLs, que también tienen el formato hostname[:port], y busca una coincidencia.
  • Cuando se encuentra una coincidencia, Cloud Service Mesh devuelve reglas de enrutamiento e información del servicio al cliente de gRPC.

Si se encuentra más de una coincidencia, el comportamiento no está definido y puede provocar un comportamiento impredecible. Por lo general, esto ocurre cuando se cumplen las dos condiciones siguientes:

  • Se usa el mismo nombre de host en varios mapas de URLs.
  • Varias reglas de reenvío con el esquema de balanceo de carga INTERNAL_SELF_MANAGED especifican el mismo puerto.

Por este motivo, le recomendamos que no reutilice el mismo nombre de host en varios mapas de URLs a los que hagan referencia reglas de reenvío que especifiquen el mismo puerto.

Siguientes pasos