Resolver problemas em implantações do Envoy

Neste guia, você encontra informações para resolver problemas de configuração do Traffic Director. Para mais informações sobre como usar a API Client Status Discovery Service (CSDS) para investigar problemas com o Traffic Director, consulte Noções básicas sobre o status do cliente do Traffic Director.

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).

Determinar a versão com implantação automática do Envoy

Para verificar ou consultar a versão do Envoy com a implantação automática, 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",
...
}

Determinar a versão com a implantação manual do Envoy

Para verificar ou consultar a versão do Envoy com a implantação manual, faça o seguinte:

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.

No Google Kubernetes Engine (GKE), os proxies do Envoy são executados com os pods do aplicativo. Você verá todos os erros nos registros do pod de aplicativo filtrados pelo contêiner envoy.

Se o cluster tiver a geração de registros da carga de trabalho ativada, é possível ver os erros no Cloud Logging. Veja a seguir um filtro possível:

resource.type="K8S_CONTAINER"
resource.labels.project_id="PROJECT_NAME"
resource.labels.location="CLUSTER_ZONE"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="WORKLOAD_NAMESPACE"
labels.k8s-pod/app="WORKLOAD_NAME"
resource.labels.container_name="envoy"

Se a geração de registros da carga de trabalho não estiver ativada no cluster, é possível ver os erros usando um comando como este:

kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.

Também é possível ver os registros de todos os Envoy que estão sendo executados em todos os clusters e qualquer carga de trabalho usando o seguinte filtro:
```
resource.type="K8S_CONTAINER"
resource.labels.container_name="envoy"
```

Com o Compute Engine e a implantação manual, defina o LOG_DIR antes de executar o script run.sh no guia de configuração.

Exemplo:
```
LOG_DIR='/var/log/envoy/'
```
Por padrão, os erros são exibidos no registro a seguir:
```
/var/log/envoy/envoy.err.log
```

Se o usuário não executou nenhuma outra configuração para exportar isso para o Logging, os erros só ficam visíveis se você usar SSH para se conectar à instância e conseguir esse arquivo.

Se você usar a implantação automática do Envoy, use SSH para se conectar à instância e obter o arquivo de registros. O caminho provavelmente será o mesmo que o caminho mencionado anteriormente.

Os proxies não se conectam ao Traffic Director

Se os proxies não se conectarem ao Traffic Director, 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 Traffic Director no projeto. Em APIs e serviços do projeto, procure erros da API Traffic Director.
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ê usa o Envoy no proxy secundário, confirme se a versão dele é 1.9.1 ou superior.

Não é possível acessar o serviço configurado com o Traffic Director

Se um serviço configurado com o Traffic Director não estiver acessível, verifique se o proxy sidecar está em execução e se ele consegue se conectar ao Traffic Director.

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 se o Traffic Director configurou recursos dinâmicos. 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 em Configurar atributos de inicialização do Envoy para o Traffic Director, verifique se o usuário do sistema que executa o proxy do Envoy tem permissões para gravar no local de registro de acesso especificado.

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.

Os aplicativos não conseguem se conectar a serviços não configurados no Traffic Director

Verifique se você configurou a interceptação de tráfego apenas para os endereços IP dos serviços configurados no Traffic Director. Se todo o tráfego for interceptado, o proxy sidecar descartará silenciosamente as conexões com os serviços não configurados no Traffic Director.

O tráfego entra em loop em um nó ou um nó falha

Se o netfilter (iptables) estiver configurado para interceptar todo o tráfego, verifique se o usuário (UID) usado para executar o proxy sidecar foi excluído da interceptação do tráfego. Caso contrário, o tráfego enviado pelo proxy sidecar voltará para o proxy indefinidamente. Como resultado, o processo do proxy sidecar pode falhar. Na configuração de referência, as regras do netfilter não interceptam o tráfego do usuário do proxy.

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

Se você tiver dificuldades com a configuração do Traffic Director, pode ser que veja alguma destas mensagens de erro nos registros do Envoy:

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Traffic Director configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Traffic Director 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.

Traffic Director configuration was not found.

Esta mensagem de erro (Traffic Director configuration was not found) geralmente indica que o Envoy está solicitando a configuração do Traffic Director, mas que nenhuma configuração correspondente pode ser encontrada. Quando o Envoy se conecta ao Traffic Director, ele apresenta um nome de rede VPC (por exemplo, my-network). Em seguida, o Traffic Director 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 Traffic Director com implantações automáticas do Envoy no Compute Engine, verifique se o valor fornecido para a sinalização --service-proxy:network corresponde ao nome de rede da regra de encaminhamento.
Se você estiver usando o Traffic Director com implantações manuais do Envoy no Compute Engine, 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 estiver usando o injetor automático, certifique-se de que o número do projeto e o nome da rede VPC estejam configurados corretamente, de acordo com as instruções na configuração do Traffic Director para pods do GKE com injeção automática do Envoy.

Solução de problemas de implantações automáticas para o Compute Engine

