Configurar back-ends externos com grupos de endpoints de rede da Internet
Neste documento, mostramos como configurar back-ends externos para o Cloud Service Mesh usando grupos de endpoints de rede (NEGs, na sigla em inglês) da Internet, que exigem um nome de domínio totalmente qualificado. Este documento é destinado a usuários que têm um nível intermediário ou avançado de familiaridade com o seguinte:
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
Confira a visão geral do Cloud Service Mesh 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 Cloud Service Mesh, zonas do Cloud DNS e conectividade híbrida, estão anexados à rede de nuvem privada virtual (VPC) padrão.
- o serviço
example.com:443
está sendo executado na infraestrutura local. O domínioexample.com
é exibido por três endpoints,10.0.0.100
,10.0.0.101
e10.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:
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.
As etapas na legenda a seguir correspondem à numeração na diagrama.
Etapa | Descrição |
---|---|
0 | O Envoy recebe a configuração de back-end do FQDN da Cloud Service Mesh 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
- 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
- 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
- Crie o NEG da Internet.
gcloud compute network-endpoint-groups create on-prem-service-a-neg \ --global \ --network-endpoint-type INTERNET_FQDN_PORT
- 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
- Crie uma verificação de integridade global.
gcloud compute health-checks create http service-a-http-health-check \ --global
- 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
- 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
- Crie o mapa de URL:
gcloud compute url-maps create td-url-map \ --default-service on-prem-service-a
- 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
- 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
- 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
- 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
- Crie uma verificação de integridade
HTTPS
:
gcloud compute health-checks create https service-a-https-health-check \ --global
- 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 de 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
configurando registros DNS para os endpoints de serviço locais e configurando
a Cloud Service Mesh conforme descrito nas etapas a seguir:
- Configure registros DNS para o FQDN.
- Crie um novo NEG de Internet com o FQDN.
- 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 com o serviço de back-end do NEG de conectividade híbrida ao novo serviço de back-end. Verificar se os novos endpoints remotos estão íntegros.
- 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.
- 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.
- Verifique se os novos endpoints remotos estão exibindo o tráfego corretamente.
- 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.
- 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
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 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
enviar 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 vai 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 o conflito estiver causando problemas no processamento ou no roteamento da solicitação quando
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 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
ouNXDOMAIN
. - 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 back-ends de
FQDN 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
ouNXDOMAIN
. - 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, funções do Cloud Run e serviços do App Engine) usando back-ends FQDN no Cloud Service Mesh. 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 as APIs e serviços do Google.
A seguir
- Para saber mais sobre as políticas de TLS do cliente, consulte Cloud Service Mesh a segurança do serviço e a Central de segurança de rede API.