Esta é a documentação da malha de serviço v1.21.

Versões disponíveis

Cloud Service Mesh
1.22 archive
1.21 archive
1.20 archive
1.19 archive
1.18 archive

Esta página foi traduzida pela API Cloud Translation.

Resolver problemas em implantações do Envoy

Este guia fornece informações para ajudar você a resolver problemas de configuração com Clientes Envoy quando você executa o Cloud Service Mesh com as APIs do Google. Para informações sobre como usar o serviço de descoberta de status do cliente (CSDS, na sigla em inglês) para ajudar a investigar problemas com o Cloud Service Mesh, consulte Noções básicas sobre o status do cliente do Cloud Service Mesh

Como determinar a versão do Envoy instalada em uma VM

Use estas instruções para verificar qual versão do Envoy está sendo executada em uma instância de máquina virtual (VM).

Para verificar a versão do Envoy, faça o seguinte:

Verifique os atributos de convidado da VM no caminho 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-version

NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Verifique os registros da instância do Cloud Logging na página do Logging dos detalhes da instância de VM no Console do Google Cloud com uma consulta como esta:

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

Você recebe esta resposta:

  {
    "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"
  }

Use SSH para se conectar a uma VM e verifique a versão binária:

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

Use o SSH para se conectar a uma VM e à interface de administração como raiz:

  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",
   ...
  }

Locais de registro do Envoy

Para resolver alguns problemas, é necessário examinar os registros de proxy do Envoy.

Você pode usar o SSH para se conectar à instância de VM e acessar o arquivo de registros. O caminho provavelmente será o seguinte.

  /var/log/envoy/envoy.err.log

Os proxies não se conectam ao Cloud Service Mesh

Se os proxies não se conectarem ao Cloud Service Mesh, faça o seguinte:

Verifique se há erros na conexão com o trafficdirector.googleapis.com nos registros do proxy Envoy.
Se você configurar o netfilter (via iptables) para redirecionar todo o tráfego para o proxy Envoy, verifique se o usuário (UID) que executou o proxy foi excluído do redirecionamento. Caso contrário, isso faz com que o tráfego volte sempre para o proxy.
Verifique se você ativou a API Cloud Service Mesh para o projeto. Em APIs e serviços do projeto, procure erros da API Cloud Service Mesh.
Confirme se o escopo de acesso da API da VM está definido para permitir acesso total às APIs do Google Cloud. Para isso, especifique o seguinte ao criar a VM:
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Confirme se a conta de serviço tem as permissões corretas. Para mais informações, consulte Ativar a conta de serviço para acessar a API Traffic Director.
Confirme se você pode acessar trafficdirector.googleapis.com:443 pela VM. Se houver problemas com esse acesso, os possíveis motivos podem ser um firewall impedindo o acesso a trafficdirector.googleapis.com pela porta TCP 443 ou problemas de resolução de DNS para o nome do host trafficdirector.googleapis.com.
Se você estiver usando o Envoy para o proxy sidecar, confirme se a versão do Envoy é a versão 1.24.9 ou mais recente.

O serviço configurado com o Cloud Service Mesh não está acessível

Se um serviço configurado com o Cloud Service Mesh não estiver acessível, confirme se o proxy sidecar está em execução e consegue se conectar ao Cloud Service Mesh.

Se você estiver usando o Envoy como proxy sidecar, é possível confirmar isso executando os comandos a seguir.

Na linha de comando, verifique se o processo do Envoy está em execução.
```
ps aux | grep envoy
```
Inspecione a configuração do ambiente de execução do Envoy para confirmar que o Cloud Service Mesh os recursos dinâmicos configurados. Para ver a configuração, execute este comando:
```
curl http://localhost:15000/config_dump
```
Certifique-se de que a interceptação de tráfego para o proxy sidecar esteja configurada corretamente. Para a configuração de redirecionamento com iptables, execute o comando iptables e, em seguida, grep na saída para garantir que suas regras estejam disponíveis:
```
sudo iptables -t nat -S | grep ISTIO
```
A seguir, há um exemplo da saída para iptables interceptar o endereço IP virtual (VIP, na sigla em inglês) 10.0.0.1/32 e encaminhá-lo para um proxy Envoy em execução na porta 15001 como o UID 1006:
```
-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
```

