Soluciona problemas de implementaciones de Envoy
En esta guía, se proporciona información para ayudarte a resolver problemas de configuración con 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 la versión de Envoy, puedes realizar una de las siguientes acciones:
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-versionNAMESPACE 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. La ruta es probables sean los siguientes.
/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 deiptables
) 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 para tu proyecto, busca errores para 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 altrafficdirector.googleapis.com
a través del puerto TCP443
o que haya problemas de resolución de DNS para el nombre de hosttrafficdirector.googleapis.com
.Si usas Envoy para el proxy de sidecar, confirma que la versión de Envoy es la versión 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 lo siguiente: se está ejecutando el proxy de sidecar y puede 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 comandoiptables
y, luego, usagrep
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 puerto15001
como UID1006
:-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, podría ver 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.
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 Implementaciones automáticas de Envoy en Compute Engine, asegúrate de que el valor proporcionado para la marca
--service-proxy:network
coincida 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, verifica el archivo de arranque de Envoy para ver lo siguiente:
- 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. - Asegúrate de que el número de proyecto esté configurado en la variable
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
.
- Asegúrate de que el valor de la variable
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.
Solución de problemas para 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, recién descubierto. los servicios de Cloud Service Mesh y cualquier otra información que pueda útil cuando se investigan 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 instancias 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 atributogce-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 intercepción de tráfico en la VM no se configuró correctamente para Servicios basados en la malla de servicios de Cloud. Accede a la VM y revisa el
iptables
actual:gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo iptables -L -t nat
Examina la cadena
SERVICE_PROXY_SERVICE_CIDRS
para entradasSERVICE_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 no recibieron su configuración de Cloud Service Mesh aún. 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ó de la malla de servicios de Cloud. 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" ... ]
address_prefix
es la dirección IP virtual (VIP) de una malla de servicios de Cloud. servicio. Apunta al mapa de URL llamadotd-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.
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
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
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 esCannot 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 atributogce-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 entradasSERVICE_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 columnadestination
. 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 para verificar el proxy de Envoy actual:
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 coninbound
, 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 endestination_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 la malla de servicios de Cloud problemas de configuración.
Comportamiento de Cloud Service Mesh cuando la mayoría de los extremos están en mal estado
Para una mejor confiabilidad, cuando el 99% de los extremos están en mal estado, Cloud Service Mesh configura el plano de datos para ignorar la 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, el tráfico podría
siguen procesándose, 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 aún están presentes, pero que
mucho más lejos del cliente, lo que introduce 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 cambió recientemente la configuración de
HealthCheck
.
¿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.