Configurar back-ends externos com grupos de endpoints de rede na Internet

Este documento fornece instruções para configurar back-ends externos para o Cloud Service Mesh usando grupos de endpoints de rede (NEGs) na Internet, que exigem um nome de domínio totalmente qualificado. Este documento é destinado a usuários que Ter familiaridade de intermediário a avançado com os seguintes itens:

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

  • Como configurar o Cloud Service Mesh para usar um NEG da Internet e TLS não autenticado para 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

Revise o Cloud Service Mesh com endpoint de rede na Internet grupos de usuários.

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

  • Todos os recursos relevantes do Compute Engine, como proxies intermediários, Recursos do Cloud Service Mesh, zonas do Cloud DNS e ambientes conectadas à nuvem privada virtual (VPC) padrão em uma rede VPC.
  • 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. Existem rotas que garantem a conectividade os proxies Envoy para esses endpoints remotos.

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

Exemplo de configuração com um NEG da Internet.
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 Cloud Service Mesh com um NEG na Internet usando o FQDN e o TLS para o tráfego de saída, a implantação de exemplo se comporta ilustrado no diagrama e na descrição a seguir do tráfego.

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

As etapas na legenda a seguir correspondem à numeração na diagrama.

Etapa Descrição
0 O Envoy recebe a configuração de back-end FQDN Cloud Service Mesh com 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 de firewall da VPC e as rotas estão configuradas corretamente para estabelecer a acessibilidade bidirecional do Envoy para o serviço particular endpoints e, opcionalmente, para um servidor DNS no local.
  • Para um cenário de failover de alta disponibilidade regional bem-sucedido, o roteamento dinâmico global está ativado. Para mais detalhes, consulte 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
  1. 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 Cloud Service Mesh com um NEG FQDN da Internet

Nesta seção, você vai configurar o Cloud Service Mesh com um FQDN da Internet NEG

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
  1. 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
  1. Crie uma verificação de integridade global.
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. 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
  1. 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.

Este mapa 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
  1. Criar o proxy HTTP de destino e associar o mapa de URL ao destino proxy:
    gcloud compute target-http-proxies create td-proxy \
        --url-map td-url-map
  1. 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 seu plano de dados ignore o endereço IP de destino e rotear solicitações com base apenas no Parâmetros HTTP.
    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. Um TLS do cliente é anexada a um recurso de serviço de back-end usando a 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
  1. 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
  1. Crie uma verificação de integridade HTTPS:
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. 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

NON_GCP_PRIVATE_IP_PORT O NEG exige que você programe endpoints de serviço no NEG como pares estáticos de IP:PORT, enquanto INTERNET_FQDN_NEG permite que os endpoints sejam resolvidos dinamicamente usando DNS. Para migrar para o NEG da Internet, a configuração de registros DNS para os endpoints de serviço no local Cloud Service Mesh, 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 criado na etapa 2 como back-end. Associe a mesma verificação de integridade usada ao serviço de back-end NEG de conectividade híbrida com o novo serviço de back-end. Verificar 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%. Usar as instruções para configurar o tráfego divisão.
    1. Verifique se os novos endpoints remotos estão exibindo o tráfego corretamente.
  6. 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. Esta etapa drena o back-end antigo serviço.
  7. 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 as não forem resolvidos com essas informações, consulte Solução de 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 em que os endpoints são resolvido não importa no modo strict_dns, mas o Envoy drena o tráfego para qualquer endpoint que não está 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 como 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 é seu endpoint de serviço local. Você quer para enviar tráfego para o domínio altostrat.com, que está configurado no seu NEG.

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

Se o conflito estiver causando problemas no processamento ou no roteamento da solicitação quando ela chega ao endpoint local. Como solução alternativa, reescreva o método Host cabeçalho para altostrat.com (Host: altostrat.com). Isso pode ser feito Cloud Service Mesh com a regravação de URL ou no endpoint remoto se tem o recurso de reescrita de cabeçalho.

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

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, confirme se todos os endpoints estão acessíveis pelo Envoy. Verifique suas regras e rotas de firewall no tanto no lado do Google Cloud quanto no 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 o FQDN back-ends no Cloud Service Mesh. 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 a rede sem servidor (Cloud Run, Cloud Functions e App Engine) usando back-ends FQDN no Cloud Service Mesh. Se o proxy Envoy estiver sendo executado em um VM do Compute Engine que não tem um endereço IP externo ou cluster particular do GKE, você precisa configurar Acesso privado do Google na sub-rede para acessar as APIs do Google e serviços.

A seguir