Está a ver a documentação da malha de serviço v1.22.

Versões disponíveis

Cloud Service Mesh
Arquivo 1.24
Arquivo 1.23
Arquivo 1.22
Arquivo 1.21
Arquivo 1.20
Arquivo 1.19
Arquivo 1.18

Esta página foi traduzida pela API Cloud Translation.

Resolva problemas de implementações do Envoy

Este guia fornece informações para ajudar a resolver problemas de configuração com clientes do Envoy quando executa a malha de serviços na nuvem com APIs Google. 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.

Determinar a versão do Envoy instalada numa VM

Siga estas instruções para verificar que versão do Envoy está a ser executada numa instância de máquina virtual (VM).

Para validar ou verificar a versão do Envoy, pode fazer uma das seguintes ações:

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 registos da instância do Cloud Logging nos detalhes da instância de VM página de registo na Google Cloud consola com uma consulta como esta:

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

Recebe uma resposta como esta:

  {
    "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 o SSH para estabelecer ligação a uma VM e verificar 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 estabelecer ligação 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",
   ...
  }

Localizações dos registos do Envoy

Para resolver alguns problemas, tem de examinar os registos do proxy Envoy.

Pode usar o SSH para estabelecer ligação à instância de VM para obter o ficheiro de registo. É provável que o caminho seja o seguinte.

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

Os proxies não se ligam ao Cloud Service Mesh

Se os seus proxies não estabelecerem ligação ao Cloud Service Mesh, faça o seguinte:

Verifique se existem erros de ligação a trafficdirector.googleapis.com nos registos do proxy Envoy.
Se configurar o netfilter (através do iptables) para redirecionar todo o tráfego para o proxy Envoy, certifique-se de que o utilizador (UID) com o qual executa o proxy está excluído do redirecionamento. Caso contrário, o tráfego entra num ciclo contínuo de retorno ao proxy.
Certifique-se de que ativou a API do Cloud Service Mesh para o projeto. Em APIs e serviços do seu projeto, procure erros da API Cloud Service Mesh.
Confirme se o âmbito de acesso à API da VM está definido para permitir o acesso total às Google Cloud APIs especificando o seguinte quando criar a VM:
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Confirme que a conta de serviço tem as autorizações corretas. Para mais informações, consulte o artigo Ative a conta de serviço para aceder à API Traffic Director.
Confirme se consegue aceder a trafficdirector.googleapis.com:443 a partir da MV. Se houver problemas com este acesso, os motivos possíveis podem ser uma firewall que impeça 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.
Se estiver a usar o Envoy para o proxy sidecar, confirme que a versão do Envoy é a 1.24.9 ou posterior.

O serviço configurado com a malha de serviço na nuvem não está acessível

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

Se estiver a usar o Envoy como um proxy sidecar, pode confirmar esta ação executando os seguintes comandos:

Na linha de comandos, confirme que o processo Envoy está em execução:
```
ps aux | grep envoy
```
Inspeccione a configuração do tempo de execução do Envoy para confirmar que a Cloud Service Mesh configurou recursos dinâmicos. Para ver a configuração, execute este comando:
```
curl http://localhost:15000/config_dump
```
Certifique-se de que a interceção de tráfego para o proxy sidecar está configurada corretamente. Para a configuração do redirecionamento com iptables, execute o comando iptables e, de seguida, grep o resultado para garantir que as suas regras estão presentes:
```
sudo iptables -t nat -S | grep ISTIO
```
Segue-se um exemplo da saída para iptablesintercetar o endereço IP virtual (VIP)10.0.0.1/32 e encaminhá-lo para um proxy do Envoy em execução na porta 15001 como 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 através da Google Cloud consola, alguns módulos relacionados com IPv6 não são instalados e ficam disponíveis antes de um reinício. Isto faz com que o iptables falhe devido a dependências em falta. Neste caso, reinicie a VM e volte a executar o processo de configuração, o que deve resolver o problema. Não é esperado que uma VM do Compute Engine que criou com a CLI Google Cloud tenha este problema.

O serviço deixa de estar acessível quando o registo de acesso do Envoy está configurado

Se usou TRAFFICDIRECTOR_ACCESS_LOG_PATH para configurar um registo de acesso do Envoy, conforme descrito no artigo Configure os atributos de arranque do Envoy para a Cloud Service Mesh, certifique-se de que o utilizador do sistema que executa o proxy do Envoy tem autorizações para escrever na localização do registo de acesso especificada.

A não concessão das autorizações necessárias faz com que os ouvintes não sejam programados no proxy e pode ser detetada através da verificação da seguinte mensagem de erro no registo 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 autorizações do ficheiro escolhido para que o utilizador do Envoy possa escrever no registo de acesso.

As mensagens de erro nos registos do Envoy indicam um problema de configuração

