Como solucionar problemas em implantações do Traffic Director

Neste guia, você encontra informações para ajudá-lo a resolver problemas de configuração 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.
    Acessar 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.

Como solucionar problemas de implantações automatizadas do Envoy

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.

A seguir

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