Conectar-se a serviços locais por uma rede híbrida usando o Private Service Connect e o NEG híbrido com balanceador de carga HTTP(s) interno

1. Introdução

O Cloud Load Balancing é compatível com o tráfego de balanceamento de carga para endpoints que se estendem além do Google Cloud, como data centers locais e outras nuvens públicas que podem ser acessadas utilizando a conectividade híbrida.

Uma estratégia híbrida é uma solução pragmática para você se adaptar às demandas do mercado em constante mudança e modernizar gradualmente os aplicativos. Essa pode ser uma implantação híbrida temporária para permitir a migração para uma solução moderna baseada na nuvem ou uma instalação permanente da infraestrutura de TI da sua organização.

A configuração do balanceamento de carga híbrido também permite trazer os benefícios dos recursos de rede do Cloud Load Balancing para serviços em execução na infraestrutura atual fora do Google Cloud.

Se você quiser disponibilizar o serviço híbrido em outras redes VPC, use o Private Service Connect para publicar o serviço. Ao colocar um anexo de serviço na frente do balanceador de carga HTTP(S) regional interno,é possível permitir que clientes em outras redes VPC alcancem os serviços híbridos executados no local ou em outros ambientes de nuvem.

O que você vai criar

Neste codelab, você vai criar um balanceador de carga HTTP(S) interno com conectividade híbrida a um serviço local usando um grupo de endpoints de rede. A VPC do consumidor poderá se comunicar com o serviço local usando as portas 80. A porta 443 não está no escopo do codelab.

Observação:o codelab oferece etapas de configuração e validação com base na topologia ilustrada. Modifique o procedimento conforme necessário para atender aos requisitos da sua organização. As permissões do IAM não estão no escopo do codelab.

O que você vai aprender

• Como criar um balanceador de carga HTTP(S) interno com um back-end de NEG híbrido
• Como estabelecer um produtor (anexo de serviço) e um consumidor (regra de encaminhamento) do Private Service Connect

Observação:este codelab é focado em uma implementação de balanceador de carga HTTP(S) interno com PSC. A configuração de rede híbrida não está documentada, mas há documentação e capturas de tela de suporte.

O que é necessário

• Redes híbridas estabelecidas, como VPN de alta disponibilidade, Interconnect e SW-WAN
• Projeto do Google Cloud

Estabelecer conectividade híbrida

O Google Cloud e os ambientes locais ou em nuvem precisam ser conectados por uma conectividade híbrida usando anexos da VLAN do Cloud Interconnect ou túneis do Cloud VPN com o Cloud Router. Recomendamos que você use uma conexão de alta disponibilidade.

Um Cloud Router ativado com roteamento dinâmico global aprende sobre o endpoint específico pelo BGP e o programa na sua rede VPC do Google Cloud. O roteamento dinâmico regional não é compatível. Rotas estáticas também não são compatíveis.

A rede VPC do Google Cloud usada para configurar o Cloud Interconnect ou o Cloud VPN é a mesma rede usada para configurar a implantação do balanceamento de carga híbrido. Verifique se os intervalos de CIDR da sub-rede da rede VPC não entram em conflito com os intervalos CIDR remotos. Quando os endereços IP se sobrepõem, as rotas de sub-rede são priorizadas em relação à conectividade remota.

Para instruções, consulte:

• Documentação do Cloud VPN
• Documentação do Cloud Interconnect

Divulgações de rota personalizadas

As sub-redes abaixo exigem divulgações personalizadas do Cloud Router para a rede local, garantindo que as regras de firewall local sejam atualizadas.

Sub-rede	Descrição
172.16.0.0/23	Sub-rede de proxy usada para se comunicar diretamente com o serviço local.
130.211.0.0/22, 35.191.0.0/16	Verificação de integridade do Google Cloud

2. Antes de começar

Atualizar o projeto para oferecer suporte ao codelab

Este codelab usa $variáveis para ajudar na implementação da configuração da gcloud no Cloud Shell.

No Cloud Shell, faça o seguinte:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Configuração do produtor

Criar a VPC do produtor

No Cloud Shell, faça o seguinte:

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Criar as sub-redes do produtor

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

Reservar um endereço IP para o balanceador de carga interno

No Cloud Shell, faça o seguinte. O uso de SHARED_VIP não é compatível com o Private Service Connect. Use GCE_ENDPOINT.

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

Use o comando compute addresses describe para ver o endereço IP alocado.

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

Criar as sub-redes de proxy regionais

A alocação de proxy está no nível da VPC, não no nível do balanceador de carga. Crie uma sub-rede somente proxy em cada região de uma rede virtual (VPC) em que você usa balanceadores de carga baseados em Envoy. Se você implantar vários balanceadores de carga na mesma região e rede VPC, eles vão compartilhar a mesma sub-rede somente proxy para balanceamento de carga.