Esta secção aplica-se a implementações que usam as APIs de equilíbrio de carga.

Se tiver dificuldades com a configuração da malha de serviços na nuvem, pode ver qualquer uma das seguintes mensagens de erro nos registos 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) indica geralmente que o Envoy está a pedir configuração ao Cloud Service Mesh, mas não é possível encontrar nenhuma configuração correspondente. Quando o Envoy se liga ao Cloud Service Mesh, apresenta um nome de rede VPC (por exemplo, my-network). Em seguida, o Cloud Service Mesh procura regras de encaminhamento que tenham o esquema de balanceamento de carga INTERNAL_SELF_MANAGED e referenciem o mesmo nome de rede VPC.

Para corrigir este erro, faça o seguinte:

Certifique-se de que existe uma regra de encaminhamento na sua rede com o esquema de balanceamento de carga INTERNAL_SELF_MANAGED. Tome nota do nome da rede VPC da regra de encaminhamento.
Se estiver a usar a malha de serviços na nuvem com implementações automáticas do Envoy no Compute Engine, certifique-se de que o valor fornecido à flag --service-proxy:network corresponde ao nome da rede VPC da regra de encaminhamento.
Se estiver a usar o Cloud Service Mesh com implementações manuais do Envoy no Compute Engine, verifique o ficheiro de arranque do Envoy para o seguinte:
1. Certifique-se de que o valor da variável TRAFFICDIRECTOR_NETWORK_NAME corresponde ao nome da rede VPC da regra de encaminhamento.
2. Certifique-se de que o número do projeto está definido na variável TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.
Se estiver a implementar no GKE e a usar o injetor automático, certifique-se de que o número do projeto e o nome da rede VPC estão configurados corretamente, de acordo com as instruções em Configuração do Cloud Service Mesh para pods do GKE com injeção automática do Envoy.

Resolução de problemas do Compute Engine

Esta secção fornece instruções para resolver problemas de implementações do Envoy para o Compute Engine.

Os processos de arranque do Envoy e da VM, bem como outras operações de gestão do ciclo de vida, podem falhar por vários motivos, incluindo problemas de conetividade temporários, repositórios danificados, erros nos scripts de arranque e nos agentes na VM, e ações inesperadas do utilizador.

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

Google Cloud oferece canais de comunicação que pode usar para ajudar a compreender o processo de arranque e o estado atual dos componentes que residem nas suas VMs.

Registo de saída da porta de série virtual

Normalmente, o sistema operativo, o BIOS e outras entidades ao nível do sistema de uma VM escrevem a saída nas portas série. Este resultado é útil para resolver problemas de falhas de sistema, arranques falhados, problemas de arranque e problemas de encerramento.

Os agentes de arranque do Compute Engine registam todas as ações realizadas na porta série 1. Isto inclui eventos do sistema, começando pela instalação básica de pacotes através da obtenção de dados do servidor de metadados de uma instância, iptables configuração e estado de instalação do Envoy.

Os agentes na VM registam o estado de funcionamento do processo Envoy, os serviços do Cloud Service Mesh recentemente descobertos e quaisquer outras informações que possam ser úteis quando investigar problemas com VMs.

Registo do Cloud Monitoring

Os dados expostos na saída da porta série também são registados no Monitoring, que usa a biblioteca Golang e exporta os registos para um registo separado para reduzir o ruído. Uma vez que este registo é um registo ao nível da instância, pode encontrar registos de proxy de serviço na mesma página que outros registos de instâncias.

Atributos de convidado da VM

Os atributos de convidados são um tipo específico de metadados personalizados que as suas aplicações podem escrever durante a execução na sua instância. Qualquer aplicação ou utilizador nas suas instâncias pode ler e escrever dados nestes valores de metadados de atributos de convidados.

Os scripts de arranque do Envoy do Compute Engine e os agentes na VM expõem atributos com informações sobre o processo de arranque e o estado atual do Envoy. Todos os atributos de hóspedes são expostos no espaço de nomes gce-service-proxy:

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

Se encontrar problemas, recomendamos que verifique o valor dos atributos de hóspedes bootstrap-status e bootstrap-last-failure. Qualquer valor bootstrap-status que não seja FINISHED indica que o ambiente do Envoy ainda não está configurado. O valor de bookstrap-last-failure pode indicar qual é o problema.

Não é possível aceder ao serviço Cloud Service Mesh a partir de uma VM criada com um modelo de instância com proxy de serviço ativado

Para corrigir este problema, siga estes passos:

A instalação dos componentes do proxy de serviço na VM pode não ter sido concluída ou pode ter falhado. 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 bootstrap-statusconvidado está definido como um dos seguintes:
- [none] indica que a instalação ainda não começou. A VM pode ainda estar a arrancar. Verifique o estado novamente dentro de alguns minutos.
- IN PROGRESS indica que a instalação e a configuração dos componentes do proxy de serviço ainda não estão concluídas. Repita a verificação do estado para ver atualizações sobre o 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. Siga as instruções abaixo para verificar se a interceção de tráfego e o proxy Envoy estão configurados corretamente.
A interceção de tráfego na VM não está configurada corretamente para serviços baseados na Cloud Service Mesh. Inicie sessão na VM e verifique a iptables configuração:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examine a cadeia SERVICE_PROXY_SERVICE_CIDRS para ver se existem 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, deve existir um endereço IP ou um CIDR correspondente na coluna destination. Se não existir nenhuma entrada para o endereço IP virtual (VIP), existe um problema com o preenchimento da configuração do proxy Envoy a partir do Cloud Service Mesh ou o agente na VM falhou.
Os proxies Envoy ainda não receberam a respetiva configuração do Cloud Service Mesh. Inicie sessão na VM para verificar a configuração do proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Examine a configuração do ouvinte recebida do Cloud Service Mesh. Por 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 serviço do Cloud Service Mesh. Apunta para o mapa de URLs denominado td-routing-rule-1. Verifique se o serviço ao qual quer associar o domínio já está incluído na configuração do ouvinte.
O agente na VM não está em execução. O agente na VM configura automaticamente a interceção de tráfego quando são criados novos serviços da Cloud Service Mesh. Se o agente não estiver em execução, todo o tráfego para novos serviços vai diretamente para os VIPs, ignorando o proxy Envoy, e expira.
1. Valide o estado 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 a hora em que o agente executou uma ação ou uma verificação pela última vez. Se o valor tiver mais de cinco minutos, o agente está bloqueado e deve recriar a VM através do seguinte comando:
```
gcloud compute instance-groups managed recreate-instance
```
3. O atributo agent-last-failure expõe o último erro que ocorreu no agente. Este pode ser um problema temporário que se resolve na próxima vez que o agente verificar, por exemplo, se o erro for Cannot reach the Cloud Service Mesh API server, ou pode ser um erro permanente. Aguarde alguns minutos e, em seguida, verifique novamente o erro.

A interceção de tráfego de entrada está configurada para a porta da carga de trabalho, mas não consegue estabelecer ligação à porta a partir do exterior da VM

Para corrigir este problema, siga estes passos:

A instalação dos componentes do proxy de serviço na VM pode não ter sido concluída ou pode ter falhado. 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 bootstrap-statusconvidado está definido como um dos seguintes:
- [none] indica que a instalação ainda não começou. A VM pode ainda estar a arrancar. Verifique o estado novamente dentro de alguns minutos.
- IN PROGRESS indica que a instalação e a configuração dos componentes do proxy de serviço ainda não estão concluídas. Repita a verificação do estado para ver atualizações sobre o 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. Siga as instruções abaixo para verificar se a interceção de tráfego e o proxy Envoy estão configurados corretamente.
A interceção de tráfego na VM não está configurada corretamente para o tráfego de entrada. Inicie sessão 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 para ver se existem 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, deve existir uma porta correspondente na coluna destination. Se não existir nenhuma entrada para a porta, todo o tráfego de entrada é direcionado diretamente para esta porta, ignorando o proxy do Envoy.

Verifique se existem outras regras que rejeitam o tráfego para esta porta ou todas as portas, exceto uma porta específica.
Os proxies Envoy ainda não receberam a respetiva configuração para a porta de entrada do Cloud Service Mesh. Inicie sessão na VM para verificar a configuração do proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Procure a configuração do ouvinte inbound recebida do 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, que começa com inbound, indica um serviço especial criado para fins de interceção de tráfego de entrada. Verifique se a porta à qual quer estabelecer ligação já está incluída na configuração do ouvinte em destination_port.

Problemas quando as ligações usam protocolos de servidor primeiro

Algumas aplicações, como o MySQL, usam protocolos em que o servidor envia o primeiro pacote. Isto significa que, após a ligação inicial, o servidor envia os primeiros bytes. Estes protocolos e aplicações não são suportados pela Cloud Service Mesh.

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:

Verifique o estado de funcionamento do seu serviço de back-end na Google Cloud consola.
Aceda aos serviços do Cloud Service Mesh
Certifique-se de que o registo está ativado para o recurso HealthCheck.
Se as verificações de estado começaram a falhar recentemente, inspecione os registos de auditoria da nuvem para determinar se a configuração do HealthCheck foi alterada recentemente.

O que se segue?

Para resolver problemas de configuração quando implementa serviços gRPC sem proxy, consulte o artigo Resolução de problemas de implementações que usam gRPC sem proxy.
Para encontrar apoio técnico adicional para usar o Cloud Service Mesh, consulte o artigo Receber apoio técnico.