Se a instância de VM for criada pelo Console do GCP Cloud, alguns módulos relacionados ao ipv6 não serão instalados e não ficarão disponíveis antes da reinicialização. Isso faz com que iptables falhe devido a dependências ausentes. Nesse caso, reinicie a VM e execute novamente o processo de configuração, o que provavelmente resolverá o problema. Não é esperado que uma VM do Compute Engine criada por meio da CLI do Google Cloud tenha esse problema.

O serviço fica inacessível quando a geração de registros de acesso do Envoy é configurada

Se você usou TRAFFICDIRECTOR_ACCESS_LOG_PATH para configurar um Registro de acesso do Envoy conforme descrito nas Configurar atributos de inicialização do Envoy para o Cloud Service Mesh verificar se o usuário do sistema que executa o proxy Envoy tem permissões para gravar no local especificado do registro de acesso.

Se você não fornecer as permissões necessárias, os listeners não serão programados no proxy e poderão ser detectados verificando a seguinte mensagem de erro no registro do proxy 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

Para resolver o problema, altere as permissões projeto do arquivo escolhido para que o usuário do Envoy possa gravar registros de acesso.

Mensagens de erro nos registros do Envoy indicam um problema de configuração

Esta seção se aplica a implantações que usam as APIs de balanceamento de carga.

Se você tiver dificuldades com a configuração do Cloud Service Mesh, pode ser que aparece alguma destas mensagens de erro nos registros do 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.

A última mensagem de erro (Traffic Director configuration was not found) geralmente indica que o Envoy está solicitando a configuração do Cloud Service Mesh, mas que nenhuma configuração correspondente pode ser encontrada. Quando o Envoy se conecta ao Cloud Service Mesh, ele apresenta um nome de rede VPC Por exemplo, my-network. Em seguida, o Cloud Service Mesh procura regras de encaminhamento que têm o esquema de balanceamento de carga INTERNAL_SELF_MANAGED e fazem referência ao mesmo nome de rede VPC.

Para resolver esse erro, faça o seguinte:

Verifique se há uma regra de encaminhamento na rede que tenha o esquema de balanceamento de carga INTERNAL_SELF_MANAGED. Anote o nome da rede VPC da regra de encaminhamento.
Se você estiver usando o Cloud Service Mesh com implantações automáticas do Envoy no Compute Engine, verifique se o valor fornecido para a flag --service-proxy:network corresponde ao nome de rede da regra de encaminhamento.
Se você estiver usando o Cloud Service Mesh com implantações manuais do Envoy no Compute Engine, siga estas etapas: verifique o seguinte no arquivo de inicialização do Envoy:
1. Verifique se o valor da variável TRAFFICDIRECTOR_NETWORK_NAME corresponde ao nome da rede VPC da regra de encaminhamento.
2. Verifique se o número do projeto está definido na variável TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.
Se você estiver implantando no GKE e usando o injetor automático, verifique se o número do projeto e o nome da rede VPC estão configuradas corretamente, de acordo com as instruções Configuração do Cloud Service Mesh para pods do GKE com injeção automática do Envoy

Como solucionar problemas no Compute Engine

Esta seção fornece instruções para solucionar problemas de implantações do Envoy no Compute Engine.

Os processos de inicialização do Envoy e da VM e outras operações de gerenciamento de ciclo de vida podem falhar por vários motivos, incluindo problemas temporários de conectividade, repositórios corrompidos, bugs em scripts de bootstrap e agentes na VM e ações inesperadas do usuário.

Canais de comunicação para solução de problemas

O Google Cloud oferece canais de comunicação que podem ser usados para ajudar você a entender o processo de inicialização e o estado atual dos componentes que residem nas VMs.

Geração de registros da saída da porta serial virtual

O sistema operacional de uma VM, o BIOS e outras entidades no nível do sistema geralmente gravam a saída nas portas seriais. A saída é útil para solucionar problemas de falhas do sistema, inicializações com falha, problemas de inicialização e problemas de desligamento.

Os agentes de inicialização do Compute Engine registram todas as ações realizadas na porta serial 1. Isso inclui eventos do sistema, desde a instalação básica do pacote, até o recebimento de dados do servidor de metadados de uma instância, da configuração de iptables e status de instalação do Envoy.