1. Um cliente estabelece uma conexão com o endereço IP e a porta da regra de encaminhamento do balanceador de carga.
2. Cada proxy detecta o endereço IP e a porta especificados pela regra de encaminhamento do balanceador de carga correspondente. Um dos proxies recebe e encerra a conexão de rede do cliente.
3. O proxy estabelece uma conexão com o endpoint ou a VM de back-end adequados em um NEG, conforme determinado pelos serviços de back-end e mapa de URL do balanceador de carga.

É necessário criar sub-redes somente proxy, mesmo que sua rede esteja no modo automático ou seja personalizada. Uma sub-rede somente proxy precisa fornecer 64 ou mais endereços IP. Isso corresponde a um comprimento de prefixo de /26 ou mais curto. O tamanho de sub-rede recomendado é /23 (512 endereços somente proxy).

Observação:a sub-rede somente proxy exige um anúncio BGP do cliente para o ambiente local, portanto, roteável para sua rede local. O acesso ao serviço é possível pela sub-rede de proxy fornecida.

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Criar as sub-redes NAT do Private Service Connect

Crie uma ou mais sub-redes dedicadas para usar com o Private Service Connect. Se você estiver usando o console do Google Cloud para publicar um serviço, poderá criar as sub-redes durante esse procedimento. Crie a sub-rede na mesma região do balanceador de carga do serviço. Não é possível converter uma sub-rede regular em uma sub-rede do Private Service Connect.

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Criar as regras de firewall do produtor

Configure regras de firewall para permitir o tráfego entre os endpoints do Private Service Connect e o anexo de serviço. No codelab, criamos uma regra de firewall de entrada que permite que a sub-rede NAT 100.100.10.0/24 acesse o anexo de serviço do Private Service Connect (balanceador de carga interno).

No Cloud Shell, faça o seguinte:

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

No Cloud Shell, crie a regra fw-allow-health-check para permitir que as verificações de integridade do Google Cloud alcancem o serviço local (serviço de back-end) na porta TCP 80.

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

Crie uma regra de permissão de entrada de firewall para a sub-rede somente proxy para permitir que o balanceador de carga se comunique com instâncias de back-end na porta TCP 80

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Configurar o NEG de conectividade híbrida

Ao criar o NEG,use uma ZONA que minimize a distância geográfica entre o Google Cloud e seu ambiente local ou de outra nuvem. Por exemplo, se você estiver hospedando um serviço em um ambiente local em Frankfurt, na Alemanha, poderá especificar a zona europe-west3-a do Google Cloud ao criar o NEG.

Além disso, se você estiver usando o Cloud Interconnect, a ZONA usada para criar o NEG precisa estar na mesma região em que o anexo de interconexão do Cloud Interconnect foi configurado.

Para ver as regiões e zonas disponíveis, consulte a documentação do Compute Engine: regiões e zonas disponíveis.

No Cloud Shell, crie um NEG de conectividade híbrida usando o comando gcloud compute network-endpoint-groups create.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

No Cloud Shell, adicione o endpoint IP:Porta local ao NEG híbrido.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Configurar o balanceador de carga

Nas etapas a seguir, você vai configurar o balanceador de carga (regra de encaminhamento) e associá-lo ao grupo de endpoints de rede.

No Cloud Shell, crie a verificação de integridade regional transmitida ao serviço local.

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

No Cloud Shell, crie o serviço de back-end para o NEG híbrido que usa o back-end local.

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

No Cloud Shell, adicione o back-end NEG híbrido ao serviço de back-end. Para TAXA, insira a TAXA máxima que o back-end deve processar.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

No Cloud Shell, crie o mapa de URL para encaminhar solicitações recebidas ao serviço de back-end.

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

Criar o proxy HTTP de destino

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-map \
    --url-map-region=us-central1 \
    --region=us-central1

Crie uma regra de encaminhamento para encaminhar as solicitações recebidas para o proxy. Não use a sub-rede somente proxy para criar a regra de encaminhamento.

 gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --target-http-proxy-region=us-central1

4. Validar o balanceador de carga

No console do Cloud, navegue até Serviços de rede → Balanceamento de carga → Balanceadores de carga. Observação: o NEG 1 está "verde", indicando uma verificação de integridade bem-sucedida para o serviço local.

Selecionar ‘on-premise-svc-url-map' gera o endereço IP de front-end e identifica o serviço de back-end.

5. Conferir as rotas aprendidas no ambiente local

Acesse Rede VPC → Rotas. Observação: a sub-rede de serviço local aprendida 192.168.1.0/27

6. Validar a conectividade com o serviço local

Na VPC dos produtores, vamos criar uma VM para testar a conectividade com o serviço local. Depois, o anexo de serviço será a próxima configuração.

No Cloud Shell, crie a instância de teste na VPC do produtor.

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

Para permitir que o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o encaminhamento de TCP.

No Cloud Shell, crie a instância de teste na VPC do produtor.

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Faça login em test-box-us-central1 usando o IAP no Cloud Shell para validar a conectividade com o serviço local executando um curl no endereço IP do balanceador de carga. Tente de novo se houver um tempo limite.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Execute um curl para validar a conectividade com o serviço local. Depois de validado, saia da VM e volte ao prompt do Cloud Shell. Substitua o endereço IP do balanceador de carga interno com base na saída identificada na etapa 4.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

