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.

Solucionar problemas de despliegues de Envoy

En esta guía se proporciona información para ayudarte a resolver problemas de configuración con clientes de Envoy cuando ejecutas Cloud Service Mesh con APIs de Google. Para obtener información sobre cómo usar la API Client Status Discovery Service (CSDS) para investigar problemas con Cloud Service Mesh, consulta Información sobre el estado del cliente de Cloud Service Mesh.

Determinar la versión de Envoy instalada en una VM

Sigue estas instrucciones para verificar qué versión de Envoy se está ejecutando en una instancia de máquina virtual (VM).

Para verificar o comprobar la versión de Envoy, puedes hacer una de las siguientes acciones:

Comprueba los atributos de invitado de la VM en la ruta gce-service-proxy/proxy-version:

gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME
--zone ZONEc --query-path=gce-service-proxy/proxy-version

NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Consulta los registros de instancias de Cloud Logging desde la página de detalles de la instancia de VM en la consola Google Cloud con una consulta como esta:

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

Recibirás una respuesta como esta:

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }

Usa SSH para conectarte a una VM y comprueba la versión binaria:

YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Usa SSH para conectarte a una VM y a la interfaz de administración como root:

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }

Ubicaciones de los registros de Envoy

Para solucionar algunos problemas, debe examinar los registros del proxy de Envoy.

Puedes usar SSH para conectarte a la instancia de VM y obtener el archivo de registro. Es probable que la ruta sea la siguiente.

  /var/log/envoy/envoy.err.log

Los proxies no se conectan a Cloud Service Mesh

Si tus proxies no se conectan a Cloud Service Mesh, haz lo siguiente:

Comprueba si hay errores en los registros del proxy de Envoy al conectarse a trafficdirector.googleapis.com.
Si configuras netfilter (mediante iptables) para redirigir todo el tráfico al proxy de Envoy, asegúrate de que el usuario (UID) con el que ejecutas el proxy esté excluido de la redirección. De lo contrario, el tráfico se redirigirá continuamente al proxy.
Asegúrate de haber habilitado la API Cloud Service Mesh en el proyecto. En APIs y servicios de tu proyecto, busca errores de la API Cloud Service Mesh.
Confirma que el ámbito de acceso a la API de la VM esté configurado para permitir el acceso completo a lasGoogle Cloud APIs. Para ello, especifica lo siguiente al crear la VM:
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Confirma que la cuenta de servicio tiene los permisos correctos. Para obtener más información, consulta Habilitar la cuenta de servicio para acceder a la API Traffic Director.
Confirma que puedes acceder a trafficdirector.googleapis.com:443 desde la máquina virtual. Si hay problemas con este acceso, puede deberse a que un cortafuegos impide el acceso a trafficdirector.googleapis.com a través del puerto TCP 443 o a problemas de resolución de DNS para el nombre de host trafficdirector.googleapis.com.
Si usas Envoy para el proxy sidecar, confirma que la versión de Envoy es la 1.24.9 o una posterior.

No se puede acceder al servicio configurado con Cloud Service Mesh

Si no se puede acceder a un servicio configurado con Cloud Service Mesh, confirma que el proxy sidecar se está ejecutando y puede conectarse a Cloud Service Mesh.

Si usas Envoy como proxy sidecar, puedes confirmarlo ejecutando los siguientes comandos:

En la línea de comandos, confirma que el proceso de Envoy se está ejecutando:
```
ps aux | grep envoy
```
Inspecciona la configuración del tiempo de ejecución de Envoy para confirmar que Cloud Service Mesh ha configurado los recursos dinámicos. Para ver la configuración, ejecuta este comando:
```
curl http://localhost:15000/config_dump
```
Asegúrate de que la intercepción del tráfico del proxy sidecar esté configurada correctamente. Para configurar la redirección con iptables, ejecuta el comando iptables y, a continuación, grep la salida para asegurarte de que las reglas estén ahí:
```
sudo iptables -t nat -S | grep ISTIO
```
A continuación, se muestra un ejemplo del resultado de iptables interceptando la dirección IP virtual (VIP) 10.0.0.1/32 y reenviándola a un proxy de Envoy que se ejecuta en el puerto 15001 como UID 1006:
```
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
```

