1. Introduzione
Il peering VPC è un metodo comune per i producer per offrire il consumo di servizi ai propri utenti. Tuttavia, l'utilizzo del peering VPC comporta molte complessità di routing, come il peering VPC non transitivo, un elevato consumo di indirizzi IP e una sovraesposizione delle risorse in un VPC sottoposto a peering.
Private Service Connect (PSC) è un metodo di connettività che consente ai producer di esporre un servizio su un singolo endpoint che un consumer esegue il provisioning in un VPC del workload. In questo modo si eliminano molti problemi che gli utenti riscontrano con il peering VPC. Sebbene molti nuovi servizi vengano creati con PSC, esistono ancora molti servizi come servizi di peering VPC.
Google Cloud è felice di presentare un percorso di migrazione per i servizi che hai creato tramite il peering VPC per passare a un'architettura basata su PSC. Utilizzando questo metodo di migrazione, l'indirizzo IP per il servizio producer esposto tramite il peering VPC viene mantenuto fino all'architettura basata su PSC, pertanto sono necessarie modifiche minime per il consumer. Segui questo codelab per scoprire i passaggi tecnici per eseguire la migrazione.
NOTA: questo percorso di migrazione è valido solo per i servizi in cui il produttore e il consumatore esistono all'interno della stessa organizzazione Google Cloud. Per tutti i servizi Google Cloud o di terze parti che utilizzano il peering VPC, verrà utilizzato un metodo di migrazione simile, ma personalizzato per il servizio stesso. Contatta le parti appropriate per informazioni sul percorso di migrazione per questi tipi di servizi.
Cosa imparerai a fare
- Come configurare un servizio basato sul peering VPC
- Come configurare un servizio basato su PSC
- Utilizzo dell'API Internal-Ranges per eseguire la migrazione delle subnet tramite il peering VPC per ottenere una migrazione del peering VPC al servizio PSC.
- Informazioni su quando è necessario il tempo di inattività per la migrazione del servizio
- Procedura per la pulizia della migrazione
Che cosa ti serve
- Progetto Google Cloud con autorizzazioni di proprietario
2. Topologia del codelab
Per semplicità, questo codelab centralizza tutte le risorse in un unico progetto. Nel codelab verranno indicate le azioni da eseguire lato produttore e lato consumatore nel caso in cui produttori e consumatori si trovino in progetti diversi.
Questo codelab avrà 4 stati.
Lo stato 1 è lo stato del peering VPC. Ci saranno due VPC, consumer-vpc e producer-vpc, che verranno sottoposti a peering. Producer-vpc avrà un semplice servizio Apache esposto tramite un bilanciatore del carico di rete passthrough interno. consumer-vpc avrà una sola consumer-vm a scopo di test.
Lo stato 2 è lo stato di test PSC. Creeremo una nuova regola di forwarding e la utilizzeremo per associarla al nostro collegamento del servizio. Successivamente, creeremo un endpoint PSC di test in consumer-vpc per verificare che il nostro servizio PSC funzioni come previsto.
Lo stato 3 è lo stato della migrazione. Riserviamo l'intervallo di subnet in producer-vpc in cui è stato eseguito il deployment del servizio basato sul peering VPC da utilizzare in consumer-vpc. Creeremo quindi un nuovo endpoint PSC con lo stesso indirizzo IP della regola di forwarding preesistente in producer-vpc.
Lo stato 4 è lo stato finale del PSC. Puliremo l'endpoint PSC di test ed elimineremo il peering VPC tra consumer-vpc e producer-vpc.
3. Configurazione e requisiti
Configurazione dell'ambiente autonomo
- Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.
- Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
- L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere identificato come
PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimane per tutta la durata del progetto. - Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
- Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. Completare questo codelab non costa molto, se non nulla. Per arrestare le risorse ed evitare addebiti oltre a quelli previsti in questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.
Avvia Cloud Shell
Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.
Nella console Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:
Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere un risultato simile a questo:
Questa macchina virtuale è caricata con tutti gli strumenti per sviluppatori di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Tutto il lavoro in questo codelab può essere svolto all'interno di un browser. Non devi installare nulla.
4. Prima di iniziare
Abilita API
In Cloud Shell, assicurati che il progetto sia configurato e configura le variabili.
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
Attiva tutti i servizi necessari
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. Crea rete VPC producer (attività del producer)
Rete VPC
Da Cloud Shell
gcloud compute networks create producer-vpc \
--subnet-mode=custom
Crea subnet
Da 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
Crea il router Cloud e Cloud NAT del produttore
Da 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
Crea la policy firewall di rete del produttore e le regole firewall
Da 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
Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:
- Si applichi a tutte le istanze VM a cui vuoi accedere tramite IAP.
- Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP che utilizzati da IAP per l'inoltro TCP.
Da 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
Creeremo anche altre due regole che consentono i controlli di integrità del bilanciatore del carico al servizio e il traffico di rete dalle VM che si connetteranno da consumer-vpc.
Da 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. Configurazione del servizio producer (attività del producer)
Creeremo un servizio di produzione con una singola VM che esegue un server web Apache che verrà aggiunto a un gruppo di istanze non gestito di cui è stato eseguito il provisioning con un bilanciatore del carico di rete passthrough interno regionale.
Crea la VM e il gruppo di istanze non gestito
Da 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'
Da 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
Crea il bilanciatore del carico di rete passthrough interno regionale
Da 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. Crea rete VPC consumer (attività consumer)
Rete VPC
Da Cloud Shell
gcloud compute networks create consumer-vpc \
--subnet-mode=custom
Crea subnet
Da Cloud Shell
gcloud compute networks subnets create consumer-vm-subnet \
--network=consumer-vpc \
--range=10.0.1.0/28 \
--region=$region
Crea criteri firewall di rete consumer e regole firewall
Creeremo un'altra policy firewall di rete per consumer-vpc.
Da 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. Crea peer VPC
Attività del produttore
Da Cloud Shell
gcloud compute networks peerings create producer-vpc-peering \
--network=producer-vpc \
--peer-project=$projectid \
--peer-network=consumer-vpc
Attività dei consumatori
Da Cloud Shell
gcloud compute networks peerings create consumer-vpc-peering \
--network=consumer-vpc \
--peer-project=$projectid \
--peer-network=producer-vpc
Verifica che il peering sia stabilito controllando l'elenco delle route in consumer-vpc. Dovresti visualizzare le route per consumer-vpc e producer-vpc.
Attività dei consumatori
Da Cloud Shell
gcloud compute routes list --filter="network=consumer-vpc"
Output previsto
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. Crea zona DNS (attività dei consumatori)
Per mostrare un esempio più realistico, creeremo una zona privata di Cloud DNS per chiamare il servizio producer tramite DNS anziché tramite un indirizzo IP privato.
Aggiungeremo un record A al servizio di puntamento del dominio example.com service.example.com all'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough che abbiamo creato in precedenza. L'indirizzo IP della regola di forwarding è 192.168.0.2.
Da 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. Testare il servizio producer tramite il peering VPC (attività consumer)
A questo punto, l'architettura dello stato 1 è stata creata.
Crea una VM consumer-client
Da Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Test di connettività
Da Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Dalla VM client consumer
curl service.example.com
Risultato previsto
I am a Producer Service.
Dalla VM client consumer
exit
11. Prepara il servizio per Private Service Connect (attività del producer)
Ora che abbiamo completato tutti i passaggi di configurazione iniziali, inizieremo a preparare il servizio con peering VPC per la migrazione a Private Service Connect. In questa sezione, apporteremo modifiche a producer-vpc configurando il servizio in modo che venga esposto tramite un collegamento del servizio. Dobbiamo creare una nuova subnet e una nuova regola di inoltro all'interno di questa subnet per poter eseguire la migrazione della subnet esistente al VPC consumer e mantenere intatto l'indirizzo IP esistente del servizio.
Crea la subnet in cui verrà ospitato il nuovo IP della regola di forwarding del bilanciatore del carico.
Da Cloud Shell
gcloud compute networks subnets create producer-psc-fr-subnet \
--network=producer-vpc \
--range=10.0.2.64/28 \
--region=$region
Crea l'indirizzo IP interno della regola di forwarding del bilanciatore del carico.
Da Cloud Shell
gcloud compute addresses create producer-psc-ip \ --region $region \ --subnet producer-psc-fr-subnet \ --addresses 10.0.2.66
Crea la nuova regola di forwarding del bilanciatore del carico. Questa regola è configurata per utilizzare lo stesso servizio di backend e gli stessi controlli di integrità che abbiamo configurato in precedenza.
Da 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
La subnet psc-nat-subnet verrà associata al collegamento del servizio PSC ai fini della Network Address Translation. Per i casi d'uso di produzione, le dimensioni di questa subnet devono essere adeguate per supportare il numero di endpoint collegati. Per ulteriori informazioni, consulta la documentazione sul dimensionamento della subnet NAT PSC.
Da 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
Dobbiamo aggiungere un'altra regola firewall alla policy firewall di rete per consentire ora il traffico dalla subnet psc-nat-subnet. Quando si accede al servizio tramite PSC, la subnet psc-nat è l'origine del traffico.
Da 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
Crea il collegamento del servizio e annota l'URI del collegamento del servizio per configurare l'endpoint PSC nella sezione successiva.
Da 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
Da Cloud Shell
gcloud compute service-attachments describe producer-sa --region=$region
Esempio di output
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. Collega l'endpoint PSC consumer "test" al servizio producer e testalo (attività del consumer)
L'architettura si trova ora nello stato 2.
A questo punto, il servizio producer esistente esposto tramite il peering VPC è ancora attivo e funziona correttamente in uno scenario di produzione. Creeremo un endpoint PSC "test" per assicurarci che il collegamento del servizio esposto funzioni correttamente prima di avviare un periodo di interruzione per eseguire la migrazione della subnet VPC peering corrente al VPC consumer. La connettività dello stato finale sarà un endpoint PSC con lo stesso indirizzo IP della regola di forwarding corrente per il servizio basato sul peering VPC.
Crea endpoint PSC
Da Cloud Shell
gcloud compute addresses create test-psc-endpoint-ip \
--region=$region \
--subnet=consumer-vm-subnet \
--addresses 10.0.1.3
Il servizio di destinazione riportato di seguito sarà l'URI del collegamento al servizio che hai annotato nell'ultimo passaggio.
Da 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
Testa l'endpoint PSC "test"
Da Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Da consumer-client
curl 10.0.1.3
Risultato previsto
I am a Producer Service.
Da consumer-client
exit
13. Esegui la migrazione della subnet della regola di inoltro del produttore esistente
L'esecuzione di questi passaggi avvierà un'interruzione del servizio di produzione basato sul peering VPC live. Ora eseguiamo la migrazione della subnet della regola di forwarding da producer-vpc a consumer-vpc utilizzando l'API Internal Ranges. In questo modo, la subnet non potrà essere utilizzata nel periodo di tempo intermedio tra l'eliminazione della subnet nel VPC del produttore e la sua designazione solo a scopo di migrazione per la creazione nel VPC del consumer.
L'API per l'intervallo interno richiede di riservare la subnet della regola di forwarding del peering VPC esistente (producer-fr-subnet, 192.168.0.0/28) e di designare un nome di subnet di destinazione in consumer-vpc (consumer-psc-subnet). Creiamo una nuova subnet in consumer-vpc con questo nome in pochi passaggi.
Riserva la subnet producer-fr per la migrazione
Attività del produttore
Da 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
Esegui un comando describe sull'intervallo interno che abbiamo creato per visualizzare lo stato della subnet.
Attività del produttore
Da Cloud Shell
gcloud network-connectivity internal-ranges describe producer-peering-internal-range
Esempio di output
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
Elimina la regola di forwarding e la subnet basate sul peering VPC
Attività del produttore
Da 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
Esegui la migrazione della subnet
Migra la subnet al consumer-vpc creando una nuova subnet utilizzando l'intervallo interno creato in precedenza. Il nome di questa subnet deve essere lo stesso che abbiamo scelto in precedenza (consumer-psc-subnet). Lo scopo specifico di PEER_MIGRATION indica che la subnet è riservata alla migrazione della subnet tra VPC con peering. Con questo flag di scopo, questa subnet può contenere solo indirizzi IP statici riservati ed endpoint PSC.
Attività dei consumatori
Da 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. Crea l'endpoint PSC dello stato finale (attività del consumer)
A questo punto, il servizio Producer non è ancora attivo. La subnet che abbiamo appena creato è ancora bloccata e può essere utilizzata solo per lo scopo specifico della migrazione. Puoi testare questa operazione tentando di creare una VM in questa subnet. La creazione della VM non andrà a buon fine.
Da Cloud Shell
gcloud compute instances create test-consumer-vm \
--zone=$zone \
--subnet=consumer-psc-subnet \
--no-address
Risultato previsto
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Subnetwork must have purpose=PRIVATE.
Possiamo utilizzare questa subnet solo per creare un endpoint PSC. Tieni presente che l'indirizzo IP che creiamo utilizza lo stesso IP della regola di forwarding utilizzata dal nostro servizio producer tramite il peering VPC.
Da Cloud Shell
gcloud compute addresses create psc-endpoint-ip \
--region=$region \
--subnet=consumer-psc-subnet \
--addresses 192.168.0.2
Ancora una volta, devi utilizzare lo stesso URI del collegamento al servizio che hai annotato in precedenza e che è stato utilizzato anche per creare l'endpoint PSC "test".
Da 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. Testa l'endpoint PSC dello stato finale (attività consumer)
A questo punto, ti trovi nell'architettura dello stato 3.
Da Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Dalla VM client consumer
curl service.example.com
Risultato previsto
I am a Producer Service.
Dalla VM client consumer
exit
A questo punto, l'interruzione è terminata e il servizio è di nuovo attivo. Tieni presente che non è stato necessario apportare modifiche al DNS esistente. Non è necessario apportare modifiche al client lato consumer. Le applicazioni possono riprendere le operazioni nel servizio di cui è stata eseguita la migrazione.
16. Pulizia della migrazione
Per finalizzare la migrazione, dobbiamo eseguire alcuni passaggi di pulizia. Dobbiamo eliminare e sbloccare le risorse.
Sblocca la subnet dell'intervallo interno
In questo modo, la subnet di cui è stata eseguita la migrazione verrà sbloccata e il suo scopo potrà essere modificato da "PEER_MIGRATION" a "PRIVATE".
Attività del produttore
Da Cloud Shell
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
Attività dei consumatori
Da Cloud Shell
gcloud compute networks subnets update consumer-psc-subnet \
--region=$region \
--purpose=PRIVATE
gcloud compute networks subnets describe consumer-psc-subnet --region=$region
Esempio di output
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
Elimina i peering VPC
Attività del produttore
Da Cloud Shell
gcloud compute networks peerings delete producer-vpc-peering \
--network=producer-vpc
Attività dei consumatori
Da Cloud Shell
gcloud compute networks peerings delete consumer-vpc-peering \
--network=consumer-vpc
Elimina l'endpoint PSC "test"
Consumer-Activity
Da Cloud Shell
gcloud compute forwarding-rules delete test-psc-endpoint --region=$region gcloud compute addresses delete test-psc-endpoint-ip --region=$region
17. Test finale dopo la pulizia della migrazione (attività dei consumatori)
A questo punto, è stata raggiunta l'architettura dello stato 4 (lo stato finale).
Verifica di nuovo la connettività dell'endpoint PSC per assicurarti che non siano stati osservati effetti negativi dalla pulizia della migrazione.
Da Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Dalla VM client consumer
curl service.example.com
Risultato previsto
I am a Producer Service.
Dalla VM client consumer
exit
OPERAZIONE RIUSCITA.
18. Procedura di pulizia
Da 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. Complimenti!
Congratulazioni per aver completato il codelab.
Argomenti trattati
- Come configurare un servizio basato sul peering VPC
- Come configurare un servizio basato su PSC
- Utilizzo dell'API Internal-Ranges per eseguire la migrazione delle subnet tramite il peering VPC per ottenere una migrazione del peering VPC al servizio PSC.
- Informazioni su quando è necessario il tempo di inattività per la migrazione del servizio
- Procedura per la pulizia della migrazione