1. Introdução
O peering de VPC é um método comum para produtores oferecerem consumo de serviço aos usuários. No entanto, o uso do peering de VPC traz muitas complexidades de roteamento, como peering de VPC não transitivo, alto consumo de endereços IP e superexposição de recursos em uma VPC com peering.
O Private Service Connect (PSC) é um método de conectividade que permite aos produtores expor um serviço em um único endpoint provisionado por um consumidor em uma VPC de carga de trabalho. Isso elimina vários problemas que os usuários enfrentam com o peering de VPC. Embora muitos serviços novos estejam sendo criados com o PSC, ainda há muitos que existem como serviços de peering de VPC.
O Google Cloud tem o prazer de apresentar um caminho de migração dos serviços que você criou com o peering de VPC para migrar para uma arquitetura baseada em PSC. Ao usar esse método de migração, o endereço IP do serviço do produtor que é exposto por meio do peering de VPC é preservado na arquitetura baseada em PSC para que haja alterações mínimas necessárias para o consumidor. Acompanhe este codelab para conhecer as etapas técnicas para realizar essa migração.
OBSERVAÇÃO: esse caminho de migração é apenas para serviços em que o produtor e o consumidor estão na mesma organização do Google Cloud. Todos os serviços do Google Cloud ou de terceiros que usam peering de VPC usarão um método de migração semelhante, mas serão personalizados para o próprio serviço. Entre em contato com as partes relevantes para saber mais sobre o caminho de migração desses tipos de serviços.
O que você vai aprender
- Como configurar um serviço baseado em peering de VPC
- Como configurar um serviço baseado em PSC
- Como usar a API Internal-Ranges para migrar a sub-rede pelo peering de VPC e conseguir uma migração de serviço de peering de VPC para PSC.
- Entender quando o tempo de inatividade precisa ocorrer para a migração do serviço
- Etapas de limpeza da migração
O que é necessário
- Projeto do Google Cloud com permissões de proprietário
2. Topologia do codelab
Para simplificar, este codelab centraliza todos os recursos em um único projeto. Você verá no codelab quais ações precisam ser realizadas no lado do produtor e quais ações precisam ser realizadas pelo lado do consumidor caso produtores e consumidores estejam em projetos diferentes.
Este codelab terá quatro estados.
O estado 1 é o estado do peering de VPC. Haverá duas VPCs, consumer-vpc e producer-vpc, que serão pareadas em peering. O Producer-vpc terá um serviço Apache simples exposto por meio de um balanceador de carga de passagem de rede interno. Consumer-vpc terá uma única consumer-vm para fins de teste.
O estado 2 é o estado de teste de PSC. Criaremos uma nova regra de encaminhamento e a usaremos para associar ao nosso anexo de serviço. Em seguida, criaremos um endpoint de teste do PSC em consumer-vpc para testar se nosso serviço de PSC está funcionando conforme o esperado.
O estado 3 é o estado da migração. Vamos reservar o intervalo de sub-redes em producer-vpc, onde o serviço baseado em peering de VPC foi implantado para ser usado em consumer-vpc. Em seguida, criaremos um novo endpoint do PSC com o mesmo endereço IP que a regra de encaminhamento pré-existente em producer-vpc.
O estado 4 é o estado final do PSC. Vamos limpar o endpoint de teste do PSC e excluir o peering de VPC entre consumer-vpc e producer-vpc.
3. Configuração e requisitos
Configuração de ambiente autoguiada
- Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.
- O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
- O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como
PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto. - Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.
- Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.
Inicie o Cloud Shell
Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.
No Console do Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:
O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:
Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.
4. Antes de começar
Ativar APIs
No Cloud Shell, verifique se o projeto está configurado e configure as variáveis.
gcloud auth login gcloud config list project gcloud config set project [YOUR-PROJECT-ID] export projectid=[YOUR-PROJECT-ID] export region=us-central1 export zone=$region-a echo $projectid echo $region echo $zone
Ative todos os serviços necessários
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. Criar rede VPC do produtor (atividade do produtor)
Rede VPC
No Cloud Shell
gcloud compute networks create producer-vpc \
--subnet-mode=custom
Criar sub-redes
No Cloud Shell
gcloud compute networks subnets create producer-service-subnet \
--network=producer-vpc \
--range=10.0.0.0/28 \
--region=$region
gcloud compute networks subnets create producer-fr-subnet \
--network=producer-vpc \
--range=192.168.0.0/28 \
--region=$region
Criar o Cloud Router e o Cloud NAT do produtor
No Cloud Shell
gcloud compute routers create $region-cr \
--network=producer-vpc \
--region=$region
gcloud compute routers nats create $region-nat \
--router=$region-cr \
--region=$region \
--nat-all-subnet-ip-ranges \
--auto-allocate-nat-external-ips
Criar política de firewall de rede do produtor e regras de firewall
No Cloud Shell
gcloud compute network-firewall-policies create producer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy producer-vpc-policy \
--network producer-vpc \
--name network-producer-vpc \
--global-firewall-policy
Para permitir que o IAP se conecte às instâncias de VM, crie uma regra de firewall que:
- Aplica-se a todas as instâncias de VM que você quer disponibilizar usando o IAP.
- Permite tráfego de entrada no intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para encaminhamento de TCP.
No Cloud Shell
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
Também criaremos mais duas regras que permitem verificações de integridade do balanceador de carga para o serviço e o tráfego de rede de VMs que se conectarão a partir de consumer-vpc.
No Cloud Shell
gcloud compute network-firewall-policies rules create 2000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "LB healthchecks" \
--direction INGRESS \
--src-ip-ranges 130.211.0.0/22,35.191.0.0/16 \
--layer4-configs tcp:80 \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 3000 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow access from consumer-vpc" \
--direction INGRESS \
--src-ip-ranges 10.0.1.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
6. Configuração do serviço do produtor (atividade do produtor)
Vamos criar um serviço de produtor com uma única VM executando um servidor da Web Apache. Ela será adicionada a um grupo de instâncias não gerenciadas com um balanceador de carga de passagem de rede interno regional.
Crie a VM e o grupo de instâncias não gerenciadas
No Cloud Shell
gcloud compute instances create producer-service-vm \
--network producer-vpc \
--subnet producer-service-subnet \
--zone $zone \
--no-address \
--metadata startup-script='#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
a2enmod ssl
sudo a2ensite default-ssl
echo "I am a Producer Service." | \
tee /var/www/html/index.html
systemctl restart apache2'
No Cloud Shell
gcloud compute instance-groups unmanaged create prod-uig \ --zone=$zone gcloud compute instance-groups unmanaged add-instances prod-uig \ --zone=$zone \ --instances=producer-service-vm
Crie o balanceador de carga de passagem da rede interna regional
No Cloud Shell
gcloud compute health-checks create http producer-hc \
--region=$region
gcloud compute backend-services create producer-bes \
--load-balancing-scheme=internal \
--protocol=tcp \
--region=$region \
--health-checks=producer-hc \
--health-checks-region=$region
gcloud compute backend-services add-backend producer-bes \
--region=$region \
--instance-group=prod-uig \
--instance-group-zone=$zone
gcloud compute addresses create producer-fr-ip\
--region $region \
--subnet producer-fr-subnet \
--addresses 192.168.0.2
gcloud compute forwarding-rules create producer-fr \
--region=$region \
--load-balancing-scheme=internal \
--network=producer-vpc \
--subnet=producer-fr-subnet \
--address=producer-fr-ip \
--ip-protocol=TCP \
--ports=80 \
--backend-service=producer-bes \
--backend-service-region=$region
7. Criar rede VPC do consumidor (atividade do consumidor)
Rede VPC
No Cloud Shell
gcloud compute networks create consumer-vpc \
--subnet-mode=custom
Criar sub-rede
No Cloud Shell
gcloud compute networks subnets create consumer-vm-subnet \
--network=consumer-vpc \
--range=10.0.1.0/28 \
--region=$region
Criar política de firewall de rede do consumidor e regras de firewall
Vamos criar outra política de firewall de rede para consumer-vpc.
No Cloud Shell
gcloud compute network-firewall-policies create consumer-vpc-policy --global
gcloud compute network-firewall-policies associations create \
--firewall-policy consumer-vpc-policy \
--network consumer-vpc \
--name network-consumer-vpc \
--global-firewall-policy
gcloud compute network-firewall-policies rules create 1000 \
--action ALLOW \
--firewall-policy consumer-vpc-policy \
--description "SSH with IAP" \
--direction INGRESS \
--src-ip-ranges 35.235.240.0/20 \
--layer4-configs tcp:22 \
--global-firewall-policy
8. Criar par de VPC
Atividade do produtor
No Cloud Shell
gcloud compute networks peerings create producer-vpc-peering \
--network=producer-vpc \
--peer-project=$projectid \
--peer-network=consumer-vpc
Atividade do consumidor
No Cloud Shell
gcloud compute networks peerings create consumer-vpc-peering \
--network=consumer-vpc \
--peer-project=$projectid \
--peer-network=producer-vpc
Para confirmar se o peering foi estabelecido, verifique a lista de rotas em "consumer-vpc". Você vai ver rotas para consumer-vpc e producer-vpc.
Atividade do consumidor
No Cloud Shell
gcloud compute routes list --filter="network=consumer-vpc"
Resposta esperada
NAME: default-route-49dda7094977e231 NETWORK: consumer-vpc DEST_RANGE: 0.0.0.0/0 NEXT_HOP: default-internet-gateway PRIORITY: 1000 NAME: default-route-r-10d65e16cc6278b2 NETWORK: consumer-vpc DEST_RANGE: 10.0.1.0/28 NEXT_HOP: consumer-vpc PRIORITY: 0 NAME: peering-route-496d0732b4f11cea NETWORK: consumer-vpc DEST_RANGE: 192.168.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0 NAME: peering-route-b4f9d3acc4c08d55 NETWORK: consumer-vpc DEST_RANGE: 10.0.0.0/28 NEXT_HOP: consumer-vpc-peering PRIORITY: 0
9. Criar zona DNS (atividade do consumidor)
Para mostrar um exemplo mais realista, criaremos uma zona particular do Cloud DNS para chamar o serviço do produtor pelo DNS em vez de usar um endereço IP particular.
Vamos adicionar um registro A ao domínio example.com, apontando service.example.com para o endereço IP da regra de encaminhamento do balanceador de carga de passagem de rede que criamos anteriormente. O endereço IP da regra de encaminhamento é 192.168.0.2.
No Cloud Shell
gcloud dns managed-zones create "producer-service" \ --dns-name=example.com \ --description="producer service dns" \ --visibility=private \ --networks=consumer-vpc gcloud dns record-sets transaction start \ --zone="producer-service" gcloud dns record-sets transaction add 192.168.0.2 \ --name=service.example.com \ --ttl=300 \ --type=A \ --zone="producer-service" gcloud dns record-sets transaction execute \ --zone="producer-service"
10. Serviço do produtor de teste sobre o peering VPC (atividade do consumidor)
A arquitetura do Estado 1 já está pronta.
Criar uma VM consumidor-cliente
No Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Testar conectividade
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Da VM consumidor-cliente
curl service.example.com
Resposta esperada
I am a Producer Service.
Da VM consumidor-cliente
exit
11. Preparar serviço para o Private Service Connect (atividade do produtor)
Agora que concluímos todas as etapas iniciais de configuração, vamos começar a preparar o serviço com peering de VPC para migração ao Private Service Connect. Nesta seção, vamos fazer mudanças em producer-vpc, configurando o serviço para ser exposto por um anexo de serviço. Vamos precisar criar uma nova sub-rede e uma nova regra de encaminhamento dentro dela para migrar a sub-rede atual para o consumer-vpc e manter o endereço IP atual do serviço intacto.
Crie a sub-rede em que o novo IP da regra de encaminhamento do balanceador de carga será hospedado.
No Cloud Shell
gcloud compute networks subnets create producer-psc-fr-subnet \
--network=producer-vpc \
--range=10.0.2.64/28 \
--region=$region
Crie o endereço IP interno da regra de encaminhamento do balanceador de carga.
No Cloud Shell
gcloud compute addresses create producer-psc-ip \ --region $region \ --subnet producer-psc-fr-subnet \ --addresses 10.0.2.66
Crie a nova regra de encaminhamento do balanceador de carga. Esta regra está configurada para usar o mesmo serviço de back-end e verificações de integridade que configuramos anteriormente.
No Cloud Shell
gcloud compute forwarding-rules create psc-service-fr \ --region=$region \ --load-balancing-scheme=internal \ --network=producer-vpc \ --subnet=producer-psc-fr-subnet \ --address=producer-psc-ip \ --ip-protocol=TCP \ --ports=80 \ --backend-service=producer-bes \ --backend-service-region=$region
A psc-nat-subnet será associada ao anexo de serviço do PSC para fins de conversão de endereços de rede. Para casos de uso de produção, essa sub-rede precisa ser dimensionada adequadamente para suportar o número de endpoints anexados. Consulte a documentação sobre o dimensionamento de sub-redes NAT PSC para mais informações.
No Cloud Shell
gcloud compute networks subnets create psc-nat-subnet \
--network=producer-vpc \
--range=10.100.100.0/28 \
--region=$region \
--purpose=PRIVATE_SERVICE_CONNECT
Precisamos adicionar outra regra à Política de Firewall de Rede para permitir o tráfego vindo do psc-nat-subnet. Ao acessar o serviço por PSC, o psc-nat-subnet é o local de origem do tráfego.
No Cloud Shell
gcloud compute network-firewall-policies rules create 2001 \
--action ALLOW \
--firewall-policy producer-vpc-policy \
--description "allow PSC NAT subnet" \
--direction INGRESS \
--src-ip-ranges 10.100.100.0/28 \
--layer4-configs tcp:80 \
--global-firewall-policy
Crie o anexo de serviço e anote o URI do anexo de serviço para configurar o endpoint do PSC na próxima seção.
No Cloud Shell
gcloud compute service-attachments create producer-sa \
--region=$region \
--producer-forwarding-rule=psc-service-fr \
--connection-preference=ACCEPT_MANUAL \
--consumer-accept-list=$projectid=5 \
--nat-subnets=psc-nat-subnet
No Cloud Shell
gcloud compute service-attachments describe producer-sa --region=$region
Exemplo de saída
connectionPreference: ACCEPT_MANUAL consumerAcceptLists: - connectionLimit: 5 projectIdOrNum: $projectid creationTimestamp: '2025-04-24T11:23:09.886-07:00' description: '' enableProxyProtocol: false fingerprint: xxx id: 'xxx' kind: compute#serviceAttachment name: producer-sa natSubnets: - https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/psc-nat-subnet pscServiceAttachmentId: high: 'xxx' low: 'xxx' reconcileConnections: false region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/serviceAttachments/producer-sa targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/forwardingRules/psc-service-fr
12. Conectar o endpoint PSC do consumidor "test" ao serviço e teste do produtor (atividade do consumidor)
A arquitetura agora está no Estado 2.
Neste ponto, o serviço do produtor atual exposto por peering de VPC ainda está ativo e funcionando corretamente no cenário de produção. Vamos criar um endpoint PSC de "teste" para garantir que o anexo de serviço exposto esteja funcionando corretamente antes de iniciarmos um período de interrupção para migrar a sub-rede de peering de VPC atual para a VPC de consumidor. Nossa conectividade de estado final será um endpoint PSC com o mesmo endereço IP da regra de encaminhamento atual para o serviço baseado em peering de VPC.
Criar endpoint do PSC
No Cloud Shell
gcloud compute addresses create test-psc-endpoint-ip \
--region=$region \
--subnet=consumer-vm-subnet \
--addresses 10.0.1.3
O serviço de destino abaixo será o URI do anexo de serviço que você anotou na última etapa.
No Cloud Shell
gcloud compute forwarding-rules create test-psc-endpoint \ --region=$region \ --network=consumer-vpc \ --address=test-psc-endpoint-ip \ --target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
Testar o endpoint do PSC de "teste"
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
De consumidor-cliente
curl 10.0.1.3
Resposta esperada
I am a Producer Service.
De consumidor-cliente
exit
13. Migrar a sub-rede de regra de encaminhamento do produtor atual
A execução dessas etapas vai iniciar uma interrupção do serviço produtor baseado em peering de VPC ativo. Agora vamos migrar a sub-rede da regra de encaminhamento de producer-vpc para a consumer-vpc usando a API Internal Ranges. Isso vai impedir que a sub-rede seja usada no período provisório, quando a excluirmos em producer-vpc, e a designar apenas para fins de migração para criação em consumer-vpc.
A API de intervalo interno exige que você reserve a sub-rede da regra de encaminhamento de peering de VPC atual (producer-fr-subnet, 192.168.0.0/28) e defina um nome de sub-rede de destino em consumer-vpc (consumer-psc-subnet). Vamos criar uma nova sub-rede em "consumer-vpc" com esse nome em algumas etapas.
Reservar producer-fr-subnet para migração
Atividade do produtor
No Cloud Shell
gcloud network-connectivity internal-ranges create producer-peering-internal-range \
--ip-cidr-range=192.168.0.0/28 \
--network=producer-vpc \
--usage=FOR_MIGRATION \
--migration-source=projects/$projectid/regions/$region/subnetworks/producer-fr-subnet \
--migration-target=projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
Execute uma descrição no intervalo interno que criamos para visualizar o estado da sub-rede.
Atividade do produtor
No Cloud Shell
gcloud network-connectivity internal-ranges describe producer-peering-internal-range
Exemplo de saída
createTime: '2025-04-24T19:26:10.589343291Z' ipCidrRange: 192.168.0.0/28 migration: source: projects/$projectid/regions/$region/subnetworks/producer-fr-subnet target: projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet name: projects/$projectid/locations/global/internalRanges/producer-peering-internal-range network: https://www.googleapis.com/compute/v1/projects/$project/global/networks/producer-vpc peering: FOR_SELF updateTime: '2025-04-24T19:26:11.521960016Z' usage: FOR_MIGRATION
Excluir a regra de encaminhamento e a sub-rede com base em peering de VPC
Atividade do produtor
No Cloud Shell
gcloud compute forwarding-rules delete producer-fr --region=$region gcloud compute addresses delete producer-fr-ip --region=$region gcloud compute networks subnets delete producer-fr-subnet --region=$region
Migrar a sub-rede
Migre a sub-rede para consumer-vpc criando uma nova sub-rede usando o internal-range que criamos anteriormente. O nome desta sub-rede precisa ser o mesmo que segmentamos anteriormente (consumer-psc-subnet). A finalidade específica de PEER_MIGRATION indica que a sub-rede é reservada para a migração de sub-redes entre VPCs com peering. Com essa flag de finalidade, a sub-rede só pode conter endereços IP estáticos reservados e endpoints PSC.
Atividade do consumidor
No Cloud Shell
gcloud compute networks subnets create consumer-psc-subnet \ --purpose=PEER_MIGRATION \ --network=consumer-vpc \ --range=192.168.0.0/28 \ --region=$region
14. Criar o endpoint do PSC do estado final (atividade do consumidor)
Neste momento, o serviço Producer ainda está inativo. A sub-rede que acabamos de criar ainda está bloqueada e só pode ser usada para fins específicos de migração. É possível testar isso tentando criar uma VM nessa sub-rede. A criação da VM vai falhar.
No Cloud Shell
gcloud compute instances create test-consumer-vm \
--zone=$zone \
--subnet=consumer-psc-subnet \
--no-address
Resposta esperada
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Subnetwork must have purpose=PRIVATE.
Só podemos usar essa sub-rede para criar um endpoint PSC. O endereço IP que criamos usa o mesmo IP da regra de encaminhamento que nosso serviço do produtor usou no peering de VPC.
No Cloud Shell
gcloud compute addresses create psc-endpoint-ip \
--region=$region \
--subnet=consumer-psc-subnet \
--addresses 192.168.0.2
Mais uma vez, você precisa usar o mesmo URI do anexo de serviço que anotou anteriormente e que também foi usado para criar o endpoint do PSC de "teste".
No Cloud Shell
gcloud compute forwarding-rules create psc-endpoint \
--region=$region \
--network=consumer-vpc \
--address=psc-endpoint-ip \
--target-service-attachment=projects/$projectid/regions/$region/serviceAttachments/producer-sa
15. Testar o endpoint PSC do estado final (atividade do consumidor)
Neste ponto, você está na arquitetura do Estado 3.
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Da VM consumidor-cliente
curl service.example.com
Resposta esperada
I am a Producer Service.
Da VM consumidor-cliente
exit
A esta altura, a interrupção do serviço terminou e o serviço voltou a funcionar. Observe que não tivemos que fazer nenhuma alteração no DNS existente. Nenhuma mudança no lado do consumidor é necessária. Os aplicativos só podem retomar as operações no serviço migrado.
16. Limpeza da migração
Para finalizar a migração, precisamos realizar algumas etapas de limpeza. Precisamos excluir e desbloquear recursos.
Desbloquear a sub-rede do intervalo interno
Isso desbloqueia a sub-rede migrada, e a finalidade dela pode ser alterada de "PEER_MIGRATION" para "PRIVATE".
Atividade do produtor
No Cloud Shell
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
Atividade do consumidor
No Cloud Shell
gcloud compute networks subnets update consumer-psc-subnet \
--region=$region \
--purpose=PRIVATE
gcloud compute networks subnets describe consumer-psc-subnet --region=$region
Exemplo de saída
creationTimestamp: '2025-04-24T12:29:33.883-07:00' fingerprint: xxx gatewayAddress: 192.168.0.1 id: 'xxx' ipCidrRange: 192.168.0.0/28 kind: compute#subnetwork name: consumer-psc-subnet network: https://www.googleapis.com/compute/v1/projects/$projectid/global/networks/consumer-vpc privateIpGoogleAccess: false privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS purpose: PRIVATE region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/$region/subnetworks/consumer-psc-subnet
Excluir os peerings de VPC
Atividade do produtor
No Cloud Shell
gcloud compute networks peerings delete producer-vpc-peering \
--network=producer-vpc
Atividade do consumidor
No Cloud Shell
gcloud compute networks peerings delete consumer-vpc-peering \
--network=consumer-vpc
Excluir o endpoint do PSC de "teste"
Atividade do consumidor
No Cloud Shell
gcloud compute forwarding-rules delete test-psc-endpoint --region=$region gcloud compute addresses delete test-psc-endpoint-ip --region=$region
17. Teste final após a limpeza da migração (atividade do consumidor)
Neste ponto, a arquitetura do Estado 4 (o estado final) foi alcançada.
Teste a conectividade do endpoint do PSC novamente para garantir que nenhum efeito adverso seja observado na limpeza da migração.
No Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Da VM consumidor-cliente
curl service.example.com
Resposta esperada
I am a Producer Service.
Da VM consumidor-cliente
exit
SUCCESS!
18. Etapas de limpeza
No Cloud Shell
gcloud compute forwarding-rules delete psc-endpoint --region=$region -q gcloud compute addresses delete psc-endpoint-ip --region=$region -q gcloud compute instances delete consumer-client --zone=$zone --project=$projectid -q gcloud dns record-sets delete service.example.com --zone="producer-service" --type=A -q gcloud dns managed-zones delete "producer-service" -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy consumer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=consumer-vpc-policy --name=network-consumer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete consumer-vpc-policy --global -q gcloud compute networks subnets delete consumer-psc-subnet --region=$region -q gcloud compute networks subnets delete consumer-vm-subnet --region=$region -q gcloud compute networks delete consumer-vpc -q gcloud compute service-attachments delete producer-sa --region=$region -q gcloud compute forwarding-rules delete psc-service-fr --region=$region -q gcloud compute addresses delete producer-psc-ip --region=$region -q gcloud compute backend-services delete producer-bes --region=$region -q gcloud compute health-checks delete producer-hc --region=$region -q gcloud compute instance-groups unmanaged delete prod-uig --zone=$zone -q gcloud compute instances delete producer-service-vm --zone=$zone --project=$projectid -q gcloud compute network-firewall-policies rules delete 3000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy --name=network-producer-vpc --global-firewall-policy -q gcloud compute network-firewall-policies delete producer-vpc-policy --global -q gcloud compute routers nats delete $region-nat --router=$region-cr --region=$region -q gcloud compute routers delete $region-cr --region=$region -q gcloud compute networks subnets delete psc-nat-subnet --region=$region -q gcloud compute networks subnets delete producer-psc-fr-subnet --region=$region -q gcloud compute networks subnets delete producer-service-subnet --region=$region -q gcloud compute networks delete producer-vpc -q
19. Parabéns!
Parabéns por concluir o codelab.
O que vimos
- Como configurar um serviço baseado em peering de VPC
- Como configurar um serviço baseado em PSC
- Como usar a API Internal-Ranges para migrar a sub-rede pelo peering de VPC e conseguir uma migração de serviço de peering de VPC para PSC.
- Entender quando o tempo de inatividade precisa ocorrer para a migração do serviço
- Etapas de limpeza da migração