Si la instancia de VM se crea a través de la Google Cloud consola, algunos módulos relacionados con IPv6 no se instalan ni están disponibles hasta que se reinicia. Esto provoca que iptables falle debido a que faltan dependencias. En ese caso, reinicia la máquina virtual y vuelve a ejecutar el proceso de configuración, lo que debería solucionar el problema. No es habitual que una VM de Compute Engine que hayas creado con la CLI de Google Cloud tenga este problema.

El servicio deja de estar accesible cuando se configura el registro de acceso de Envoy

Si has usado TRAFFICDIRECTOR_ACCESS_LOG_PATH para configurar un registro de acceso de Envoy tal como se describe en Configurar atributos de arranque de Envoy para Cloud Service Mesh, asegúrate de que el usuario del sistema que ejecuta el proxy de Envoy tenga permisos para escribir en la ubicación del registro de acceso especificada.

Si no se proporcionan los permisos necesarios, los listeners no se programarán en el proxy y se podrá detectar si se comprueba el siguiente mensaje de error en el registro del proxy de Envoy:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

Para solucionar el problema, cambia los permisos del archivo elegido para que el usuario de Envoy pueda escribir en el registro de acceso.

Los mensajes de error de los registros de Envoy indican un problema de configuración

Esta sección se aplica a los despliegues que usan las APIs de balanceo de carga.

Si tienes problemas con la configuración de Cloud Service Mesh, es posible que veas alguno de los siguientes mensajes de error en los registros de Envoy:

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.

Cloud Service Mesh configuration was not found.

El último mensaje de error (Traffic Director configuration was not found) suele indicar que Envoy está solicitando la configuración de Cloud Service Mesh, pero no se encuentra ninguna configuración coincidente. Cuando Envoy se conecta a Cloud Service Mesh, presenta un nombre de red VPC (por ejemplo, my-network). A continuación, Cloud Service Mesh busca reglas de reenvío que tengan el esquema de balanceo de carga INTERNAL_SELF_MANAGED y hagan referencia al mismo nombre de red VPC.

Para solucionar este error, siga estos pasos:

Asegúrate de que haya una regla de reenvío en tu red que tenga el esquema de balanceo de carga INTERNAL_SELF_MANAGED. Anota el nombre de la red VPC de la regla de reenvío.
Si usas Cloud Service Mesh con despliegues automáticos de Envoy en Compute Engine, comprueba que el valor proporcionado a la marca --service-proxy:network coincida con el nombre de la red VPC de la regla de reenvío.
Si usas Cloud Service Mesh con despliegues manuales de Envoy en Compute Engine, comprueba lo siguiente en el archivo de arranque de Envoy:
1. Asegúrate de que el valor de la variable TRAFFICDIRECTOR_NETWORK_NAME coincida con el nombre de la red de VPC de la regla de reenvío.
2. Asegúrate de que el número de proyecto se haya definido en la variable TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.
Si vas a desplegar en GKE y usas el inyector automático, asegúrate de que el número de proyecto y el nombre de la red VPC estén configurados correctamente, según las instrucciones de Configuración de Cloud Service Mesh para pods de GKE con inyección automática de Envoy.

Solución de problemas de Compute Engine

En esta sección se proporcionan instrucciones para solucionar problemas de implementaciones de Envoy en Compute Engine.

Los procesos de arranque de Envoy y de la VM, así como otras operaciones de gestión del ciclo de vida, pueden fallar por muchos motivos, como problemas de conectividad temporales, repositorios dañados, errores en las secuencias de comandos de arranque y en los agentes de la VM, y acciones inesperadas de los usuarios.

Canales de comunicación para solucionar problemas

Google Cloud Proporciona canales de comunicación que puedes usar para entender el proceso de arranque y el estado actual de los componentes que residen en tus máquinas virtuales.

Registro de salida de puerto serie virtual

El sistema operativo, la BIOS y otras entidades a nivel de sistema de una máquina virtual suelen escribir la salida en los puertos serie. Esta salida es útil para solucionar problemas de fallos del sistema, errores de arranque, problemas de inicio y problemas de apagado.

Los agentes de arranque de Compute Engine registran todas las acciones realizadas en el puerto serie 1. Esto incluye eventos del sistema, desde la instalación básica de paquetes hasta la obtención de datos del servidor de metadatos de una instancia, iptables la configuración y el estado de instalación de Envoy.

Los agentes en la VM registran el estado de salud del proceso de Envoy, los servicios de Cloud Service Mesh recién descubiertos y cualquier otra información que pueda ser útil cuando investigues problemas con las VMs.

Registro de Cloud Monitoring