7. Criar o anexo do serviço do Private Service Connect

Nas etapas a seguir, vamos criar o anexo de serviço. Depois de pareado com um endpoint do consumidor, o acesso ao serviço local é feito sem a necessidade de peering de VPC.

Criar o anexo de serviço

No Cloud Shell, crie o anexo de serviço.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

Opcional:se você estiver usando uma VPC compartilhada, crie o anexo de serviço no projeto de serviço.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

Validar o anexo de serviço TCP

gcloud compute service-attachments describe service-1 --region us-central1

Opcional: navegue até Serviços de rede → Private Service Connect para conferir o serviço anexado recém-estabelecido.

Ao selecionar Service-1, você tem mais detalhes, incluindo o URI do anexo de serviço usado pelo consumidor para estabelecer uma conexão de serviço particular. Anote o URI, porque ele será usado em uma etapa posterior.

Detalhes do anexo de serviço:projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. Configuração do consumidor

Criar a VPC do consumidor

No Cloud Shell, faça o seguinte:

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Criar as sub-redes do consumidor

No Cloud Shell, crie a sub-rede do GCE.

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

No Cloud Shell, crie a sub-rede do endpoint do consumidor.

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Criar o endpoint do consumidor (regra de encaminhamento)

No Cloud Shell, crie o endereço IP estático que será usado como um endpoint do consumidor.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Vamos usar o URI do anexo de serviço gerado anteriormente para criar o endpoint do consumidor.

No Cloud Shell, crie o endpoint do consumidor.

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. Validar o Private Service Connect do consumidor: VPC do consumidor

Na VPC do consumidor, verifique se a conexão do Private Service Connect foi estabelecida navegando até Serviços de rede → Private Service Connect → Endpoints conectados. Anote a conexão psc-consumer-1 estabelecida e o endereço IP correspondente que criamos anteriormente.

Ao selecionar psc-consumer-1, os detalhes são fornecidos, incluindo o URI do anexo de serviço.

10. Validar o Private Service Connect do consumidor: VPC do produtor

Na VPC do produtor, verifique se a conexão de serviço particular foi criada navegando até Serviços de rede → Private Service Connect → Serviço publicado. Observe que a conexão do serviço-1 publicado agora indica uma regra de encaminhamento (endpoint de conexão).

11. Criar uma zona de DNS particular e um registro A

Crie a zona de DNS particular mapeada para o endpoint de conexão do PSC, permitindo o acesso contínuo ao produtor de qualquer host na VPC.

Observação:o acesso a um endpoint do consumidor por peering de VPC não é compatível.

No Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. Validar o acesso do consumidor ao serviço dos produtores usando a VM

Na VPC do consumidor, vamos criar uma VM para testar a conectividade com o serviço local acessando o endpoint do consumidor service1.codelabs.net.

No Cloud Shell, crie a instância de teste na VPC do consumidor.

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

Para permitir que o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o encaminhamento de TCP.

No Cloud Shell, crie a instância de teste na VPC do consumidor.

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Faça login na consumer-vm usando o IAP no Cloud Shell para validar a conectividade com o serviço local executando um curl no FQDN DNS service1.codelab.net. Tente de novo se houver um tempo limite.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

Execute um curl para validar a conectividade com o serviço local. Depois de validado, saia da VM e volte ao prompt do Cloud Shell.

No Cloud Shell, execute um curl

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Confira abaixo um exemplo de captura do serviço local. O endereço IP de origem 172.16.0.13 é do intervalo de sub-rede de proxy 172.16.0.0/23.

13. Limpeza do produtor

Excluir componentes do Producer

No Cloud Shell, exclua as instâncias de teste na VPC do produtor.

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. Liberar espaço de contas de consumidor

Excluir componentes do consumidor

No Cloud Shell, exclua as instâncias de teste na VPC do consumidor.

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet 

15. Parabéns

Parabéns! Você configurou e validou o Private Service Connect com um balanceador de carga HTTP(S) interno.

Você criou a infraestrutura do produtor e adicionou um anexo de serviço na VPC do produtor apontando para um serviço local. Você aprendeu a criar um endpoint do consumidor na VPC do consumidor que permitia a conectividade com o serviço local.

Qual é a próxima etapa?

Confira alguns destes codelabs:

• Como usar o Private Service Connect para publicar e consumir serviços com o GKE
• Como usar o Private Service Connect para publicar e consumir serviços
• Conectar-se a serviços no local pela rede híbrida de computadores usando o Private Service Connect e um balanceador de carga do proxy TCP interno

Leituras e vídeos complementares

• Visão geral do Private Service Connect
• O que é o Private Service Connect?
• Tipos de balanceadores de carga compatíveis

Documentos de referência

• Visão geral do balanceador de carga HTTP(S) interno
• Visão geral das verificações de integridade
• Como publicar um serviço usando o Private Service Connect