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.

Configurar configuraciones avanzadas

Este documento contiene notas que pueden ser útiles al configurar Cloud Service Mesh.

Configurar una sola máquina virtual de Compute Engine para Cloud Service Mesh

Usa este procedimiento como ejemplo de cómo se pueden implementar la intercepción de tráfico y la implementación de proxy sidecar para proporcionar a una VM acceso a los servicios de Cloud Service Mesh.

Para seguir este procedimiento, debes tener instalado Docker. Sigue las instrucciones de Docker para instalar Docker Engine.

Si sigues este proceso para configurar Cloud Service Mesh en una sola VM, algunas tareas de configuración requieren que tengas acceso a un host Linux. El host puede ser una máquina local o una máquina virtual que se ejecute en tu red de nube privada virtual.

Primero, descargue y prepare los archivos de configuración y los scripts de ejemplo.

Inicia sesión en el host Linux que estés usando durante el proceso de configuración.
Descarga el archivo de los archivos necesarios en el host Linux y descomprímelo:
```
wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz
tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3
```
El archivo contiene los siguientes archivos:
- sidecar.env archivo de configuración con variables de entorno.
- iptables.sh script para configurar reglas de netfilter.
- bootstrap_template.yaml archivo de plantilla de arranque de Envoy.
- run.sh secuencia de comandos de nivel superior que usa el archivo de configuración sidecar.env para configurar iptables para la interceptación y ejecutar el proxy sidecar de Envoy.
En cada host que ejecute un proxy adicional, crea un usuario del sistema para ejecutar el proceso del proxy Envoy. Es el usuario del proxy Envoy. El inicio de sesión está inhabilitado para el usuario proxy de Envoy.
```
sudo adduser --system --disabled-login envoy
```
Edita el archivo sidecar.env para modificar la configuración. Lee los comentarios insertados en el archivo de configuración para ver una descripción detallada de cada variable.
1. En el archivo sidecar.env, asigna a la variable ENVOY_USER el nombre de usuario que quieras que sea el usuario proxy de Envoy.

A continuación, en cada host de VM que ejecute aplicaciones con Cloud Service Mesh, sigue estos pasos:

Copia todo el directorio traffic-director-xdsv3 con el archivo sidecar.env modificado en cada host de MV que ejecute aplicaciones que quieras que usen Cloud Service Mesh.
Añade la secuencia de comandos run.sh a la secuencia de comandos de inicio de tu sistema para asegurarte de que se ejecute después de cada reinicio de la VM.
En cada host de VM, ejecuta la secuencia de comandos run.sh:
```
cd traffic-director-xdsv3
sudo ./run.sh start
```

Comprueba que el proxy de Envoy se haya iniciado correctamente.

sudo ./run.sh status

Deberías ver este resultado:

OK: Envoy seems to be running.
OK: Traffic interception seems to be enabled.

Para verificar la dirección de la interceptación del tráfico, puedes hacer lo siguiente:

sudo iptables -S -t nat | grep ISTIO_REDIRECT

El resultado esperado es el siguiente:

-N ISTIO_REDIRECT
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001`

Mapas de reglas de enrutamiento

Hay dos formas de configurar el enrutamiento en un mapa de reglas de enrutamiento.

Puedes habilitar el enrutamiento en función del VIP y el puerto de destino reales del servicio. Si configura una IP virtual de su servicio como parámetro IPAddress de la regla de reenvío, solo se asociará y se enrutará el tráfico destinado a esta dirección y al puerto asociado, en función de los parámetros de host y ruta especificados en el mapa de URLs.

También puedes definir la dirección de tu regla de reenvío como 0.0.0.0. De esta forma, los proxies solo coincidirán con el tráfico en función del puerto de destino, independientemente de la dirección IP de destino de la solicitud. El tráfico se enruta en función de los parámetros de host y de ruta especificados en el mapa de URLs.

Según estos dos enfoques, los nombres de host, tal como se configuran en las reglas de host, asociados a un par de puerto y VIP de destino, o a un puerto de destino (cuando el VIP es 0.0.0.0), deben ser únicos en la configuración de tu malla de servicios. Es decir, no puedes tener dos servicios diferentes, con conjuntos de back-ends distintos, que usen el mismo nombre de host.

Independientemente del método seleccionado, el tráfico a la IP virtual a la que se resuelve el nombre de host o el FQDN de tu servicio y el puerto en el que escucha tu servicio deben interceptarse y redirigirse al proxy sidecar. Consulta los detalles completos de la configuración del host en Configurar una sola máquina virtual de Compute Engine para Cloud Service Mesh.

Cada regla de reenvío de una red de VPC debe tener una combinación única de dirección IP y puerto por red de VPC, incluida la dirección 0.0.0.0. Si creas más de una regla de reenvío con la misma dirección IP y el mismo puerto en una red de VPC concreta, solo será válida la primera regla de reenvío. Las demás se ignoran.

Para no perder tráfico, consulta la sección Configuración avanzada de la intercepción de tráfico que se incluye más abajo.

Configuración avanzada de la intercepción de tráfico

Si tus VMs ejecutan aplicaciones que necesitan acceder a servicios configurados por Cloud Service Mesh, debes instalar un proxy sidecar y configurar la intercepción del tráfico en las VMs para permitir que el proxy sidecar gestione el enrutamiento del tráfico a los back-ends de esos servicios.

Si no te parece adecuado interceptar todo el tráfico saliente de la VM para tu despliegue, puedes redirigir tráfico específico al proxy adicional, mientras que el resto del tráfico seguirá la ruta habitual definida por la configuración de red de tu host.

Para ello, modifica la configuración del host de la máquina virtual de Compute Engine en el procedimiento Configuración de Cloud Service Mesh con máquinas virtuales y despliegue manual de Envoy de la siguiente manera:

Decide el intervalo de direcciones IP al que deben resolverse los servicios controlados por Cloud Service Mesh. El tráfico destinado a estas direcciones IP se intercepta y se redirige al proxy sidecar. El intervalo es específico de tu implementación.
En el archivo sidecar.env, asigna a SERVICE_CIDR este intervalo. Netfilter redirige el tráfico a estas direcciones IP a un proxy sidecar y lo equilibra de carga según la configuración proporcionada por Cloud Service Mesh.
No es estrictamente necesario que el proxy sidecar se ejecute como un usuario dedicado que no intercepte el tráfico. Sin embargo, sigue siendo recomendable.
Después de ejecutar la secuencia de comandos run.sh, tal como se indica en el procedimiento principal, iptables se configura para interceptar y redirigir solo este intervalo específico.
Ejecuta el siguiente comando para verificar que netfilter se ha configurado correctamente. En ${SERVICE_CIDR}, sustituye el valor que hayas configurado como intervalo de direcciones IP interceptadas.
```
sudo iptables -L -t nat | grep -E "(ISTIO_REDIRECT).+${SERVICE_CIDR})"
```