Resolva problemas de implementações gRPC sem proxy

Este documento fornece informações para ajudar a resolver problemas de configuração quando implementa serviços gRPC sem proxy com a Cloud Service Mesh. Para obter informações sobre como usar a API Client Status Discovery Service (CSDS) para ajudar a investigar problemas com a Cloud Service Mesh, consulte o artigo Compreender o estado do cliente da Cloud Service Mesh.

Resolução de problemas de falhas de RPC numa aplicação gRPC

Existem duas formas comuns de resolver problemas de falhas de chamadas de procedimento remoto (RPC) numa aplicação gRPC:

  1. Reveja o estado devolvido quando um RPC falha. Normalmente, o estado contém informações suficientes para ajudar a compreender a causa de uma falha de RPC.

  2. Ative o registo no tempo de execução do gRPC. Por vezes, tem de rever os registos de tempo de execução do gRPC para compreender uma falha que pode não ser propagada de volta para um estado de retorno do RPC. Por exemplo, quando uma RPC falha com um estado que indica que o prazo foi excedido, os registos podem ajudar a compreender a falha subjacente que causou o excesso do prazo.

    As diferentes implementações de idiomas do gRPC têm diferentes formas de ativar o registo no tempo de execução do gRPC:

    • gRPC em Java: o gRPC usa java.util.logging para o registo. Defina io.grpc.level para o nível FINE para ativar o registo detalhado suficiente no tempo de execução do gRPC. Uma forma típica de ativar o registo em Java é carregar a configuração de registo a partir de um ficheiro e fornecer a localização do ficheiro à JVM através de um indicador da linha de comandos. Por exemplo:

      # 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 ativar o registo específico dos módulos xDS, defina io.grpc.xds.level como FINE. Para ver registos mais detalhados, defina o nível como FINER ou FINEST.

    • gRPC em Go: ative o registo definindo variáveis de ambiente.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • gRPC em C++: para ativar o registo com o gRPC em C++, consulte as instruções em Resolução de problemas do gRPC. Para ativar o registo específico dos módulos xDS, ative os seguintes rastreadores através da GRPC_TRACE variável de ambiente para xds_client, xds_resolver, cds_lb, eds_lb, priority_lb, weighted_target_lb e lrs_lb.

    • gRPC em Node.js: para ativar o registo com gRPC em Node.js, consulte as instruções em Resolução de problemas de gRPC-JS. Para ativar o registo específico dos módulos xDS, ative os seguintes rastreadores através da GRPC_TRACE variável de ambiente para xds_client, xds_resolver, cds_balancer, eds_balancer, priority e weighted_target.

Dependendo do erro no estado de RPC ou nos registos de tempo de execução, o seu problema pode enquadrar-se numa das seguintes categorias.

Não é possível estabelecer ligação à malha de serviços na nuvem

Para resolver problemas de ligação, experimente o seguinte:

  • Verifique se o valor server_uri no ficheiro de arranque é trafficdirector.googleapis.com:443.
  • Certifique-se de que a variável de ambiente GRPC_XDS_BOOTSTRAP está definida e aponta para o ficheiro de arranque.
  • Certifique-se de que está a usar o esquema xds no URI quando cria um canal gRPC.
  • Certifique-se de que concedeu as autorizações do IAM necessárias para criar instâncias de computação e modificar uma rede num projeto.
  • Certifique-se de que ativa a conta de serviço para aceder à API Traffic Director. Em Google Cloud APIs e serviços da consola para o seu projeto, procure erros na API Traffic Director.
  • Confirme que a conta de serviço tem as autorizações corretas. As aplicações gRPC executadas na VM ou no pod usam a conta de serviço do anfitrião da VM do Compute Engine ou da instância do nó do Google Kubernetes Engine (GKE).

  • Confirme que o âmbito de acesso à API das VMs do Compute Engine ou dos clusters do GKE está definido para permitir o acesso total às APIs do Compute Engine. Para tal, especifique o seguinte quando criar as VMs ou o cluster:

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

  • Confirme se consegue aceder a trafficdirector.googleapis.com:443 a partir da VM. Se existirem problemas de acesso, os motivos possíveis incluem uma firewall que impede o acesso a trafficdirector.googleapis.com através da porta TCP 443 ou problemas de resolução de DNS para o nome de anfitrião trafficdirector.googleapis.com.

Não é possível resolver o nome do anfitrião especificado no URI

Pode encontrar uma mensagem de erro como a seguinte nos seus registos:

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

