Configure back-ends externos com grupos de pontos finais de rede da Internet

Este documento fornece instruções para configurar back-ends externos para a Cloud Service Mesh através de grupos de pontos finais de rede (NEGs) da Internet, que requerem um nome de domínio totalmente qualificado. Este documento destina-se a utilizadores que têm um nível de familiaridade intermédio a avançado com o seguinte:

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

  • Configurar a malha de serviços na nuvem para usar um NEG de Internet e TLS não autenticado para tráfego de saída
  • Encaminhar tráfego para um serviço do Cloud Run a partir da sua malha de serviços

Antes de começar

Reveja a vista geral da rede de serviços na nuvem com grupos de pontos finais da rede da Internet.

Para efeitos deste guia, as configurações de exemplo pressupõem o seguinte:

  • Todos os recursos relevantes do Compute Engine, como proxies intermédios, recursos do Cloud Service Mesh, zonas do Cloud DNS e conetividade híbrida, estão anexados à rede da nuvem virtual privada (VPC) predefinida.
  • O serviço example.com:443 está a ser executado na sua infraestrutura no local. O domínio example.com é publicado por três pontos finais: 10.0.0.100, 10.0.0.101 e 10.0.0.102. Existem rotas que garantem a conetividade dos proxies do Envoy a estes pontos finais remotos.

A implementação resultante é semelhante à seguinte.

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

Encaminhamento de tráfego com um NEG de Internet e TLS com SNI

Depois de configurar a malha de serviços na nuvem com um NEG da Internet através do FQDN e do TLS para o tráfego de saída, a implementação de exemplo comporta-se conforme ilustrado no diagrama e na descrição do tráfego seguintes.

Como o tráfego é encaminhado no exemplo.
Como o tráfego é encaminhado no exemplo (clique para aumentar)

Os passos na legenda seguinte correspondem à numeração no diagrama anterior.

Passo Descrição
0 O Envoy recebe a configuração do back-end FQDN do Cloud Service Mesh através do xDS.
0 O Envoy, em execução na VM, consulta continuamente o DNS para o FQDN configurado.
1 A aplicação do utilizador inicia um pedido.
2 Parâmetros do pedido.
3 O proxy Envoy interceta o pedido. O exemplo pressupõe que está a usar 0.0.0.0 como o endereço IP virtual (VIP) da regra de encaminhamento. Quando 0.0.0.0 é o VIP, o Envoy interceta todos os pedidos. O encaminhamento de pedidos baseia-se apenas em parâmetros da camada 7, independentemente do endereço IP de destino no pedido original gerado pela aplicação.
4 O Envoy seleciona um ponto final remoto em bom estado e faz um handshake TLS com o SNI obtido a partir da política TLS do cliente.
5 O Envoy encaminha o pedido para o ponto final remoto.

Não é apresentado no diagrama, mas, se as verificações de funcionamento estiverem configuradas, o Envoy verifica continuamente o funcionamento dos pontos finais remotos e encaminha pedidos apenas para pontos finais em bom estado.

Configure a conetividade híbrida

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

  • A conetividade híbrida entre a rede VPC e os serviços nas instalações ou uma nuvem pública de terceiros é estabelecida com o Cloud VPN ou o Cloud Interconnect.
  • As regras de firewall e as rotas da VPC estão configuradas corretamente para estabelecer acessibilidade bidirecional do Envoy aos pontos finais do serviço privado e, opcionalmente, a um servidor DNS no local.
  • Para um cenário de comutação por falha de HA regional bem-sucedido, o encaminhamento dinâmico global está ativado. Para mais detalhes, consulte o modo de planeamento de itinerários dinâmico.

Configure a configuração do Cloud DNS

Use os seguintes comandos para configurar uma zona privada do Cloud DNS para o domínio (FQDN) example.com que tem registos A a apontar para os pontos finais 10.0.0.100, 10.0.0.101, 10.0.0.102 e 10.0.0.103.

