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 usando 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 para 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.
O que você vai aprender
- Como criar um balanceador de carga HTTP(S) interno com um back-end NEG híbrido
- Como estabelecer um produtor (anexo de serviço) e um consumidor (regra de encaminhamento) do Private Service Connect
O que é necessário
- Rede híbrida estabelecida, por exemplo, 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 estar 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 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 de 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:
Divulgações de rota personalizadas
As sub-redes abaixo exigem divulgações personalizadas do Cloud Router para a rede local, garantindo que as regras do 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 |
2. Antes de começar
Atualizar o projeto para oferecer suporte ao codelab
Este codelab usa $variables para ajudar na implementação da configuração do 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 conferir 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 que estão na mesma região e na mesma rede VPC, eles vão compartilhar a mesma sub-rede somente proxy para balanceamento de carga.
- Um cliente estabelece uma conexão com o endereço IP e a porta da regra de encaminhamento do balanceador de carga.
- 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.
- 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 o mapa de URL do balanceador de carga.
Quer sua rede esteja no modo automático ou seja personalizada, é necessário criar sub-redes somente proxy. 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).
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 (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 ZONE que minimize a distância geográfica entre o Google Cloud e o ambiente local ou de outra nuvem. Por exemplo, se você estiver hospedando um serviço em um ambiente local em Frankfurt, na Alemanha, será possível especificar a zona europe-west3-a do Google Cloud ao criar o NEG.
Além disso, se você estiver usando o Cloud Interconnect, a ZONE usada para criar o NEG precisa estar na mesma região em que o anexo do Cloud Interconnect foi configurado.
Para conferir 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 aproveitando 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. Em TAXA, insira a TAXA máxima que o back-end precisa 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 as solicitações recebidas para o 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 de destino HTTP
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, acesse Serviços de rede → Balanceamento de carga → Balanceadores de carga. O NEG 1 está "verde", indicando que a verificação de integridade foi concluída com sucesso no serviço local.
A seleção de ‘on-premise-svc-url-map' gera o endereço IP do front-end e identifica o serviço de back-end.
5. Conferir as rotas aprendidas no local
Navegue até Rede VPC → Rotas. Observe 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, a próxima configuração será o anexo do serviç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 da VM que você quer que sejam acessíveis 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 balanceamento de carga. Tente novamente se houver um tempo limite.
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
Execute um curl que valida a conectividade com o serviço local. Depois que a saída for validada, saia da VM e volte ao prompt do Cloud Shell. Substitua 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 próximas etapas, vamos criar o anexo de serviço. Depois de ser pareado com um endpoint do consumidor, o acesso ao serviço local é alcançado sem a necessidade de peering da VPC.
Criar o anexo do serviço
No Cloud Shell, crie o anexo do 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 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 do 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 anexo de serviço recém-estabelecido.
A seleção de Service-1 fornece mais detalhes, incluindo o URI do anexo de serviço usado pelo consumidor para estabelecer uma conexão de serviço privada. Anote o URI, porque ele será usado em uma etapa posterior.
Detalhes do anexo do 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 serviço particular foi bem-sucedida acessando Serviços de rede → Private Service Connect → Endpoints conectados. Observe 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 bem-sucedida acessando Serviços de rede → Conexão de serviço particular → Serviço publicado. A conexão do serviço publicado 1 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 acesso perfeito ao produtor de qualquer host na VPC.
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 do produtor usando a VM
Na VPC dos consumidores, 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 da VM que você quer que sejam acessíveis 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 no consumer-vm usando o IAP no Cloud Shell para validar a conectividade com o serviço local executando um curl no FQDN do dns service1.codelab.net. Tente novamente se houver um tempo limite.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
Execute um curl que valida a conectividade com o serviço local. Depois de validar, 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 do proxy 172.16.0.0/23.
13. Limpeza do produtor
Excluir componentes do produtor
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. Limpeza do 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 que aponta para um serviço local. Você aprendeu a criar um endpoint do consumidor na VPC do consumidor que permitia a conectividade ao serviço local.
Qual é a próxima etapa?
Confira alguns destes codelabs:
- Como usar o Private Service 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 on-prem por rede híbrida 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