Soluciona problemas de implementaciones de gRPC sin proxy

En este documento, se proporciona información para ayudarte a resolver problemas de configuración cuando implementas servicios de gRPC sin proxy con Traffic Director. Para obtener información sobre cómo usar la API de Client Status Discovery Service (CSDS) a fin de ayudarte a investigar problemas con Traffic Director, consulta Comprende el estado de cliente de Traffic Director.

Soluciona fallas de RPC en una aplicación de gRPC

Existen dos formas comunes de solucionar problemas de llamada de procedimiento remoto (RPC) en una aplicación de gRPC:

  1. Revisa el estado que se muestra cuando falla una RPC. Por lo general, el estado contiene suficiente información para ayudarte a comprender la causa de una falla de RPC.

  2. Habilita el registro en el entorno de ejecución de gRPC. A veces, deberás revisar los registros del entorno de ejecución de gRPC para comprender una falla que puede que no se propague en un estado de retorno de RPC. Por ejemplo, cuando una RPC falla con un estado que indica que se superó el plazo, los registros pueden ayudarte a comprender la falla subyacente que lo provocó.

    Las diferentes implementaciones de lenguaje de gRPC tienen diferentes maneras de habilitar el registro en el entorno de ejecución de gRPC:

    • gRPC en Java: gRPC usa java.util.logging para el registro. Configura io.grpc.level en el nivel FINE para habilitar el registro detallado suficiente en el entorno de ejecución de gRPC. Una forma típica de habilitar el registro en Java es cargar la configuración de registro desde un archivo y proporcionar la ubicación del archivo en una JVM mediante una función experimental de línea de comandos. Por ejemplo:

      # Create a file called logging.properties with the following contents:
handlers=java.util.logging.ConsoleHandler
io.grpc.level=FINE
io.grpc.xds.level=FINEST
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter

# Pass the location of the file to JVM by using this command-line flag:
-Djava.util.logging.config.file=logging.properties

      Para habilitar el registro específico de los módulos xDS, establece io.grpc.xds.level como FINE. Para ver un registro más detallado, establece el nivel en FINER o FINEST.

    • gRPC en Go: configura variables de entorno para activar el registro.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • gRPC en C++: Para habilitar el registro con gRPC en C++, consulta las instrucciones en Soluciona problemas de gRPC. A fin de habilitar el registro específico de los módulos xDS, habilita los siguientes rastreadores mediante la variable de entorno GRPC_TRACE para xds_client, xds_resolver, cds_lb, eds_lb, priority_lb, weighted_target_lb y lrs_lb.

    • gRPC en Node.js: Para habilitar el registro con gRPC en Node.js, consulta las instrucciones en Soluciona problemas de gRPC-JS. A fin de habilitar el registro específico de los módulos xDS, habilita los siguientes rastreadores mediante la variable de entorno GRPC_TRACE para xds_client, xds_resolver, cds_balancer, eds_balancer, priority y weighted_target.

Según el error en el estado de la RPC o en los registros del entorno de ejecución, el problema puede encontrarse en una de las siguientes categorías.

No se puede establecer una conexión con Traffic Director

Para solucionar los problemas de conexión, intenta lo siguiente:

  • Comprueba que el valor de server_uri en el archivo de arranque sea trafficdirector.googleapis.com:443.
  • Asegúrate de que la variable de entorno GRPC_XDS_BOOTSTRAP esté definida y orientada al archivo de arranque.
  • Asegúrate de usar el esquema xds en el URI cuando crees un canal de gRPC.
  • Asegúrate de otorgar los permisos de IAM necesarios para crear instancias de procesamiento y modificar una red en un proyecto.
  • Asegúrate de habilitar la API de Traffic Director para el proyecto. En API y servicios de la consola de Google Cloud del proyecto, busca los errores de la API de Traffic Director.
  • Confirma que la cuenta de servicio tenga los permisos correctos. Las aplicaciones de gRPC que se ejecutan en la VM o el Pod usan la cuenta de servicio del host de VM de Compute Engine o la instancia de nodo de Google Kubernetes Engine (GKE).

  • Confirma que el permiso de acceso a la API de las VM de Compute Engine o de los clústeres de GKE esté configurado para permitir el acceso completo a las API de Compute Engine. Para ello, especifica lo siguiente cuando crees las VM o el clúster:

    --scopes=https://www.googleapis.com/auth/cloud-platform

  • Confirma que puedes acceder a trafficdirector.googleapis.com:443 desde la VM. Si hay problemas de acceso, las razones posibles incluyen un firewall que impide el acceso a trafficdirector.googleapis.com a través del puerto TCP 443 o problemas de resolución de DNS para el nombre de host trafficdirector.googleapis.com.

