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.

Establece las opciones de configuración avanzada

Este documento contiene notas que podrían ser útiles para configurar la malla de servicios en la nube.

Configura una sola VM de Compute Engine para Cloud Service Mesh

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

Para usar este procedimiento, debes tener instalado Docker. Seguir 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 de Linux. El host puede ser una máquina local o una VM que se ejecute en tu red de nube privada virtual.

Primero, descarga y prepara los archivos de configuración y las secuencias de comandos de muestra.

Accede al host de Linux que usarás durante el proceso de configuración.
Descarga el archivo de los archivos requeridos en el host de Linux y descomprime el archivo:
```
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: Secuencia de comandos para configurar reglas de netfilter
- bootstrap_template.yaml: Archivo de plantilla de arranque para Envoy
- run.sh: Secuencia de comandos de nivel superior que usa el archivo de configuración sidecar.env a fin de configurar iptables para la interceptación y con el fin de ejecutar el proxy de sidecar de Envoy
En cada host que ejecute un proxy de sidecar, crea un usuario del sistema para ejecutar el proceso del proxy de Envoy. Este es el usuario del proxy de Envoy. El acceso está inhabilitado para el usuario del proxy de Envoy.
```
sudo adduser --system --disabled-login envoy
```
Edita el archivo sidecar.env para modificar la configuración. Lee los comentarios intercalados en el archivo de configuración para obtener una descripción detallada de cada variable.
1. En el archivo sidecar.env, configura la variable ENVOY_USER con el nombre de usuario que quieres que sea el usuario del proxy de Envoy.

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

Copia todo el directorio traffic-director-xdsv3 con el directorio archivo sidecar.env a cada host de VM que ejecute aplicaciones de la que esperas usar Cloud Service Mesh.
Agrega la secuencia de comandos run.sh a la secuencia de comandos de inicio del sistema, lo que garantizará que la secuencia de comandos se ejecute después de cada reinicio de VM.
En cada host de VM, ejecuta la secuencia de comandos run.sh:
```
cd traffic-director-xdsv3
sudo ./run.sh start
```

Verifica que el proxy de Envoy se haya iniciado de forma correcta.

sudo ./run.sh status

Deberías ver el siguiente resultado:

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

Puedes verificar la dirección de interceptación del tráfico con este comando:

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

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

Puedes habilitar el enrutamiento según la VIP y el puerto de destino del servicio. Si configuras una VIP del servicio como el parámetro IPAddress de la regla de reenvío, solo se hace coincidir el tráfico dirigido a esta dirección y al puerto asociado, y el tráfico se enruta según los parámetros de host y de ruta de acceso especificados en el mapa de URL.

Como alternativa, puedes establecer la dirección de regla de reenvío en 0.0.0.0. De este modo, se configurarán los proxies para que coincidan solo con el tráfico en función del puerto de destino, sin importar la dirección IP de destino de la solicitud. Luego, el tráfico se enruta en función de los parámetros de host y de ruta de acceso especificados en el mapa de URL.

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

Sin importar el método seleccionado, el tráfico a la VIP a la resuelve el nombre de host o el FQDN de tu servicio y el puerto en el que escucha tu servicio deben interceptarse y redireccionarse al proxy de sidecar. Consulta Configurar una sola VM de Compute Engine para Cloud Service Mesh para obtener todos los detalles de la configuración del host.

Cada regla de reenvío en 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 combinación de dirección IP y puerto en una red de VPC en particular, solo la primera regla de reenvío es válida. Las demás reglas se ignoran.

Para evitar perder tráfico, sigue la sección Configuración avanzada de la interceptación de tráfico.

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

Si tus VMs ejecutan aplicaciones que necesitan acceso a los servicios configurados por Cloud Service Mesh, debes instalar un proxy de sidecar y configurar la interceptación de tráfico en las VMs para permitir que el proxy de sidecar administre el enrutamiento de tráfico a los backends de esos servicios.

Si la interceptación de todo el tráfico de VM saliente no es aceptable para tu implementación, puedes redireccionar tráfico específico al proxy de sidecar, mientras que el resto del tráfico seguirá la ruta normal definida por la configuración de red del host.

Para lograrlo, modifica la configuración del host de VM de Compute Engine en el procedimiento Configuración de Cloud Service Mesh con VMs y la implementación manual de Envoy de la siguiente manera:

Decide el rango de direcciones IP a las que deben resolverse los servicios controlados por Cloud Service Mesh. El tráfico dirigido a estas direcciones IP se intercepta y se redirecciona al proxy de sidecar. El rango es específico de tu implementación.
En el archivo sidecar.env, establece el valor de SERVICE_CIDR en este rango. netfilter redirecciona el tráfico a estas direcciones IP a un proxy de sidecar y se balancean las cargas según la configuración que proporciona la malla de servicios en la nube.
No se requiere de forma estricta que el proxy de sidecar se ejecute como un usuario dedicado que se excluye de la interceptación de tráfico. Sin embargo, se recomienda este método.
Después de ejecutar la secuencia de comandos run.sh, como se indica en el procedimiento principal, iptables se configura para la intercepción y el redireccionamiento solo de este rango específico.
Ejecuta el siguiente comando para verificar que netfilter esté configurado de forma correcta. Para ${SERVICE_CIDR}, sustituye el valor que configuraste como el rango de direcciones IP interceptado.
```
sudo iptables -L -t nat | grep -E "(ISTIO_REDIRECT).+${SERVICE_CIDR})"
```