Los datos expuestos en la salida del puerto serie también se registran en Monitoring, que usa la biblioteca Golang y exporta los registros a un registro independiente para reducir el ruido. Como este registro es un registro a nivel de instancia, es posible que encuentres registros de proxy de servicio en la misma página que otros registros de instancia.

Atributos de invitado de la VM

Los atributos de invitado son un tipo específico de metadatos personalizados que tus aplicaciones pueden escribir mientras se ejecutan en tu instancia. Cualquier aplicación o usuario de tus instancias puede leer y escribir datos en estos valores de metadatos de atributos de invitado.

Los scripts de arranque de Envoy de Compute Engine y los agentes de las máquinas virtuales exponen atributos con información sobre el proceso de arranque y el estado actual de Envoy. Todos los atributos de invitado se exponen en el espacio de nombres gce-service-proxy:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

Si detectas algún problema, te recomendamos que compruebes el valor de los atributos de invitado bootstrap-status y bootstrap-last-failure. Cualquier valor de bootstrap-status que no sea FINISHED indica que el entorno de Envoy aún no se ha configurado. El valor de bookstrap-last-failure puede indicar cuál es el problema.

No se puede acceder al servicio de Cloud Service Mesh desde una VM creada con una plantilla de instancia con proxy de servicio habilitado

Para corregir este problema, sigue estos pasos:

Es posible que no se haya completado o que haya fallado la instalación de los componentes del proxy de servicio en la VM. Usa el siguiente comando para determinar si todos los componentes se han instalado correctamente:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
El atributo bootstrap-status guest tiene uno de los siguientes valores:
- [none] indica que la instalación aún no ha empezado. Es posible que la VM siga iniciándose. Vuelve a comprobar el estado en unos minutos.
- IN PROGRESS indica que aún no se han completado la instalación y la configuración de los componentes del proxy de servicio. Repite la comprobación del estado para ver si hay novedades en el proceso.
- FAILED indica que la instalación o la configuración de un componente ha fallado. Consulta el mensaje de error consultando el atributo gce-service-proxy/bootstrap-last-failure1.
- FINISHED indica que los procesos de instalación y configuración han finalizado sin errores. Sigue estas instrucciones para verificar que la intercepción del tráfico y el proxy de Envoy están configurados correctamente.
La intercepción del tráfico en la VM no está configurada correctamente para los servicios basados en Cloud Service Mesh. Inicia sesión en la VM y comprueba la iptables configuración:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examina la cadena SERVICE_PROXY_SERVICE_CIDRS para ver las entradas SERVICE_PROXY_REDIRECT como estas:
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
En la columna destination, debe haber una dirección IP o un CIDR correspondiente a cada servicio. Si no hay ninguna entrada para la dirección IP virtual (VIP), significa que hay un problema al rellenar la configuración del proxy de Envoy desde Cloud Service Mesh o que el agente en la VM ha fallado.
Los proxies de Envoy aún no han recibido su configuración de Cloud Service Mesh. Inicia sesión en la VM para comprobar la configuración del proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Examina la configuración del listener recibida de Cloud Service Mesh. Por ejemplo:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]
```
El address_prefix es la dirección IP virtual (VIP) de un servicio de Cloud Service Mesh. Apunta al mapa de URLs llamado td-routing-rule-1. Comprueba si el servicio al que quieres conectarte ya está incluido en la configuración del receptor.
El agente en la VM no se está ejecutando. El agente en la VM configura automáticamente la intercepción del tráfico cuando se crean nuevos servicios de Cloud Service Mesh. Si el agente no se está ejecutando, todo el tráfico a los nuevos servicios va directamente a los VIPs, sin pasar por el proxy de Envoy, y se agota el tiempo de espera.
1. Para verificar el estado del agente en la VM, ejecuta el siguiente comando:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. Examina los atributos del agente en la VM. El valor del atributo agent-heartbeat es la hora en la que el agente realizó por última vez una acción o una comprobación. Si el valor tiene más de cinco minutos, el agente se quedará bloqueado y deberás volver a crear la máquina virtual con el siguiente comando:
```
gcloud compute instance-groups managed recreate-instance
```
3. El atributo agent-last-failure expone el último error que se ha producido en el agente. Puede que se trate de un problema temporal que se resuelva la próxima vez que el agente lo compruebe (por ejemplo, si el error es Cannot reach the Cloud Service Mesh API server) o que sea un error permanente. Espera unos minutos y vuelve a comprobar el error.

La interceptación del tráfico entrante está configurada en el puerto de la carga de trabajo, pero no puedes conectarte al puerto desde fuera de la VM

Para corregir este problema, sigue estos pasos:

Es posible que no se haya completado o que haya fallado la instalación de los componentes del proxy de servicio en la VM. Usa el siguiente comando para determinar si todos los componentes se han instalado correctamente:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
El atributo bootstrap-status guest tiene uno de los siguientes valores:
- [none] indica que la instalación aún no ha empezado. Es posible que la VM siga iniciándose. Vuelve a comprobar el estado en unos minutos.
- IN PROGRESS indica que aún no se han completado la instalación y la configuración de los componentes del proxy de servicio. Repite la comprobación del estado para ver si hay novedades en el proceso.
- FAILED indica que la instalación o la configuración de un componente ha fallado. Consulta el mensaje de error consultando el atributo gce-service-proxy/bootstrap-last-failure1.
- FINISHED indica que los procesos de instalación y configuración han finalizado sin errores. Sigue estas instrucciones para verificar que la intercepción del tráfico y el proxy de Envoy están configurados correctamente.
La intercepción de tráfico en la VM no está configurada correctamente para el tráfico entrante. Inicia sesión en la VM y comprueba la configuración de iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examina la cadena SERVICE_PROXY_INBOUND para ver las entradas SERVICE_PROXY_IN_REDIRECT como estas:
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
Por cada puerto definido en service-proxy:serving-ports, debe haber un puerto coincidente en la columna destination. Si no hay ninguna entrada para el puerto, todo el tráfico entrante se dirige directamente a este puerto, sin pasar por el proxy de Envoy.

Verifica que no haya ninguna otra regla que rechace el tráfico a este puerto o a todos los puertos excepto a uno específico.
Los proxies de Envoy aún no han recibido su configuración para el puerto de entrada de Cloud Service Mesh. Inicia sesión en la VM para comprobar la configuración del proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Busca la configuración del receptor entrante recibida de Cloud Service Mesh:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]
```
El route_config_name, que empieza por inbound, indica un servicio especial creado para interceptar el tráfico entrante. Comprueba si el puerto al que quieres conectarte ya está incluido en la configuración del receptor en destination_port.

