Configurar back-ends externos

Neste documento, fornecemos instruções para configurar back-ends externos para o Traffic Director usando grupos de endpoints de rede (NEGs, na sigla em inglês) de nome de domínio totalmente qualificado (FQDN, na sigla em inglês) da Internet. Presumimos que você tenha familiaridade de nível intermediário ou avançado com este assuntos:

• Balanceador de carga de aplicativo externo
• Cloud DNS
• Traffic Director
• Conectividade híbrida

Este guia de configuração fornece instruções básicas para os seguintes itens:

• Como configurar o Traffic Director para usar um NEG da Internet e o TLS não autenticado para o tráfego de saída
• Como rotear o tráfego para um serviço do Cloud Run na malha de serviço

Antes de começar

Confira a visão geral do Traffic Director com grupos de endpoints de rede da Internet.

Para os fins deste guia, as configurações de exemplo presumem o seguinte:

• todos os recursos relevantes do Compute Engine, como proxies do meio, recursos do Traffic Director, zona do Cloud DNS e conectividade híbrida, estão anexados à rede de nuvem privada virtual (VPC, na sigla em inglês) padrão.
• o serviço example.com:443 está sendo executado na infraestrutura local. O domínio example.com é exibido por três endpoints, 10.0.0.100, 10.0.0.101 e 10.0.0.102. Há rotas que garantem a conectividade dos proxies do Envoy a esses endpoints remotos.

A implantação resultante será semelhante a esta:

Exemplo de configuração com um NEG da Internet (clique para ampliar)

Roteamento de tráfego com um NEG e TLS da Internet com SNI

Depois de configurar o Traffic Director com um NEG da Internet usando o FQDN e o TLS para o tráfego de saída, a implantação de exemplo se comporta conforme ilustrado no diagrama e na descrição do tráfego a seguir.

Como o tráfego é roteado no exemplo (clique para ampliar)

As etapas da legenda a seguir correspondem à numeração no diagrama anterior.

Etapa	Descrição
0	O Envoy recebe a configuração de back-end do FQDN do Traffic Director pelo xDS.
0	O Envoy, em execução na VM, consulta continuamente o DNS para encontrar o FQDN configurado.
1	O aplicativo do usuário inicia uma solicitação.
2	Parâmetros da solicitação.
3	O proxy Envoy intercepta a solicitação. No exemplo, pressupomos que você esteja usando 0.0.0.0 como o endereço IP virtual (VIP, na sigla em inglês) da regra de encaminhamento. Quando 0.0.0.0 é o VIP, o Envoy intercepta todas as solicitações. O roteamento de solicitações é baseado apenas nos parâmetros da camada 7, independentemente do endereço IP de destino na solicitação original gerada pelo aplicativo.
4	O Envoy seleciona um endpoint remoto íntegro e executa um handshake de TLS com a SNI recebida da política de TLS do cliente.
5	O Envoy envia por proxy a solicitação para o endpoint remoto.

Não é mostrado no diagrama, mas se as verificações de integridade estiverem configuradas, o Envoy faz a verificação de integridade os endpoints remotos continuamente e roteia solicitações apenas para endpoints íntegros.

Configurar a conectividade híbrida

Este documento também pressupõe que a conectividade híbrida já está estabelecida.

• A conectividade híbrida entre a rede VPC e os serviços no local ou uma nuvem pública de terceiros é estabelecida com o Cloud VPN ou o Cloud Interconnect.
• As regras e rotas de firewall da VPC estão configuradas corretamente para estabelecer a acessibilidade bidirecional do Envoy aos endpoints de serviço particular e, opcionalmente, a um servidor DNS local.
• Para um cenário de failover de alta disponibilidade regional bem-sucedido, o roteamento dinâmico global está ativado. Para mais detalhes, consulte Modo de roteamento dinâmico.

Definir a configuração do Cloud DNS

Use os seguintes comandos para configurar uma zona particular do Cloud DNS para o domínio example.com (FQDN) que tem registros A apontando para os endpoints 10.0.0.100, 10.0.0.101, 10.0.0.102 e 10.0.0.103.

gcloud

1. Crie uma zona particular gerenciada de DNS e anexe-a à rede padrão.

   gcloud dns managed-zones create example-zone \
       --description=test \
       --dns-name=example.com \
       --networks=default \
       --visibility=private
   

2. Adicione registros DNS à zona particular.

   gcloud dns record-sets transaction start \
       --zone=example-zone
   
   gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \
       --name=example.com \
       --ttl=300 \
       --type=A \
       --zone=example-zone
   
   gcloud dns record-sets transaction execute \
       --zone=example-zone
   

Configurar o Traffic Director com um NEG de FQDN da Internet

Nesta seção, você configurará o Traffic Director com um NEG de FQDN da Internet.

Criar o NEG, a verificação de integridade e o serviço de back-end

gcloud

1. Crie o NEG da Internet.

   gcloud compute network-endpoint-groups create on-prem-service-a-neg \
       --global \
       --network-endpoint-type INTERNET_FQDN_PORT
   

