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.

Soluciona problemas de implementaciones 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 las APIs de Google. Para obtener información sobre cómo usar la API de Client Status Discovery Service (CSDS) a fin de ayudarte a investigar problemas con Cloud Service Mesh, consulta Comprende el estado de cliente de Cloud Service Mesh.

Determina la versión de Envoy instalada en una VM

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

Para verificar o comprobar la versión de Envoy, puedes hacer lo siguiente:

Verifica 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

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

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

Recibes una respuesta como la que se muestra a continuación:

  {
    "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 verificar 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 la interfaz de administrador como raíz:

  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 registros de Envoy

Para solucionar ciertos problemas, debes 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 de acceso sea la siguiente.

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

Los proxies no se conectan a Cloud Service Mesh

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

Conéctate a trafficdirector.googleapis.com para buscar errores en los registros del proxy de Envoy.
Si configuraste netfilter (a través de iptables) a fin de redireccionar todo el tráfico al proxy de Envoy, asegúrate de que el usuario (UID) que usas para ejecutar el proxy esté excluido del redireccionamiento. De lo contrario, esto hace que el tráfico se envíe en bucle al proxy de forma continua.
Asegúrate de habilitar la API de Cloud Service Mesh para el proyecto. En APIs y servicios del proyecto, busca errores de la API de Cloud Service Mesh.
Confirma que el permiso de acceso a la API de la VM esté configurado para permitir el acceso completo a las API de Google Cloud. Para ello, especifica lo siguiente cuando crees la VM:
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Confirma que la cuenta de servicio tenga los permisos correctos. Si deseas obtener más información, consulta Habilita la cuenta de servicio para acceder a la API de Traffic Director.
Confirma que puedes acceder a trafficdirector.googleapis.com:443 desde la VM. Si hay problemas con este acceso, es posible que un firewall impida el acceso al trafficdirector.googleapis.com a través del puerto TCP 443 o que haya problemas de resolución de DNS para el nombre de host trafficdirector.googleapis.com.
Si usas Envoy para el proxy de sidecar, confirma que la versión de Envoy sea la versión 1.24.9 o 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 de sidecar esté en ejecución y pueda conectarse a Cloud Service Mesh.

Si usas Envoy como el proxy de sidecar, puedes ejecutar los siguientes comandos para confirmarlo:

Desde la línea de comandos, confirma que el proceso de Envoy esté en ejecución:
```
ps aux | grep envoy
```
Inspecciona la configuración del entorno de ejecución de Envoy para confirmar que la malla de servicios de Cloud configuró los recursos dinámicos. Para ver la configuración, ejecuta este comando:
```
curl http://localhost:15000/config_dump
```
Asegúrate de que la interceptación de tráfico para el proxy de sidecar esté configurada de forma correcta. Para la configuración de redireccionamiento con iptables, ejecuta el comando iptables y, luego, usa grep para el resultado a fin de asegurarte de que las reglas estén allí:
```
sudo iptables -t nat -S | grep ISTIO
```
El siguiente es 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 consola de Google Cloud, algunos módulos relacionados con IPv6 no estarán instalados ni disponibles antes de un reinicio. Esto hace que iptables falle debido a dependencias faltantes. En este caso, reinicia la VM y vuelve a ejecutar el proceso de configuración, lo que debería resolver el problema. No se espera que una VM de Compute Engine que creaste mediante la CLI de Google Cloud tenga este problema.

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

Si usaste TRAFFICDIRECTOR_ACCESS_LOG_PATH para configurar un registro de acceso de Envoy como se describe en Configura los 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 de registro de acceso especificada.

Si no se proporcionan los permisos necesarios, los objetos de escucha no se programarán en el proxy. Esto se puede detectar si se busca 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

Si deseas resolver el problema, cambia los permisos del archivo seleccionado para que el usuario de Envoy pueda escribir en el registro de acceso.

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

Esta sección se aplica a las implementaciones que usan las APIs de balanceo de cargas.

Si tienes problemas con la configuración de Cloud Service Mesh, es posible que veas cualquiera de estos 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.

Por lo general, este último mensaje de error (Traffic Director configuration was not found) indica que Envoy solicita la configuración de Cloud Service Mesh, pero no se puede encontrar ninguna configuración que coincida. Cuando Envoy se conecta a Cloud Service Mesh, presenta un nombre de red de VPC (por ejemplo, my-network). Luego, Cloud Service Mesh busca reglas de reenvío que tengan el esquema de balanceo de cargas INTERNAL_SELF_MANAGED y hagan referencia al mismo nombre de red de VPC.

Para resolver este error, haz lo siguiente:

Asegúrate de que haya una regla de reenvío en tu red que tenga el esquema de balanceo de cargas INTERNAL_SELF_MANAGED. Anota el nombre de la red de VPC de la regla de reenvío.
Si usas Cloud Service Mesh con implementaciones automáticas de Envoy en Compute Engine, asegúrate de que el valor proporcionado para la marca --service-proxy:network coincida con el nombre de la red de VPC de la regla de reenvío.
Si usas Cloud Service Mesh con implementaciones manuales de Envoy en Compute Engine, revisa el archivo de arranque de Envoy en busca de lo siguiente:
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 esté configurado en la variable TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.
Si implementas en GKE y usas el inyector automático, asegúrate de que el número de proyecto y el nombre de la red de VPC estén configurados de forma correcta, según las instrucciones en Configuración de Cloud Service Mesh para Pods de GKE con inyección automática de Envoy.

Soluciona problemas de Compute Engine

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

Los procesos de arranque de VM y de Envoy, y las operaciones de administración del ciclo de vida adicionales pueden fallar por diversos motivos, incluidos los problemas de conectividad temporales, los repositorios dañados, los errores en las secuencias de comandos de arranque y en los agentes de VM, y las acciones inesperadas del usuario.

Canales de comunicación para solucionar problemas

Google Cloud proporciona canales de comunicación que puedes usar para comprender el proceso de arranque y el estado actual de los componentes que residen en las VM.

Registro de salida de puertos en serie virtuales

Por lo general, el sistema operativo de una VM, el BIOS y otras entidades a nivel de sistema escriben salidas en los puertos en serie. La salida es útil para solucionar fallas del sistema, arranques con fallas, problemas de inicio y problemas de cierre.

Los agentes de arranque de Compute Engine registran todas las acciones realizadas en el puerto en serie 1, junto con los eventos del sistema, a partir de la instalación básica del paquete. Para ello, obtienen los datos del servidor de metadatos de una instancia, la configuración de iptables y el estado de instalación de Envoy.

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

Registro de Cloud Monitoring

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

Atributos de invitado de la VM

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

Las secuencias de comandos de arranque de Envoy y los agentes en VM de Compute Engine exponen los atributos con información sobre el proceso de arranque y el estado actual de Envoy. Todos los atributos de invitado están expuestos en el espacio de nombres gce-service-proxy:

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

Si encuentras algún problema, te recomendamos que verifiques el valor de los atributos de invitado bootstrap-status y bootstrap-last-failure. Cualquier valor bootstrap-status que no sea FINISHED indica que el entorno de Envoy aún no se configuró. El valor de bookstrap-last-failure podría 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 habilitada para el proxy de servicio

Para corregir este problema, sigue estos pasos:

Es posible que la instalación de los componentes del proxy de servicio en la VM no se haya completado o que falle. Usa el siguiente comando para determinar si todos los componentes están instalados de forma correcta.
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
El atributo de invitado bootstrap-status se configuró como una de las siguientes opciones:
- [none] indica que todavía no comenzó la instalación. Es posible que la VM aún se esté iniciando. Vuelve a verificar el estado en unos minutos.
- IN PROGRESS indica que la instalación y la configuración de los componentes del proxy de servicio aún no se completaron. Repite la verificación de estado para obtener actualizaciones sobre el proceso.
- FAILED indica que la instalación o la configuración de un componente falló. Verifica el mensaje de error mediante una consulta al atributo gce-service-proxy/bootstrap-last-failure1.
- FINISHED indica que los procesos de instalación y configuración finalizaron sin ningún error. Usa las siguientes instrucciones para verificar que la interceptación del tráfico y el proxy de Envoy estén configurados de forma correcta.
La interceptación de tráfico en la VM no se configuró de forma correcta para los servicios basados en Cloud Service Mesh. Accede a la VM y verifica la configuración de iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examina la cadena SERVICE_PROXY_SERVICE_CIDRS para entradas SERVICE_PROXY_REDIRECT como las siguientes:
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
Para cada servicio, debe haber una dirección IP o un CIDR coincidente en la columna destination. Si no hay ninguna entrada para la dirección IP virtual (VIP), significa que hay un problema en la propagación de la configuración del proxy de Envoy desde Cloud Service Mesh, o el agente en VM falló.
Los proxies de Envoy aún no recibieron su configuración de Cloud Service Mesh. Accede a la VM y verifica la configuración del proxy de Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Examina la configuración del objeto de escucha que se recibió desde 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"
  ...
]
```
La address_prefix es la dirección IP virtual (VIP) de un servicio de Cloud Service Mesh. Apunta al mapa de URL llamado td-routing-rule-1. Verifica si el servicio al que deseas conectarte ya está incluido en la configuración del objeto de escucha.
El agente en VM no está en ejecución. El agente en VM configura de forma automática la interceptación del tráfico cuando se crean servicios de Cloud Service Mesh nuevos. Si el agente no está en ejecución, todo el tráfico hacia los servicios nuevos se dirige directamente a las VIP, se evita el proxy de Envoy y se agota el tiempo de espera.
1. Ejecuta el siguiente comando para verificar el estado del agente en VM:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. Examina los atributos del agente en VM. El valor del atributo agent-heartbeat tiene la hora en la que el agente realizó una acción o verificación por última vez. Si el valor tiene más de cinco minutos, significa que el agente se bloqueó y debes volver a crear la VM mediante el siguiente comando:
```
gcloud compute instance-groups managed recreate-instance
```
3. El atributo agent-last-failure expone el último error que ocurrió en el agente. Puede ser un problema transitorio y resolverse la próxima vez que el agente realice una verificación, por ejemplo, si el error es Cannot reach the Cloud Service Mesh API server, o puede ser un error permanente. Espera unos minutos y vuelve a verificar el error.

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

Para corregir este problema, sigue estos pasos:

Es posible que la instalación de los componentes del proxy de servicio en la VM no se haya completado o que falle. Usa el siguiente comando para determinar si todos los componentes están instalados de forma correcta.
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
El atributo de invitado bootstrap-status se configuró como una de las siguientes opciones:
- [none] indica que todavía no comenzó la instalación. Es posible que la VM aún se esté iniciando. Vuelve a verificar el estado en unos minutos.
- IN PROGRESS indica que la instalación y la configuración de los componentes del proxy de servicio aún no se completaron. Repite la verificación de estado para obtener actualizaciones sobre el proceso.
- FAILED indica que la instalación o la configuración de un componente falló. Verifica el mensaje de error mediante una consulta al atributo gce-service-proxy/bootstrap-last-failure1.
- FINISHED indica que los procesos de instalación y configuración finalizaron sin ningún error. Usa las siguientes instrucciones para verificar que la interceptación del tráfico y el proxy de Envoy estén configurados de forma correcta.
La interceptación del tráfico en la VM no se configuró de forma correcta para el tráfico entrante. Accede a la VM y verifica la configuración de iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examina la cadena SERVICE_PROXY_INBOUND para entradas SERVICE_PROXY_IN_REDIRECT como las siguientes:
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
Para cada puerto que se define en service-proxy:serving-ports, debe haber un puerto coincidente en la columna destination. Si no hay una entrada para el puerto, todo el tráfico entrante va directamente a este puerto y se omite el proxy de Envoy.

Verifica que no haya otras reglas que abandonen el tráfico a este puerto o a todos los puertos, excepto un puerto específico.
Los proxies de Envoy aún no recibieron su configuración para el puerto entrante de Cloud Service Mesh. Accede a la VM y verifica la configuración del proxy de Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Busca la configuración del objeto de escucha entrante que se recibió 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 comienza con inbound, indica un servicio especial que se creó para fines de interceptación de tráfico entrante. Verifica si el puerto al que deseas conectarte ya está incluido en la configuración del objeto de escucha en destination_port.

Problemas cuando las conexiones usan protocolos que priorizan el servidor

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

Soluciona los problemas del 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 extremos están en mal estado

Para obtener una mejor confiabilidad, cuando el 99% de los extremos no están en buen estado, Cloud Service Mesh configura el plano de datos para ignorar el estado de los extremos. En cambio, el plano de datos balancea el tráfico entre todos los extremos porque es posible que el puerto de entrega aún funcione.

Los backends en mal estado generan una distribución subóptima del tráfico

Cloud Service Mesh usa la información del recurso HealthCheck adjunto a un servicio de backend para evaluar el estado de los backends. Cloud Service Mesh usa este estado para enrutar el tráfico al backend en buen estado más cercano. Si algunos de tus backends están en mal estado, es posible que el tráfico se siga procesando, pero con una distribución subóptima. Por ejemplo, el tráfico podría fluir a una región en la que los backends en buen estado todavía están presentes, pero esto está mucho más lejos del cliente, lo que genera latencia. Para identificar y supervisar el estado de los backends, prueba los siguientes pasos:

Verifica el estado del servicio de backend en la consola de Google Cloud.
Ir a los servicios de Cloud Service Mesh
Asegúrate de que el registro esté habilitado para el recurso HealthCheck.
Si las verificaciones de estado comenzaron a fallar recientemente, inspecciona los registros de auditoría de Cloud para determinar si la configuración de HealthCheck cambió recientemente.

¿Qué sigue?

Para resolver problemas de configuración cuando implementas servicios de gRPC sin proxy, consulta Soluciona problemas de implementaciones que usan gRPC sin proxy.
Si deseas obtener asistencia adicional para usar Cloud Service Mesh, consulta Obtén asistencia.