Solução de problemas em implantações que usam o Envoy

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

Locais de registro do Envoy

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

No Google Kubernetes Engine, os proxies do Envoy são executados com os pods do aplicativo, portanto, você verá erros no registro do pod do aplicativo filtrando pelo contêiner istio-proxy. Se o cluster tiver a geração de registros de carga de trabalho ativada, será possível visualizar os erros no Cloud Logging.

Veja 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="istio-proxy"

Se a geração de registros de carga de trabalho não estiver ativada no cluster, será 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 istio-proxy --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 com o seguinte filtro:

resource.type="k8s_container"
resource.labels.container_name="istio-proxy"

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.

Por exemplo: LOG_DIR='/var/log/envoy/'

Por padrão, os erros são exibidos em /var/log/envoy/envoy.err.log.

Se o usuário não tiver feito nenhuma configuração adicional para exportar para o Logging, os erros só ficarão visíveis se você usar SSH na instância e acessar esse arquivo.

Se você usar a implantação automática do Envoy, será possível usar o SSH na instância para acessar o arquivo de registros. O caminho do arquivo provavelmente será o mesmo mostrado acima.

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ê configurou 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 seu projeto, procure erros da API Traffic Director.
    Acesse a página Biblioteca de APIs
  • Confirme se o escopo de acesso da API da VM está definido para permitir acesso total às APIs do GCP. Isso é feito especificando --scopes=https://www.googleapis.com/auth/cloud-platform no momento da criação da VM
  • Confirme se a conta de serviço tem as permissões corretas. Para mais informações, leia Como ativar a conta de serviço para acessar a API Traffic Director.
  • Confirme se é possível acessar trafficdirector.googleapis.com:443 na VM. Se houver problemas com esse acesso, as possíveis causas são: o firewall está impedindo o acesso a trafficdirector.googleapis.com pela porta TCP 443 ou problemas de resolução de DNS para o nome do host de 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, você poderá confirmar isso executando os comandos a seguir.

  1. Na linha de comando, verifique se o processo do Envoy está em execução.

    ps aux | grep envoy
    
  2. Inspecione a configuração do ambiente de execução do Envoy para confirmar se os recursos dinâmicos foram configurados pelo Traffic Director. Para ver a configuração, execute este comando:

    curl http://localhost:15000/config_dump
    
  3. 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 grep na saída para garantir que suas regras estejam disponíveis:

sudo iptables -t nat -S | grep ISTIO

Veja a seguir um exemplo da saída para iptables interceptar o VIP 10.0.0.1/32 e encaminhá-lo para um proxy 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 por meio do Console do GCP, 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 dos comandos gcloud apresente 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 o registro de acesso do Envoy conforme descrito em Como configurar atributos adicionais para proxies sidecar, verifique se o usuário do sistema que está executando o proxy Envoy tem as permissões para gravar no local do 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_LISTENER:
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 registro de acesso possa ser gravado pelo usuário Envoy.

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, as conexões com os serviços não configurados no Traffic Director serão descartadas pelo proxy sidecar.

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.

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

Quando 99% dos endpoints não estão íntegros, para melhorar a confiabilidade, o Traffic Director configura o plano de dados para desconsiderar o status de integridade dos endpoints e equilibrar o tráfego entre todos os endpoints, porque é possível que a porta de serviço ainda esteja funcionando.

Mensagens de erro nos registros do Envoy indicando 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 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 (1) tenham o esquema de balanceamento de carga INTERNAL_SELF_MANAGED e (2) façam referência ao mesmo nome de rede (por exemplo, my-network).

  1. Verifique se há uma regra de encaminhamento na rede que tenha o esquema de balanceamento de carga INTERNAL_SELF_MANAGED. Anote a rede VPC dessa regra de encaminhamento.

  2. Se você estiver usando o Traffic Director com implantações automatizadas 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.

  3. Se você estiver usando o Traffic Director com implantações manuais do Envoy no Compute Engine, verifique o arquivo de inicialização do Envoy:

    1. Verifique o valor da variável TRAFFICDIRECTOR_NETWORK_NAME e certifique-se de que o valor corresponda ao nome da rede da regra de encaminhamento.
    2. Confira se o número do projeto está definido na variável TRAFFICDIRECTOR_GCP_PROJECT_NUMBER no arquivo de inicialização do Envoy.
  4. Caso você esteja implantando no GKE e esteja usando o injetor automático, certifique-se de que o número do projeto e o nome da rede estejam configurados corretamente, de acordo com as instruções na configuração do Traffic Director para pods do Google Kubernetes Engine com injeção automática de Envoy.

Solução de problemas em implantações automatizadas do Envoy para o Compute Engine

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

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

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.

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, e 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, junto com eventos do sistema, começando com a instalação básica do pacote, recebendo dados do servidor de metadados de uma instância, da configuração de iptables e status de instalação do Envoy.

O agente na VM registra 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. Observe que esse é um registro no nível da instância. Portanto, pode ser que você encontre registros de proxy de serviço na mesma página que os 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

Siga estas etapas para corrigir esse problema.

  1. 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:

    • [nenhum] indica que a instalação ainda não foi iniciada. A VM ainda 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 o processo de instalação e configuração foi concluído sem erros. Use as instruções abaixo para verificar se a interceptação do tráfego e o proxy Envoy estão configurados corretamente.
  2. 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 VIP, há um problema com o preenchimento da configuração do proxy Envoy do Traffic Director ou o agente na VM falhou.

  3. 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. 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"
      ...
    ]
    

    address_prefix é o VIP 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.

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

    Para verificar o status do agente na VM, execute o comando a seguir:

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ --zone=ZONE
    
  5. É possível examinar 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 será interrompido e você deverá recriar a VM usando o comando gcloud compute instance-groups managed recreate-instance.

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

Siga estas etapas para corrigir esse problema.

  1. 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:

    • [nenhum] indica que a instalação ainda não foi iniciada. A VM ainda 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 o processo de instalação e configuração foi concluído sem erros. Use as instruções abaixo para verificar se a interceptação do tráfego e o proxy Envoy estão configurados corretamente.
  2. 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:

    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.

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

Como solucionar problemas de implantação automatizada com pods do GKE

Use estas instruções para resolver problemas ao usar a implantação automatizada do Envoy com pods.

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

Em alguns casos, os pods de aplicativos podem não ser ativados 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, será necessário criar uma regra de firewall adicional para o webhook do injetor de arquivo secundário. Siga as instruções deste guia para criar uma regra de firewall que permita que o plano de controle do GKE alcance os pods na porta TCP 9443.

Este problema 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 CLI 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, encontre os seguintes sintomas:

  • 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 primeiro 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 e você verá 0/1 pods READY. Também é possível encontrar o erro descrevendo o conjunto de réplicas 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, verifique se os valores estão corretos e recrie o injetor automático.

Verifique o valor de discoveryAddress no arquivo specs/01- configmap.yaml e no pod. No pod, o valor é definido pelo injetor do sidecar. 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"

A seguir

  • Para mais informações sobre como o Traffic Director funciona, consulte os conceitos dele.