Para resolver problemas de resolução de nomes de anfitrião, experimente o seguinte:

  • Certifique-se de que está a usar uma versão e um idioma gRPC suportados.
  • Certifique-se de que a porta usada no URI para criar um canal gRPC corresponde ao valor da porta na regra de encaminhamento usada na sua configuração. Se uma porta não for especificada no URI, é usado o valor 80 para corresponder a uma regra de encaminhamento.
  • Certifique-se de que o nome do anfitrião e a porta usados no URI para criar um canal gRPC correspondem exatamente a uma regra de anfitrião no mapa de URLs usado na sua configuração.
  • Certifique-se de que a mesma regra de anfitrião não está configurada em mais do que um mapa de URLs.
  • Certifique-se de que não estão a ser usados carateres universais. As regras de anfitriões que contenham um caráter *universal são ignoradas.

A RPC falha porque o serviço não está disponível

Para resolver problemas de falhas de RPC quando um serviço não está disponível, experimente o seguinte:

  • Verifique o estado geral da Cloud Service Mesh e o estado dos seus serviços de back-end na Google Cloud consola:

    • Na coluna Mapas de regras de encaminhamento associados, certifique-se de que os mapas de URL corretos fazem referência aos serviços de back-end. Clique na coluna para verificar se os serviços de back-end especificados nas regras de correspondência de anfitriões estão corretos.
    • Na coluna Back-ends, verifique se os back-ends associados aos seus serviços de back-end estão em bom estado.
    • Se os back-ends não estiverem em bom estado, clique no serviço de back-end correspondente e certifique-se de que a verificação de funcionamento correta está configurada. As verificações de funcionamento falham frequentemente devido a regras de firewall incorretas ou em falta, ou a uma incompatibilidade nas etiquetas especificadas na VM e nas regras de firewall. Para mais informações, consulte o artigo Criar verificações de funcionamento.

  • Para que as verificações de estado do gRPC funcionem corretamente, os back-ends do gRPC têm de implementar o protocolo de verificação de estado do gRPC. Se este protocolo não estiver implementado, use uma verificação de funcionamento de TCP. Não use uma verificação de funcionamento de HTTP, HTTPS ou HTTP/2 com serviços gRPC.

  • Quando usar grupos de instâncias, certifique-se de que a porta com nome especificada no grupo de instâncias corresponde à porta usada na verificação de funcionamento. Quando usa grupos de pontos finais de rede (NEGs), certifique-se de que a especificação do serviço GKE tem a anotação NEG correta e que a verificação de funcionamento está configurada para usar a porta de serviço NEG.

  • Verifique se o protocolo de ponto final está configurado como GRPC.

O RPC falha porque a política de equilíbrio de carga não é suportada

Pode encontrar uma mensagem de erro como uma das seguintes nos seus registos:

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)

Isto acontece porque o RING_HASH não é suportado pelo idioma e pela versão específicos do cliente que está a ser usado. Para corrigir o problema, atualize a configuração do serviço de back-end para usar apenas políticas de balanceamento de carga suportadas ou atualize o cliente para uma versão suportada. Para ver as versões de cliente suportadas, consulte as funcionalidades xDS no gRPC.

A configuração de segurança não é gerada como esperado

Se estiver a configurar a segurança do serviço e a configuração de segurança não for gerada conforme esperado, examine as políticas de pontos finais na sua implementação.

O Cloud Service Mesh não suporta cenários em que existem dois ou mais recursos de políticas de pontos finais que correspondem igualmente a um ponto final, por exemplo, duas políticas com as mesmas etiquetas e portas, ou duas ou mais políticas com etiquetas diferentes que correspondem igualmente às etiquetas de um ponto final. Para mais informações sobre como as políticas de pontos finais são associadas às etiquetas de um ponto final, consulte as APIs for EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. Nestas situações, o Cloud Service Mesh não gera uma configuração de segurança a partir de nenhuma das políticas em conflito.

Resolva problemas relacionados com o estado da sua malha de serviços

Este guia fornece informações para ajudar a resolver problemas de configuração da Cloud Service Mesh.

Comportamento do Cloud Service Mesh quando a maioria dos pontos finais não está em bom estado

Para uma melhor fiabilidade, quando 99% dos pontos finais não estão em bom estado, o Cloud Service Mesh configura o plano de dados para ignorar o estado de funcionamento dos pontos finais. Em alternativa, o plano de dados equilibra o tráfego entre todos os pontos finais porque é possível que a porta de publicação ainda esteja funcional.

Os back-ends em mau estado de funcionamento causam uma distribuição não ideal do tráfego

O Cloud Service Mesh usa as informações no recurso HealthCheck anexado a um serviço de back-end para avaliar o estado dos seus back-ends. O Cloud Service Mesh usa este estado de saúde para encaminhar o tráfego para o servidor de back-end saudável mais próximo. Se alguns dos seus back-ends estiverem em mau estado, o tráfego pode continuar a ser processado, mas com uma distribuição abaixo do ideal. Por exemplo, o tráfego pode fluir para uma região onde ainda existem back-ends em bom estado, mas que está muito mais longe do cliente, o que introduz latência. Para identificar e monitorizar o estado de funcionamento dos seus back-ends, experimente os seguintes passos:

O que se segue?