gcloud

  1. Crie uma zona privada gerida por DNS e anexe-a à rede predefinida:
    gcloud dns managed-zones create example-zone \
        --description=test \
        --dns-name=example.com \
        --networks=default \
        --visibility=private
  1. Adicione registos de DNS à zona privada:
    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

Configure o Cloud Service Mesh com um NEG FQDN da Internet

Nesta secção, configura a malha de serviços na nuvem com um FQDN de Internet NEG.

Crie o NEG, a verificação de funcionamento 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 ponto final FQDN:Port à 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 funcionamento global:
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. Crie um serviço de back-end global denominado on-prem-service-a e associe-lhe a verificação de funcionamento:
    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 denominado on-prem-service-a-neg como 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

Crie um mapa de regras de encaminhamento

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

Este mapa de URLs contém uma regra que encaminha todo o tráfego HTTP para on-prem-service-a.

gcloud

  1. Crie o mapa de URLs:
    gcloud compute url-maps create td-url-map \
        --default-service on-prem-service-a
  1. 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
  1. Crie a regra de encaminhamento global usando o endereço IP 0.0.0.0. Este é um endereço IP especial que faz com que o seu plano de dados ignore o endereço IP de destino e encaminhe os pedidos com base apenas nos parâmetros HTTP do pedido.
    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

Configure o TLS e o HTTPS não autenticados

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

Uma política TLS do cliente especifica a identidade do cliente e o mecanismo de autenticação quando um cliente envia pedidos de saída para um serviço específico. Uma política TLS do cliente é anexada a um recurso de serviço de back-end através do campo securitySettings.

gcloud

  1. Crie e importe a política de TLS do cliente; defina o SNI para o FQDN que 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 configurou uma verificação de funcionamento HTTP com o serviço de back-end na secção anterior, desassocie a verificação de funcionamento 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 funcionamento 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 criou anteriormente. Isto aplica o HTTPS não autenticado a todos os pedidos 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

Pode usar NEGs FQDN da Internet para encaminhar tráfego para qualquer serviço acessível através de FQDN, por exemplo, serviços externos e internos resolvidos por DNS ou serviços do Cloud Run.

Migre de um NEG IP:Port para um NEG FQDN:Port

NON_GCP_PRIVATE_IP_PORT O NEG requer que programe os pontos finais de serviço no NEG como pares IP:PORT estáticos, enquanto o INTERNET_FQDN_NEG permite que os pontos finais sejam resolvidos dinamicamente através do DNS. Pode migrar para o NEG da Internet configurando registos DNS para os seus pontos finais de serviço no local e configurando a malha de serviços na nuvem, conforme descrito nos passos seguintes:

  1. Configure os registos DNS para o seu FQDN.
  2. Crie um NEG de Internet com o FQDN.
  3. Crie um novo serviço de back-end com o NEG da Internet que criou no passo 2 como back-end. Associe a mesma verificação de estado de funcionamento que usou com o serviço de back-end do NEG de conetividade híbrida ao novo serviço de back-end. Verifique se os novos pontos finais remotos estão em bom estado.
  4. Atualize o mapa de regras de encaminhamento para fazer referência ao novo serviço de back-end, substituindo o back-end antigo que inclui o NEG de conetividade híbrida.
  5. Se quiser evitar o tempo de inatividade durante a migração em direto numa implementação de produção, pode usar o tráfego baseado no peso. Inicialmente, configure o novo serviço de back-end para receber apenas uma pequena percentagem do tráfego, por exemplo, 5%. Use as instruções para configurar a divisão do tráfego.
    1. Verifique se os novos pontos finais remotos estão a publicar tráfego corretamente.
  6. Se estiver a usar a divisão de tráfego baseada no peso, configure o novo serviço de back-end para receber 100% do tráfego. Este passo esgota o serviço de back-end antigo.
  7. Depois de verificar que os novos back-ends estão a publicar tráfego sem problemas, elimine o serviço de back-end antigo.