Problemas cuando las conexiones usan protocolos de servidor primero

Algunas aplicaciones, como MySQL, usan protocolos en los que el servidor envía el primer paquete. Esto significa que, al establecer la conexión inicial, el servidor envía los primeros bytes. Cloud Service Mesh no admite estos protocolos ni aplicaciones.

Solucionar problemas de estado de la malla de servicios

En esta guía se proporciona información para ayudarte a resolver problemas de configuración de Cloud Service Mesh.

Comportamiento de Cloud Service Mesh cuando la mayoría de los endpoints no están en buen estado

Para mejorar la fiabilidad, cuando el 99% de los endpoints no están en buen estado, Cloud Service Mesh configura el plano de datos para que no tenga en cuenta el estado de los endpoints. En su lugar, el plano de datos equilibra el tráfico entre todos los puntos finales, ya que es posible que el puerto de servicio siga funcionando.

Los backends en mal estado provocan una distribución del tráfico no óptima

Cloud Service Mesh usa la información del recurso HealthCheck asociado a un servicio backend para evaluar el estado de tus backends. Cloud Service Mesh usa este estado para enrutar el tráfico al backend en buen estado más cercano. Si algunos de tus back-ends no están en buen estado, es posible que el tráfico se siga procesando, pero con una distribución no óptima. Por ejemplo, el tráfico puede dirigirse a una región en la que todavía haya back-ends en buen estado, pero que esté mucho más lejos del cliente, lo que introduce latencia. Para identificar y monitorizar el estado de salud de tus back-ends, sigue estos pasos:

Consulta el estado de tu servicio backend en la Google Cloud consola.
Ve a los servicios de Cloud Service Mesh.
Asegúrate de que el registro esté habilitado en el recurso HealthCheck.
Si las comprobaciones del estado han empezado a fallar recientemente, inspecciona los registros de auditoría de Cloud para determinar si la configuración de HealthCheck ha cambiado recientemente.

Siguientes pasos

Para resolver problemas de configuración al desplegar servicios gRPC sin proxy, consulta Solucionar problemas de despliegues que utilizan gRPC sin proxy.
Para obtener más ayuda sobre cómo usar Cloud Service Mesh, consulta Obtener asistencia.