Resolver problemas em implantações gRPC sem proxy

Este documento fornece informações para ajudar a resolver problemas de configuração ao implantar serviços gRPC sem proxy com o Traffic Director. Para mais informações sobre como usar a API Service Status Discovery (CSDS) para ajudar a investigar problemas com o Traffic Director, consulte Noções básicas sobre o status de cliente do Traffic Director.

Como solucionar problemas de falhas de RPC em um aplicativo gRPC

Há duas maneiras comuns de resolver falhas de chamada de procedimento remoto (RPC, na sigla em inglês) em um aplicativo gRPC:

  1. Analise o status retornado quando uma RPC falha. Normalmente, o status contém informações suficientes para ajudar você a entender a causa de uma falha de RPC.

  2. Ativar a geração de registros no ambiente de execução do gRPC. Às vezes é preciso analisar os registros do ambiente de execução do gRPC para entender uma falha que pode não ser propagada de volta para um status de retorno da RPC. Por exemplo, quando uma RPC falha com um status indicando que o prazo foi excedido, os registros podem ajudar você a entender a falha subjacente que fez com que o prazo fosse excedido.

    As diferentes implementações de linguagem do gRPC têm maneiras diferentes de ativar a geração de registros no ambiente de execução do gRPC.

    • gRPC em Java: o gRPC usa java.util.logging para a geração de registros. Defina io.grpc.level como nível FINE para ativar a geração de registros detalhados suficientes no ambiente de execução do gRPC. Uma maneira comum de ativar a geração de registros no Java é carregar a configuração da geração de registros de um arquivo e fornecer o local do arquivo para o JVM usando uma sinalização de linha de comando. 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 a geração de registros específica de módulos xDS, defina io.grpc.xds.level como FINE. Para ver registros mais detalhados, defina o nível como FINER ou FINEST.

    • gRPC em Go: ative a geração de registros definindo variáveis de ambiente.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • gRPC em C++: para ativar a geração de registros com gRPC em C++, consulte as instruções em Solução de problemas do gRPC. Para ativar a geração de registros específicos de módulos xDS, ative os seguintes rastreadores usando a variável de ambiente GRPC_TRACE para xds_client, xds_resolver, cds_lb: eds_lb, priority_lb, weighted_target_lb e lrs_lb.

    • gRPC no Node.js: para ativar a geração de registros com o gRPC no Node.js, consulte as instruções em Como solucionar problemas do gRPC-JS. Para ativar a geração de registros específicos de módulos xDS, ative os seguintes rastreadores usando a variável de ambiente GRPC_TRACE para xds_client, xds_resolver, cds_balancer: eds_balancer, priority e weighted_target.

Dependendo do erro no status da RPC ou nos registros do ambiente de execução, o problema pode estar em uma das seguintes categorias.

Não foi possível se conectar ao Traffic Director

Para resolver problemas de conexão, tente fazer o seguinte:

  • Verifique se o valor do server_uri no arquivo de bootstrap é trafficdirector.googleapis.com:443.
  • Certifique-se de que a variável de ambiente GRPC_XDS_BOOTSTRAP esteja definida e apontando para o arquivo de bootstrap.
  • Verifique se você está usando o esquema xds no URI ao criar um canal do gRPC.
  • Verifique se você concedeu as permissões necessárias do IAM para criar instâncias de computação e modificar uma rede em um projeto.
  • Verifique se você ativou a API Traffic Director no projeto. Em APIs e serviços do Console do Google Cloud para seu projeto, procure por erros na API Traffic Director.
  • Confirme se a conta de serviço tem as permissões corretas. Os aplicativos gRPC em execução na VM ou no pod usam a conta de serviço do host da VM do Compute Engine ou a instância do nó do Google Kubernetes Engine (GKE).

  • Confirme se o escopo de acesso da API das VMs do Compute Engine ou dos clusters do GKE está definido para permitir acesso total às APIs do Compute Engine. Para fazer isso, especifique o seguinte ao criar as VMs ou o cluster:

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

  • Confirme se você pode acessar trafficdirector.googleapis.com:443 a partir da VM. Se houver problemas de acesso, os possíveis motivos incluem um firewall que impeça o acesso a trafficdirector.googleapis.com na porta TCP 443 ou problemas de resolução de DNS para o nome do host trafficdirector.googleapis.com.

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

Talvez você veja uma mensagem de erro semelhante à seguinte nos seus registros:

[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 host, tente o seguinte:

  • Verifique se você está usando uma versão e linguagem do gRPC compatíveis.
  • Verifique se a porta usada no URI para criar um canal gRPC corresponde ao valor da porta na regra de encaminhamento usada na configuração. Se uma porta não for especificada no URI, o valor 80 será usado para corresponder a uma regra de encaminhamento.
  • Verifique se o nome do host e a porta usados no URI para criar um canal do gRPC corresponde exatamente a uma regra de host no mapa de URL usado na configuração.
  • Verifique se a mesma regra de host não está configurada em mais um mapa de URL.
  • Verifique se não há caracteres curinga em uso. As regras de host que contêm o caractere curinga * são ignoradas.

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

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

  • Verifique o status geral do Traffic Director e o status dos serviços de back-end no Console do Google Cloud:

    • Na coluna Mapas associados de regras de roteamento, verifique se 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 host estão corretos.
    • Na coluna Back-ends, verifique se os back-ends associados aos serviços de back-end estão íntegros.
    • Se os back-ends não estiverem íntegros, clique no serviço de back-end correspondente e verifique se a verificação de integridade correta está configurada. As verificações de integridade geralmente falham devido a regras de firewall incorretas ou ausentes ou a uma incompatibilidade nas tags especificadas na VM e nas regras de firewall. Para mais informações, consulte Como criar verificações de integridade.

  • Para que as verificações de integridade do gRPC funcionem corretamente, os back-ends do gRPC precisam implementar o protocolo de verificação de integridade do gRPC. Se esse protocolo não for implementado, use uma verificação de integridade TCP. Não use uma verificação de integridade HTTP, HTTPS ou HTTP/2 com os serviços gRPC.

  • Ao usar grupos de instâncias, verifique se a porta nomeada especificada no grupo de instâncias corresponde à porta usada na verificação de integridade. Ao usar grupos de endpoints de rede (NEGs, na sigla em inglês), verifique se a especificação do serviço do GKE tem a anotação de NEG correta e se a verificação de integridade está configurada para usar a porta de exibição do NEG.

  • Verifique se o protocolo do endpoint está configurado como GRPC.

A RPC falha porque a política de balanceamento de carga não é compatível

Talvez você veja uma mensagem de erro como uma das seguintes nos seus 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)

Isso ocorre porque o RING_HASH não é compatível com a linguagem e a versão específicas do cliente que está sendo usado. Para corrigir o problema, atualize a configuração do serviço de back-end para usar apenas políticas de balanceamento de carga compatíveis ou faça upgrade do cliente para uma versão compatível. Para versões de cliente compatíveis, consulte Recursos xDS no gRPC.

A configuração de segurança não foi gerada conforme esperado

Se você estiver configurando a segurança do serviço e a configuração de segurança não for gerada conforme o esperado, examine as políticas de endpoint na implantação.

O Traffic Director não é compatível com cenários em que há dois ou mais recursos de política de endpoints que correspondem igualmente a um endpoint, por exemplo, duas políticas com os mesmos rótulos e portas ou duas ou mais políticas com rótulos diferentes que correspondem igualmente aos rótulos de um endpoint. Para mais informações sobre como as políticas de endpoint são correspondidas aos rótulos de um endpoint, consulte APIs para EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. Nessas circunstâncias, o Traffic Director não gera configurações de segurança de nenhuma das políticas conflitantes.

Resolva os problemas de integridade da malha de serviço

Neste guia, você encontra informações para ajudá-lo a resolver problemas de configuração do Traffic Director.

Comportamento do Traffic Director quando a maioria dos endpoints não está íntegra

Para melhor confiabilidade, quando 99% dos endpoints não estão íntegros, o Traffic Director configura o plano de dados para desconsiderar o status de integridade dos endpoints. Em vez disso, o plano de dados equilibra o tráfego entre todos os endpoints porque é possível que a porta de exibição ainda esteja funcionando.

Back-ends não íntegros causam distribuição de tráfego abaixo do ideal

O Traffic Director usa as informações no recurso HealthCheck anexado a um serviço de back-end para avaliar a integridade dos back-ends. O Traffic Director usa esse status de integridade para rotear o tráfego para o back-end íntegro mais próximo. Se alguns dos seus back-ends não estiverem íntegros, o tráfego poderá continuar sendo processado, mas com uma distribuição não ideal. Por exemplo, o tráfego pode fluir para uma região em que os back-ends íntegros ainda estão presentes, mas muito mais distante do cliente, introduzindo latência. Para identificar e monitorar o status de integridade dos back-ends, siga as etapas a seguir:

Os back-ends rejeitam o tráfego inesperadamente

Se você configurou a segurança do serviço Traffic Director, está usando o recurso EndpointPolicy para aplicar políticas de segurança aos back-ends. A configuração incorreta do EndpointPolicy pode fazer com que o back-end rejeite o tráfego. Use os seguintes registros para resolver esse problema:

A seguir