Reglas de reenvío de la malla de servicios de Cloud
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 Cloud Service Mesh arquitectura.
Propiedades de las reglas de reenvío
Un recurso de regla de reenvío contiene las siguientes propiedades que se aplican la malla de servicios en la nube. 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
con 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 IP0.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: 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: No es necesario que las direcciones IP para las reglas de reenvío de la malla de servicios de Cloud a los rangos de direcciones IP de las subredes 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 |
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 Un cliente de gRPC que usa el esquema Como resultado, Cloud Service Mesh usa la dirección IP |
|
target |
✔ |
El proxy de destino al que dirige el tráfico esta regla de reenvío.
Cloud Service Mesh admite 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
La malla de servicios de Cloud 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, 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 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 |
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 Cloud Service Mesh admite el balanceo de cargas para clientes solo dentro del 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:
- Configura Cloud Service Mesh para VMs de Compute Engine con implementación automática de Envoy
- Configura Cloud Service Mesh para las VMs de Compute Engine con la implementación manual de Envoy
- Configura Cloud Service Mesh para Pods de GKE con inyección automática de Envoy
- Configura Cloud Service Mesh para Pods de GKE con la inserción manual de Envoy
- Configura la malla de servicios de Cloud para VM de Compute Engine y servicios de gRPC sin proxy
- Configura Cloud Service Mesh para Pods de GKE y servicios de gRPC sin proxy
¿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.