Resolução de problemas

Para resolver problemas de implementação, siga as instruções nesta secção. Se os seus problemas não forem resolvidos com estas informações, consulte o artigo Resolução de problemas de implementações que usam o Envoy.

Um ponto final nas instalações não está a receber tráfego

Se um ponto final não estiver a receber tráfego, certifique-se de que está a passar nas verificações de estado e que as consultas DNS do cliente Envoy devolvem o respetivo endereço IP de forma consistente.

O Envoy usa o modo strict_dns para gerir as ligações. Faz o equilíbrio de carga do tráfego em todos os pontos finais resolvidos que estão em bom estado. A ordem pela qual os pontos finais são resolvidos não importa no modo strict_dns, mas o Envoy esgota o tráfego para qualquer ponto final que já não esteja presente na lista de endereços IP devolvidos.

O cabeçalho do anfitrião HTTP não corresponde ao FQDN quando o pedido 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 ponto final do seu serviço no local. Quer enviar tráfego para o domínio altostrat.com, que está configurado no seu GNE.

É possível que a aplicação no Compute Engine ou GKE defina o cabeçalho HTTP Host como example.com (Host: example.com), que é transmitido para o ponto final no local. Se estiver a usar HTTPS, o Envoy define o SNI como altostrat.com durante o handshake TLS. O Envoy obtém o SNI do recurso de política de TLS do cliente.

Se este conflito estiver a causar problemas no processamento ou no encaminhamento do pedido quando este atinge o ponto final no local, como solução alternativa, pode reescrever o cabeçalho Host para altostrat.com (Host: altostrat.com). Isto pode ser feito no Cloud Service Mesh através da reescrita de URLs ou no ponto final remoto, se tiver capacidade de reescrita de cabeçalhos.

Outra solução 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 devolve muitos erros 5xx

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

  • Verifique os registos do Envoy para distinguir se a resposta está a ser enviada pelo back-end (back-end no local) e qual o motivo do erro 5xx.
  • Certifique-se de que as consultas DNS são bem-sucedidas e que não existem erros SERVFAIL ou NXDOMAIN.
  • Certifique-se de que todos os pontos finais remotos estão a passar nas verificações de funcionamento.
  • Se as verificações de estado não estiverem configuradas, certifique-se de que todos os pontos finais estão acessíveis a partir do Envoy. Verifique as regras e as rotas da firewall no lado do Google Cloud , bem como no lado no local.

Não é possível aceder a serviços externos através da Internet pública a partir da malha de serviços

Pode enviar tráfego para serviços localizados na Internet pública através de back-ends de FQDN no Cloud Service Mesh. Primeiro, tem de estabelecer a conetividade à Internet entre os clientes do Envoy e o serviço externo. Se estiver a receber um erro 502 durante as ligações ao serviço externo, faça o seguinte:

  • Certifique-se de que tem as rotas corretas, especificamente a rota predefinida 0.0.0.0/0, e as regras de firewall configuradas.
  • Certifique-se de que as consultas DNS são bem-sucedidas e que não existem erros SERVFAIL ou NXDOMAIN.
  • Se o proxy Envoy estiver em execução numa VM do Compute Engine que não tenha um endereço IP externo ou num cluster privado do GKE, tem de configurar o Cloud NAT ou outro meio para estabelecer conetividade com a Internet de saída.

Se os erros persistirem ou se estiver a receber outros erros 5xx, verifique os registos do Envoy para restringir a origem dos erros.

Não é possível aceder aos serviços sem servidor a partir da malha de serviços

Pode enviar tráfego para serviços sem servidor (Cloud Run, funções do Cloud Run e App Engine) através de back-ends FQDN no Cloud Service Mesh. Se o proxy Envoy estiver em execução numa VM do Compute Engine que não tenha um endereço IP externo ou num cluster privado do GKE, tem de configurar o acesso privado à Google na sub-rede para poder aceder às APIs e aos serviços Google.

O que se segue?