2. Adicione o endpoint FQDN:Port ao NEG da Internet.

   gcloud compute network-endpoint-groups update on-prem-service-a-neg \
       --global \
       --add-endpoint=fqdn=example.com,port=443
   

3. Crie uma verificação de integridade global.

   gcloud compute health-checks create http service-a-http-health-check \
       --global
   

4. Crie um serviço de back-end global chamado on-prem-service-a e associe a verificação de integridade a ele.

   gcloud compute backend-services create on-prem-service-a \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --health-checks service-a-http-health-check
   

5. Adicione o NEG chamado on-prem-service-a-neg como o back-end do serviço de back-end.

   gcloud compute backend-services add-backend on-prem-service-a \
       --global \
       --global-network-endpoint-group \
       --network-endpoint-group on-prem-service-a-neg
   

Criar um mapa de regras de roteamento

O mapa de URL, o proxy HTTP de destino e a regra de encaminhamento constituem um mapa de regras de roteamento, que fornece informações de roteamento para o tráfego na malha.

Os mapas de URL contêm uma regra que roteia todo o tráfego HTTP para on-prem-service-a.

gcloud

1. Crie o mapa de URL:

   gcloud compute url-maps create td-url-map \
       --default-service on-prem-service-a
   

2. Crie o proxy HTTP de destino e associe o mapa de URLs ao proxy de destino.

   gcloud compute target-http-proxies create td-proxy \
       --url-map td-url-map
   

3. Crie a regra de encaminhamento global usando o endereço IP 0.0.0.0. Esse é um endereço IP especial que faz com que o plano de dados ignore o endereço IP de destino e roteie solicitações com base apenas nos parâmetros HTTP da solicitação.

   gcloud compute forwarding-rules create td-forwarding-rule \
       --global \
       --load-balancing-scheme=INTERNAL_SELF_MANAGED \
       --address=0.0.0.0 \
       --target-http-proxy=td-proxy \
       --ports=443 \
       --network=default
   

Configurar TLS e HTTPS não autenticados

Opcionalmente, se você quiser configurar o HTTPS não autenticado entre os proxies Envoy e serviços locais, use estas instruções. Estas instruções também demonstram como configurar a SNI no handshake de TLS.

Uma política de TLS do cliente especifica a identidade do cliente e o mecanismo de autenticação quando um cliente envia solicitações de saída para um determinado serviço. Uma política de TLS do cliente é anexada a um recurso de serviço de back-end usando o campo securitySettings.

gcloud

1. Crie e importe a política de TLS do cliente. Defina a SNI como o FQDN que você configurou no NEG:

   cat << EOF > client_unauthenticated_tls_policy.yaml
   name: "client_unauthenticated_tls_policy"
   sni: "example.com"
   EOF
   
   gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \
       --source=client_unauthenticated_tls_policy.yaml \
       --location=global
   

2. Se você configurou uma verificação de integridade HTTP com o serviço de back-end na seção anterior, remova a verificação de integridade do serviço de back-end:

   gcloud compute backend-services update on-prem-service-a \
       --global \
       --no-health-checks
   

3. Crie uma verificação de integridade HTTPS:

   gcloud compute health-checks create https service-a-https-health-check \
       --global
   

4. Anexe a política de TLS do cliente ao serviço de back-end que você criou anteriormente. Isso impõe HTTPS não autenticado em todas as solicitações de saída do cliente para este serviço de back-end:

   gcloud compute backend-services export on-prem-service-a \
       --global \
       --destination=on-prem-service-a.yaml
   
   cat << EOF >> on-prem-service-a.yaml
   securitySettings:
     clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy
   healthChecks:
     - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check
   EOF
   
   gcloud compute backend-services import on-prem-service-a \
       --global \
       --source=on-prem-service-a.yaml
   

É possível usar os FQDNs da Internet para rotear o tráfego para qualquer serviço acessível pelo FQDN. Por exemplo, serviços internos e externos que podem ser resolvidos por DNS ou serviços do Cloud Run.

Como migrar de um NEG IP:Port para um NEG FQDN:Port

O NEG de NON_GCP_PRIVATE_IP_PORT exige que você programe os endpoints do serviço no NEG como pares IP:PORT estáticos, enquanto o INTERNET_FQDN_NEG permite que os endpoints sejam resolvidos dinamicamente usando o DNS. É possível migrar para o NEG da Internet ao configurar registros DNS para os endpoints de serviço locais e configurar o Traffic Director conforme descrito nas etapas a seguir:

1. Configure registros DNS para o FQDN.
2. Crie um novo NEG de Internet com o FQDN.
3. Crie um novo serviço de back-end com o NEG da Internet que você criou na etapa 2 como o back-end. Associe a mesma verificação de integridade usada com serviço de back-end do NEG de conectividade híbrida com o novo serviço de back-end. Verifique se os novos endpoints remotos estão íntegros.
4. Atualize o mapa de regras de roteamento para fazer referência ao novo serviço de back-end. Para isso, substitua o back-end antigo que inclui o NEG de conectividade híbrida.
5. Se você quiser zero tempo de inatividade durante a migração em tempo real em uma implantação de produção, use o tráfego baseado em peso. Inicialmente, configure o novo serviço de back-end para receber apenas uma pequena porcentagem do tráfego. Por exemplo, 5%. Use as instruções para configurar a divisão de tráfego.
6. Verifique se os novos endpoints remotos estão exibindo o tráfego corretamente.
7. Se você estiver usando divisão de tráfego com base em peso, configure o novo serviço de back-end para receber 100% do tráfego. Essa etapa drena o serviço de back-end antigo.
8. Depois de verificar se os novos back-ends estão exibindo tráfego sem nenhum problema, exclua o serviço de back-end antigo.

Solução de problemas

Para resolver problemas de implantação, siga as instruções nesta seção. Se os problemas não forem resolvidos com essas informações, consulte Como solucionar problemas de implantações que usam o Envoy.

Um endpoint local não está recebendo tráfego

Se um endpoint não estiver recebendo tráfego, verifique se ele está sendo aprovado nas verificações de integridade. Verifique também se consultas DNS do cliente Envoy retornam o endereço IP consistentemente.

O Envoy usa o modo strict_dns para gerenciar conexões. Ele faz o balanceamento de carga do tráfego em todos os endpoints resolvidos íntegros. A ordem na qual os endpoints são resolvidos não importa no modo strict_dns, mas o Envoy drena o tráfego para qualquer endpoint que não esteja mais presente na lista de endereços IP retornados.

O cabeçalho do host HTTP não corresponde ao FQDN quando a solicitação chega ao meu servidor no local

Considere um exemplo em que o domínio example.com é resolvido para 10.0.0.1, que é o endereço IP da regra de encaminhamento, e o domínio altostrat.com é resolvido para 10.0.0.100, que é o endpoint de serviço local. Você quer enviar o tráfego para o domínio altostrat.com, que está configurado no NEG.

É possível que o aplicativo no Compute Engine ou no GKE defina o cabeçalho HTTP Host como example.com (Host: example.com), que é encaminhado para o endpoint local. Se você estiver usando HTTPS, o Envoy definirá a SNI como altostrat.com durante o handshake de TLS. O Envoy consegue a SNI com o recurso de política de TLS do cliente.

Se esse conflito estiver causando problemas no processamento ou no roteamento da solicitação quando ela chega ao endpoint local, como solução alternativa, é possível reescrever o cabeçalho Host como altostrat.com (Host: altostrat.com). Isso pode ser feito no Traffic Director usando a reescrita de URL ou no endpoint remoto, se ele tiver capacidade para reescrever cabeçalhos.

Outra alternativa menos complexa é definir o cabeçalho Host como altostrat.com (Host: altostrat.com) e usar o endereço especial 0.0.0.0 como o endereço IP da regra de encaminhamento.

O Envoy retorna muitos erros 5xx

Se o Envoy retornar um número excessivo de erros 5xx, faça o seguinte:

• Verifique os registros do Envoy para distinguir se a resposta vem do back-end (back-end no local) e qual o motivo do erro 5xx.
• Verifique se as consultas DNS são bem-sucedidas e se não há erros SERVFAIL ou NXDOMAIN.
• Confira se todos os endpoints remotos estão passando nas verificações de integridade.
• Se as verificações de integridade não estiverem configuradas, certifique-se de que todos os endpoints sejam acessíveis pelo Envoy. Verifique as regras de firewall e rotas no lado do Google Cloud e no lado do local.

Não é possível acessar serviços externos pela Internet pública pela malha de serviço

É possível enviar tráfego para serviços localizados na Internet pública usando back-ends de FQDN no Traffic Director. Primeiro, você precisa estabelecer uma conectividade com a Internet entre os clientes do Envoy e o serviço externo. Se você estiver recebendo um erro 502 durante conexões com o serviço externo, faça o seguinte:

• Verifique se você tem as rotas corretas, especificamente a rota padrão 0.0.0.0/0 e as regras de firewall configuradas.
• Verifique se as consultas DNS são bem-sucedidas e se não há erros SERVFAIL ou NXDOMAIN.
• Se o proxy Envoy estiver em execução em uma VM do Compute Engine que não tenha um endereço IP externo ou em um cluster particular do GKE, será necessário configurar o Cloud NAT ou outros meios para estabelecer a conectividade de saída com a Internet.

Se os erros persistirem ou se você estiver recebendo outros erros 5xx, verifique os registros do Envoy para ver detalhes sobre a origem dos erros.

Não é possível acessar serviços sem servidor pela malha de serviço

É possível enviar tráfego para serviços sem servidor (Cloud Run, Cloud Functions e App Engine) usando back-ends de FQDN no Traffic Director. Se o proxy Envoy estiver em execução em uma VM do Compute Engine que não tenha um endereço IP externo ou em um cluster particular do GKE, será necessário configurar o Acesso privado do Google na sub-rede para poder acessar os serviços e as APIs do Google.

A seguir

• Para saber mais sobre as políticas de TLS do cliente, consulte Segurança do serviço Traffic Director e a API Network Security.