Nesta seção, fornecemos instruções para solucionar problemas de implantações automáticas 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 o status de integridade do processo do Envoy, os serviços recém descobertos do Traffic Director e outras informações que possam ser ú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 é possível acessar o serviço do Traffic Director a partir de uma VM criada com um modelo de instância ativado para proxy de serviço

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 Traffic Director. 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, na sigla em inglês), há um problema com o preenchimento da configuração do proxy Envoy no Traffic Director ou o agente na VM falhou.
Os proxies do Envoy ainda não receberam a configuração do Traffic Director. 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 Traffic Director. 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, na sigla em inglês) de um serviço do Traffic Director. 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 Traffic Director 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 Traffic Director 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 ainda não foram configurados para a porta de entrada do Traffic Director. 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
```
Procure a configuração de listener de entrada recebida do Traffic Director:
```
"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.

Solução de problemas de implantações automáticas em pods do GKE

Esta seção fornece instruções para solucionar problemas de implantações automáticas do Envoy em pods do GKE.

Os pods não são inicializados depois que você ativa a injeção automática do Envoy

Em algumas circunstâncias, os pods do aplicativo podem não ser iniciados corretamente. Isso pode ocorrer quando você usa um cluster particular do GKE com regras de firewall restritivas.

Se você quiser usar o Traffic Director com um cluster particular do GKE, crie uma regra de firewall extra para o webhook do injetor sidecar. Para criar uma regra de firewall que permita que o plano de controle do GKE alcance os pods na porta TCP 9443, consulte Como adicionar regras de firewall para casos de uso específicos.

Este problema pode ocorrer ao criar um pod independente ou quando uma implantação tenta criar pods.

Ao criar um pod independente (por exemplo, usando kubectl apply ou kubectl run), a linha de comando kubectl pode retornar uma mensagem de erro como esta:

Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Ao criar pods em uma implantação, os seguintes sintomas podem ser encontrados:

kubectl get pods não mostra pods associados à implantação.

kubectl get events --all-namespaces mostra uma mensagem de erro como esta:

Warning  FailedCreate  15s   replicaset-controller  Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Ao seguir o guia de configuração, você talvez encontre esse problema pela primeira vez durante a etapa Como implantar um cliente de amostra e verificar a injeção. Depois de executar kubectl create -f demo/client_sample.yaml, execute kubectl get deploy busybox para ver os pods READY de 0/1. Também é possível encontrar o erro descrevendo o replicaset associado à implantação emitindo o comando kubectl describe rs -l run=client.

Conexão recusada depois de verificar a configuração

Ao configurar o Traffic Director com injeção automática do Envoy, é possível que você receba um erro de conexão recusada ao tentar verificar a configuração. A causa pode ser uma das seguintes:

O valor de discoveryAddress no arquivo specs/01-configmap.yaml não está correto. O valor deve ser trafficdirector.googleapis.com:443.
O valor da rede VPC no arquivo specs/01-configmap.yaml não está correto.
O valor do projeto Traffic Director no arquivo specs/01-configmap.yaml não está correto.
O valor de discoveryAddress está errado no pod.
O injetor do sidecar do Istio está em execução em vez do injetor do sidecar do Traffic Director.

Veja um exemplo do arquivo specs/01-configmap.yaml em Como configurar o injetor do sidecar. Se o arquivo specs/01-configmap.yaml não contiver valores corretos, o Envoy não poderá obter a configuração de correção do Traffic Director. Para corrigir isso, examine o arquivo specs/01-configmap.yaml e verifique se os valores estão corretos e, depois, recrie o injetor automático.

Verifique o valor de discoveryAddress no arquivo specs/01-configmap.yaml e no pod. No pod, o injetor do sidecar define o valor. Para verificar o valor de discoveryAddress no pod, execute este comando:

kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'

A resposta será parecida com esta:

"discoveryAddress":"trafficdirector.googleapis.com:443"

Conexão recusada com injeção manual do Envoy e pods do GKE

Se você receber uma mensagem de conexão recusada, consulte os registros do busybox para saber se a API Traffic Director está ativada ou se as permissões estão incorretas nos registros do Envoy.

Tempo limite de conexão com injeção manual do Envoy e pods do GKE

Se você receber uma mensagem de tempo limite de conexão, é provável que o problema esteja na configuração incorreta do mapa de URL, das regras de encaminhamento ou do serviço de back-end na implantação. Verifique esses recursos para confirmar se eles estão configurados corretamente.

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 Traffic Director.

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:

Verifique o status de integridade de serviço de back-end no Console do Google Cloud.
Acessar os serviços do Traffic Director
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 registros de auditoria do Cloud para determinar se a configuração de HealthCheck mudou recentemente.

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:

Verifique se há conflitos de política de endpoint informados pelo Traffic Director.
Inspecione os Registros de auditoria do Cloud para verificar se a configuração do usuário (especificamente, EndpointPolicy, ServerTlsPolicy ou AuthorizationPolicy) foi alterada recentemente.

A seguir

Para saber como o Traffic Director funciona, consulte a visão geral do Traffic Director.
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.
Se você precisar de mais suporte para usar o Traffic Director, consulte Como receber suporte.