Agentes na VM registram status de integridade do processo Envoy, recém-descoberto serviços do Cloud Service Mesh e outras informações que possam estar úteis ao investigar problemas com VMs.

Geração de registros do Cloud Monitoring

Os dados expostos na saída da porta serial também são registrados no Monitoring, que usa a biblioteca Golang e exporta os registros para um registro separado para reduzir o ruído. Como esse registro é no nível da instância, é possível encontrar registros de proxy de serviço na mesma página que outros registros de instância.

Atributos de convidado da VM

Os atributos de convidado são um tipo específico de metadados personalizados em que os aplicativos podem gravar enquanto estão sendo executados na instância. Qualquer aplicativo ou usuário nas instâncias pode ler e gravar dados nesses valores de metadados do atributo de convidado.

Os scripts de inicialização do Envoy do Compute Engine e agentes na VM expõem atributos com informações sobre o processo de inicialização e o status atual do Envoy. Todos os atributos de convidado são expostos no namespace gce-service-proxy:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

Se você encontrar qualquer problema, recomendamos que verifique o valor dos atributos de convidado bootstrap-status e bootstrap-last-failure. Qualquer valor bootstrap-status diferente de FINISHED indica que o ambiente Envoy ainda não foi configurado. O valor de bookstrap-last-failure pode indicar qual é o problema.

Não foi possível acessar o serviço do Cloud Service Mesh de uma VM criada usando um modelo de instância com proxy de serviço ativado

Para corrigir esse problema, siga estas etapas:

A instalação de componentes do proxy de serviço na VM pode não ter sido concluída ou falhou. Use o seguinte comando para determinar se todos os componentes estão instalados corretamente:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
O atributo de convidado bootstrap-status é definido como um dos seguintes itens:
- [none] indica que a instalação ainda não foi iniciada. A VM pode estar sendo inicializada. Verifique o status novamente em alguns minutos.
- IN PROGRESS indica que a instalação e a configuração dos componentes do proxy de serviço ainda não foram concluídas. Repita a verificação de status para atualizações no processo.
- FAILED indica que a instalação ou a configuração de um componente falhou. Verifique a mensagem de erro consultando o atributo gce-service-proxy/bootstrap-last-failure1.
- FINISHED indica que os processos de instalação e configuração foram concluídos sem erros. Use as instruções a seguir para verificar se a interceptação de tráfego e o proxy Envoy estão configurados corretamente.
A interceptação de tráfego na VM não está configurada corretamente para Serviços baseados no Cloud Service Mesh. Faça login na VM e verifique a configuração do iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examine a cadeia SERVICE_PROXY_SERVICE_CIDRS quanto a entradas SERVICE_PROXY_REDIRECT como estas:
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
Para cada serviço, é preciso haver um endereço IP ou CIDR correspondente na coluna destination. Se não houver entrada para o endereço IP virtual (VIP), há um problema com o preenchimento da configuração do proxy Envoy no Cloud Service Mesh ou o agente na VM falhou.
Os proxies Envoy não receberam a configuração do Cloud Service Mesh ainda. Faça login na VM e verifique a configuração do proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Examine a configuração do listener recebida do Cloud Service Mesh. Exemplo:
```
"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"
  ...
]
```
O address_prefix é o endereço IP virtual (VIP) de um Cloud Service Mesh serviço. Ele aponta para o mapa de URLs chamado td-routing-rule-1. Verifique se o serviço ao qual você quer se conectar já está incluído na configuração do listener.
O agente na VM não está em execução. O agente na VM configura automaticamente a interceptação do tráfego quando novos serviços do Cloud Service Mesh são criados. Se o agente não estiver em execução, todo o tráfego para novos serviços vai diretamente para VIPs, ignorando o proxy Envoy, e expira.
1. Verifique o status do agente na VM executando o seguinte comando:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. Examine os atributos do agente na VM. O valor do atributo agent-heartbeat tem o horário em que o agente realizou uma ação ou verificação pela última vez. Se o valor tiver mais de cinco minutos, o agente está travado, e você precisa recriar a VM usando o seguinte comando:
```
gcloud compute instance-groups managed recreate-instance
```
3. O atributo agent-last-failure expõe o último erro que ocorreu no agente. Pode ser um problema temporário que é resolvido na próxima vez que o agente verificar, por exemplo, se o erro é Cannot reach the Cloud Service Mesh API server ou se é um erro permanente. Aguarde alguns minutos e verifique novamente o erro.

