Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Reglas de reenvío para Cloud Service Mesh

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

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

Para el plano de control de Cloud Service Mesh, 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 la malla de servicios de Cloud.

Regla de reenvío de Cloud Service Mesh 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 Cloud Service Mesh. 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 Cloud Service Mesh. 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	Obligatorio	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 Cloud Service Mesh 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 Cloud Service Mesh. No hay ninguna búsqueda de DNS involucrada y no se requiere una entrada de DNS para el nombre de host. Como resultado, Cloud Service Mesh 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, Cloud Service Mesh 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. Cloud Service Mesh admite `target-http-proxy`, `target-https-proxy` y `target-grpc-proxy`. Cuando usas la consola de Google Cloud para configurar la regla de reenvío, el proxy de destino se configura de forma automática. Cuando usas la CLI de Google Cloud o la API, el proxy de destino debe existir antes de crear la regla de reenvío. Puedes usar más de una regla de reenvío con un proxy determinado.
`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 Cloud Service Mesh 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 Cloud Service Mesh 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. Cloud Service Mesh 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 la malla de servicios de Cloud con las APIs de balanceo de cargas, consulta lo siguiente:

¿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 Cloud Service Mesh.
Para obtener más información sobre Cloud Service Mesh, consulta la descripción general de Cloud Service Mesh.