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

Esta página se ha traducido con Cloud Translation API.

Reglas de reenvío de Cloud Service Mesh

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

Cloud Service Mesh usa la regla de reenvío para determinar el proxy de destino al que se dirige el tráfico de la malla.

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

En el plano de control de Cloud Service Mesh, la regla de reenvío interna, autogestionada y global dirige el tráfico a un proxy de destino según la dirección IP, el puerto y el protocolo. El proxy de destino apunta a un mapa de URLs que contiene reglas que determinan el destino del tráfico. El mapa de URLs también especifica el servicio backend predeterminado. Este servicio de backend especifica una comprobación de estado y determina el backend adecuado, como un grupo de instancias gestionado (MIG) que contiene instancias de máquina virtual (VM) o un grupo de puntos finales de red (NEG) que contiene pods de backend de Google Kubernetes Engine (GKE).

En el siguiente diagrama se muestra cómo encaja una regla de reenvío en la arquitectura de Cloud Service Mesh.

Regla de reenvío de Cloud Service Mesh destacada. — Regla de reenvío de Cloud Service Mesh destacada (haz clic en la imagen para ampliarla)

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 gestiona el tráfico que coincide con la dirección IP, el protocolo y el número de puerto de destino.

Una dirección IP 0.0.0.0 en una regla de reenvío es una de las opciones que se pueden usar con Cloud Service Mesh. Una dirección IP 0.0.0.0 significa cualquier dirección IP.

En 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 ninguna otra coincidencia específica.
En una implementación sin proxy, una dirección IP 0.0.0.0 permite especificar que no es necesaria una dirección IP. A continuación, se ofrecen más detalles sobre el uso de direcciones IP 0.0.0.0con un proxy 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`	✔	Nombre de la regla de reenvío. El nombre debe ser único en este proyecto, tener entre 1 y 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 demás deben ser un guion (a excepción del último), una letra minúscula o un dígito.
`IPAddress`	✔	Una de las siguientes: `0.0.0.0` o `127.0.0.1`, o cualquier dirección RFC 1918. Las direcciones IP de las reglas de reenvío de Cloud Service Mesh no tienen que corresponderse con los intervalos de direcciones IP de las subredes de la red de nube privada virtual (VPC). En una red de VPC, una dirección IP y un puerto concretos, solo puedes tener una regla de reenvío interna autogestionada. Por ejemplo, en la misma red de VPC, no puedes crear dos reglas de reenvío que usen la misma dirección IP `0.0.0.0` y el mismo puerto `80`.
`IPAddress` con un proxy gRPC de destino		Una regla de reenvío que hace referencia a un proxy de gRPC de destino con el campo `validateForProxyless` definido como `TRUE` y su dirección IP definida como `0.0.0.0`. Un cliente gRPC que usa el esquema `xds` no realiza una búsqueda de DNS para resolver el nombre de host en el URI del canal. En su lugar, este cliente resuelve el `hostname[:port]` en el URI de destino enviando una solicitud de servicio de detección de listeners (LDS) a Cloud Service Mesh. No se realiza ninguna búsqueda de DNS y no se necesita ninguna entrada de DNS para el nombre de host. Por lo tanto, Cloud Service Mesh usa la dirección IP `0.0.0.0` y el puerto (`80` de forma predeterminada) especificados en el URI para buscar la regla de reenvío. A continuación, Cloud Service Mesh busca una regla de host coincidente en el mapa de URLs 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 es compatible con `target-http-proxy`, `target-https-proxy` y `target-grpc-proxy`. Cuando usas la Google Cloud consola para configurar la regla de reenvío, el proxy de destino se configura automáticamente. 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 que coincide con 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 de Cloud Service Mesh es `INTERNAL_SELF_MANAGED`.
`portRange`	✔	Un puerto o un intervalo de puertos unidos por un guion. Los paquetes del protocolo especificado que se envíen a estos puertos se reenviarán al backend correspondiente. Puedes especificar un solo número de un intervalo, por ejemplo, `80` o `80-8080`. En una red de VPC, una dirección IP y un puerto concretos, solo puedes tener una regla de reenvío interna autogestionada. Por ejemplo, en la misma red de VPC, no puedes crear dos reglas de reenvío que usen la misma `0.0.0.0`dirección IP y el mismo puerto`80`. En los servicios de gRPC sin proxy, el puerto de la regla de reenvío coincide con el puerto especificado en el URI que usa una aplicación gRPC para conectarse a un servicio. Si no se especifica ningún puerto en el URI, se utiliza el puerto `80` de forma predeterminada.
`network`	✔	Especifica la red VPC en la que se encuentran las Google Cloud VMs que ejecutan proxies de Envoy. Los proxies de Envoy leen la configuración de Cloud Service Mesh que definas para la misma red en la que se hayan desplegado los proxies. Puedes usar la red de VPC llamada `default` o una red personalizada. Cloud Service Mesh solo admite el balanceo de carga para clientes de la red Google Cloud . El usuario especifica el nombre de la red en la regla de reenvío. No se admite el emparejamiento entre redes de VPC.

Añadir una regla de reenvío global

Para saber cómo configurar una regla de reenvío en la configuración general de Cloud Service Mesh con las APIs de balanceo de carga, consulte lo siguiente:

Siguientes pasos

Para usar filtros de metadatos con los que controlar qué proxies sidecar reciben la configuración adjunta a la regla de reenvío, consulta Configurar el filtrado de configuración basado en la coincidencia de MetadataFilter.
Para enrutar el tráfico, consulta la información general sobre los mapas de reglas de enrutamiento de Cloud Service Mesh.
Para obtener más información sobre Cloud Service Mesh, consulta la información general sobre Cloud Service Mesh.