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ínioexample.com
é exibido por três endpoints,10.0.0.100
,10.0.0.101
e10.0.0.102
. Existem rotas que garantem a conectividade os proxies Envoy para 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 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 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
- 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 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
- 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
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:
- 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 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.
- 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%. Usar
as instruções para configurar o tráfego
divisão.
- 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. Esta etapa drena o back-end antigo serviço.
- 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
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
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 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
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 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
- 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.