Solucionar problemas de despliegues de gRPC sin proxy

En este documento se proporciona información que le ayudará a resolver problemas de configuración al implementar servicios gRPC sin proxy con Cloud Service Mesh. 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.

Solucionar problemas de errores de RPC en una aplicación gRPC

Hay dos formas habituales de solucionar los errores de llamadas a procedimientos remotos (RPC) en una aplicación gRPC:

  1. Revisa el estado devuelto cuando falla una llamada a procedimiento remoto. Normalmente, el estado contiene información suficiente para ayudarte a entender la causa de un error de RPC.

  2. Habilita el registro en el tiempo de ejecución de gRPC. A veces, es necesario revisar los registros del tiempo de ejecución de gRPC para comprender un fallo que puede que no se propague al estado de retorno de una llamada a procedimiento remoto. Por ejemplo, cuando una llamada a procedimiento remoto falla con un estado que indica que se ha superado el plazo, los registros pueden ayudarte a comprender el error subyacente que ha provocado que se supere el plazo.

    Las diferentes implementaciones de gRPC en distintos lenguajes tienen diferentes formas de habilitar el registro en el tiempo de ejecución de gRPC:

    • gRPC en Java: gRPC usa java.util.logging para el registro. Define io.grpc.level en el nivel FINE para habilitar un registro detallado suficiente en el tiempo de ejecución de gRPC. Una forma habitual de habilitar el registro en Java es cargar la configuración de registro desde un archivo y proporcionar la ubicación del archivo a la JVM mediante una marca 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, asigna el valor io.grpc.xds.level a FINE. Para ver un registro más detallado, define el nivel como FINER o FINEST.

    • gRPC en Go: activa el registro definiendo variables de entorno.

      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 de Solución de problemas de gRPC. Para habilitar el registro específico de los módulos xDS, habilita los siguientes rastreadores mediante la GRPC_TRACE variable de entorno 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 de Solución de problemas de gRPC-JS. Para habilitar el registro específico de los módulos xDS, habilita los siguientes rastreadores mediante la GRPC_TRACE variable de entorno para xds_client, xds_resolver, cds_balancer, eds_balancer, priority y weighted_target.

En función del error en el estado de la RPC o en los registros de tiempo de ejecución, el problema puede clasificarse en una de las siguientes categorías.

No se puede conectar a Cloud Service Mesh

Para solucionar problemas de conexión, prueba lo siguiente:

  • Comprueba que el valor de server_uri en el archivo de arranque sea trafficdirector.googleapis.com:443.
  • Comprueba que la variable de entorno GRPC_XDS_BOOTSTRAP esté definida y apunte al archivo de arranque.
  • Asegúrate de usar el esquema xds en el URI al crear un canal gRPC.
  • Asegúrate de haber concedido los permisos de gestión de identidades y accesos necesarios para crear instancias de proceso y modificar una red en un proyecto.
  • Asegúrate de habilitar la cuenta de servicio para que acceda a la API de Traffic Director. En la Google Cloud consola de APIs y servicios de tu proyecto, busca errores en la API Traffic Director.
  • Confirma que la cuenta de servicio tiene los permisos correctos. Las aplicaciones gRPC que se ejecutan en la VM o el pod usan la cuenta de servicio del host de la VM de Compute Engine o de la instancia de nodo de Google Kubernetes Engine (GKE).

  • Comprueba que el permiso de acceso a la API de las VMs de Compute Engine o de los clústeres de GKE esté configurado para permitir el acceso completo a las APIs de Compute Engine. Para ello, especifica lo siguiente al crear las VMs 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, puede deberse a que un cortafuegos impida el acceso a trafficdirector.googleapis.com a través del puerto TCP 443 o a que haya problemas de resolución de DNS para el nombre de host trafficdirector.googleapis.com.

No se puede resolver el nombre de host especificado en el URI

Es posible que aparezca 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 problemas de resolución de nombres de host, prueba lo siguiente:

  • Asegúrate de que estás usando una versión e idioma de gRPC compatibles.
  • Asegúrate de que el puerto usado en el URI para crear un canal gRPC coincida con el valor del puerto de la regla de reenvío usada en tu configuración. Si no se especifica ningún puerto en el URI, se usa el valor 80 para que coincida con 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 gRPC coincidan exactamente con una regla de host del mapa de URLs que se usa en tu configuración.
  • Asegúrate de que la misma regla de host no esté configurada en más de un mapa de URLs.
  • Asegúrate de que no se utilicen comodines. Las reglas de host que contengan un comodín * se ignoran.

Se produce un error de RPC porque el servicio no está disponible

Para solucionar los errores de RPC cuando un servicio no está disponible, prueba lo siguiente:

  • Comprueba el estado general de Cloud Service Mesh y el estado de tus servicios backend en la Google Cloud consola:

    • En la columna Mapas de reglas de enrutamiento asociados, comprueba que los mapas de URLs correctos hagan referencia a los servicios de backend. Haz clic en la columna para comprobar que los servicios backend especificados en las reglas de coincidencia de hosts sean correctos.
    • En la columna Backends (Back-ends), comprueba que los back-ends asociados a tus servicios de backend estén en buen estado.
    • Si los backends no están en buen estado, haga clic en el servicio de backend correspondiente y asegúrese de que la comprobación del estado correcta esté configurada. Las comprobaciones del estado suelen fallar debido a que las reglas de cortafuegos son incorrectas o faltan, o bien porque no coinciden las etiquetas especificadas en la VM y en las reglas de cortafuegos. Para obtener más información, consulta Crear comprobaciones del estado.

  • Para que las comprobaciones del estado de gRPC funcionen correctamente, los backends de gRPC deben implementar el protocolo de comprobación del estado de gRPC. Si no se implementa este protocolo, usa una comprobación de estado TCP. No utilices comprobaciones de estado HTTP, HTTPS o HTTP/2 con servicios gRPC.

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

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

Se produce un error en la RPC porque no se admite la política de balanceo de carga

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 idioma y la versión del cliente que se está usando. Para solucionar el problema, actualice la configuración del servicio de backend para que solo use políticas de balanceo de carga compatibles o actualice el cliente a una versión compatible. Para ver las 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 de un servicio y la configuración de seguridad no se genera como se espera, examina las políticas de endpoint de tu implementación.

Cloud Service Mesh no admite situaciones en las que haya dos o más recursos de EndpointPolicy que coincidan por igual con un endpoint. Por ejemplo, dos políticas con las mismas etiquetas y puertos, o dos o más políticas con etiquetas diferentes que coincidan por igual con las etiquetas de un endpoint. Para obtener más información sobre cómo se asocian las políticas de puntos finales con las etiquetas de un punto final, consulta las APIs de EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. En estas situaciones, Cloud Service Mesh no genera ninguna configuración de seguridad a partir de las políticas en conflicto.

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:

Siguientes pasos