A interceptação do tráfego de entrada está configurada na porta da carga de trabalho, mas não é possível se conectar à porta fora da VM.

Para corrigir esse problema, siga estas etapas:

A instalação de componentes do proxy de serviço na VM pode não ter sido concluída ou falhou. Use o seguinte comando para determinar se todos os componentes estão instalados corretamente:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
O atributo de convidado bootstrap-status é definido como um dos seguintes itens:
- [none] indica que a instalação ainda não foi iniciada. A VM pode estar sendo inicializada. Verifique o status novamente em alguns minutos.
- IN PROGRESS indica que a instalação e a configuração dos componentes do proxy de serviço ainda não foram concluídas. Repita a verificação de status para atualizações no processo.
- FAILED indica que a instalação ou a configuração de um componente falhou. Verifique a mensagem de erro consultando o atributo gce-service-proxy/bootstrap-last-failure1.
- FINISHED indica que os processos de instalação e configuração foram concluídos sem erros. Use as instruções a seguir para verificar se a interceptação de tráfego e o proxy Envoy estão configurados corretamente.
A interceptação de tráfego na VM não está configurada corretamente para o tráfego de entrada. Faça login na VM e verifique a configuração do iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examine a cadeia SERVICE_PROXY_INBOUND quanto a entradas SERVICE_PROXY_IN_REDIRECT como estas:
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
Para cada porta definida em service-proxy:serving-ports, é necessário haver uma porta correspondente na coluna destination. Se não houver entrada para a porta, todo o tráfego de entrada vai para essa porta diretamente, ignorando o proxy Envoy.

Verifique se não há outras regras que descartam o tráfego para esta porta ou para todas as portas, exceto para uma porta específica.
Os proxies Envoy não receberam a configuração da porta de entrada do Cloud Service Mesh. Faça login na VM para verificar o proxy Envoy configuração:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Procure a configuração de listener de entrada recebida 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"
  ...
]
```
O route_config_name, começando com inbound, indica um serviço especial criado para fins de interceptação de tráfego de entrada. Verifique se a porta a que você quer se conectar já está incluída na configuração do listener em destination_port.

Problemas quando as conexões usam protocolos primeiro no servidor

Alguns aplicativos, como o MySQL, usam protocolos em que o servidor envia o primeiro pacote. Isso significa que, na conexão inicial, os primeiros bytes são enviados pelo servidor. Esses protocolos e aplicativos não são compatíveis com o Cloud Service Mesh.

Resolva os problemas de integridade da malha de serviço

Neste guia, você encontra informações para resolver problemas de configuração da Cloud Service Mesh.

Comportamento do Cloud Service Mesh quando a maioria dos endpoints não está íntegra

Para melhor confiabilidade, quando 99% dos endpoints não estão íntegros, O Cloud Service Mesh configura o plano de dados para desconsiderar a integridade o status dos endpoints. Em vez disso, o plano de dados equilibra o tráfego entre todos dos endpoints, porque é possível que a porta de serviço ainda esteja funcional.

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

O Cloud Service Mesh usa as informações no recurso HealthCheck anexado a um serviço de back-end para avaliar a integridade dos back-ends. O Cloud Service Mesh usa esse status de integridade para rotear o tráfego para a no 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 estas etapas:

Verifique o status de integridade de serviço de back-end no Console do Google Cloud.
Acessar os serviços do Cloud Service Mesh
Verifique se a geração de registros está ativada para o recurso HealthCheck.
Se as verificações de integridade começaram a falhar recentemente, inspecione os Registros de auditoria do Cloud. para determinar se a configuração do HealthCheck foi alterada recentemente.

A seguir

Para resolver problemas de configuração ao implantar serviços gRPC sem proxy, consulte Solução de problemas em implantações que usam gRPC sem proxy.
Para encontrar mais suporte para usar o Cloud Service Mesh, consulte Como receber suporte.