El nombre de host especificado en el URI no se puede resolver

Es posible que se muestre un mensaje de error como el siguiente en tus registros:

[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}

Para solucionar los problemas de resolución de nombres de host, intenta lo siguiente:

  • Asegúrate de usar una versión y un lenguaje de gRPC admitidos.
  • Asegúrate de que el puerto que se usa en el URI para crear un canal de gRPC coincida con el valor del puerto en la regla de reenvío que se usó en la configuración. Si no se especifica un puerto en el URI, se usa el valor 80 para hacer coincidir una regla de reenvío.
  • Asegúrate de que el nombre de host y el puerto que se usan en el URI para crear un canal de gRPC coincidan con exactitud con una regla de host en el mapa de URL que se usó en la configuración.
  • Asegúrate de que la misma regla de host no esté configurada en más de un mapa de URL.
  • Asegúrate de que no haya comodines en uso. Se ignoran las reglas de host que contengan el carácter comodín *.

RPC falla porque el servicio no está disponible

Para solucionar fallas de RPC cuando un servicio no está disponible, intenta lo siguiente:

  • Verifica el estado general de Traffic Director y el estado de tus servicios de backend en la consola de Google Cloud:

    • En la columna Mapas de reglas de enrutamiento asociadas, asegúrate de que los mapas de URL correctos hagan referencia a los servicios de backend. Haz clic en la columna para verificar que los servicios de backend especificados en las reglas de coincidencia de host sean correctos.
    • En la columna Backends, verifica que los backends asociados con los servicios de backend estén en buen estado.
    • Si los backends están en mal estado, haz clic en el servicio de backend correspondiente y asegúrate de que se haya configurado la verificación de estado correcta. Las verificaciones de estado suelen fallar debido a reglas de firewall incorrectas o faltantes, o a una falta de coincidencia en las etiquetas especificadas en la VM y en las reglas de firewall. Para obtener más información, consulta Crea verificaciones de estado.

  • Para que las verificaciones de estado de gRPC funcionen correctamente, los backends de gRPC deben implementar el protocolo de verificación de estado de gRPC. Si no se implementa este protocolo, en su lugar usa una verificación de estado de TCP. No uses una verificación de estado HTTP, HTTPS o HTTP/2 con servicios de gRPC.

  • Cuando uses grupos de instancias, asegúrate de que el puerto con nombre especificado en el grupo de instancias coincida con el puerto que se usó en la verificación de estado. Cuando uses grupos de extremos de red (NEG), asegúrate de que la especificación del servicio de GKE tenga la anotación de NEG correcta y de que la verificación de estado esté configurada para usar el puerto de entrega del NEG.

  • Comprueba que el protocolo del extremo esté configurado como GRPC.

RPC falla porque la política del balanceo de cargas no es compatible

Es posible que aparezca un mensaje de error como uno de los siguientes en tus registros:

error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715":
unexpected lbPolicy RING_HASH in response

error={"description":"errors parsing CDS response",
"file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304,
"referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."

WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910)
at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418)
at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)

Esto se debe a que RING_HASH no es compatible con el lenguaje y la versión particular del cliente que se usa. Si quieres solucionar el problema, actualiza la configuración del servicio de backend para que solo use políticas de balanceo de cargas compatibles o actualiza el cliente a una versión compatible. Para obtener versiones de cliente compatibles, consulta funciones de xDS en gRPC.

La configuración de seguridad no se genera como se esperaba

Si estás configurando la seguridad del servicio y esta no se genera como se espera, examina las políticas de extremos en tu implementación.

Traffic Director no es compatible con situaciones en las que hay dos o más recursos de políticas de extremos que coinciden de manera equitativa con un extremo, por ejemplo, dos políticas con las mismas etiquetas y puertos, o dos o más políticas con diferentes etiquetas que coinciden de manera equitativa con las etiquetas de un extremo. Si deseas obtener más información sobre cómo las políticas de extremos coinciden con las etiquetas de un extremo, consulta las API para EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. En tales casos, Traffic Director no genera una configuración de seguridad a partir de ninguna de las políticas en conflicto.

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 Traffic Director.

Comportamiento de Traffic Director 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, Traffic Director configura el plano de datos a fin de 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

Traffic Director usa la información del recurso HealthCheck adjunto a un servicio de backend para evaluar el estado de los backends. Traffic Director 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:

Los backends rechazan el tráfico de forma inesperada

Si configuraste la seguridad del servicio de Traffic Director, usas el recurso EndpointPolicy para aplicar políticas de seguridad a los backends. Una configuración incorrecta de EndpointPolicy puede hacer que el backend rechace el tráfico. Usa los siguientes registros para solucionar este problema:

¿Qué sigue?