1. Introduzione
Il peering VPC è un metodo comune utilizzato dai producer per offrire il consumo di servizi ai propri utenti. Tuttavia, l'uso del peering VPC comporta molte complessità di routing come il peering VPC non transitorio, un ampio consumo di indirizzi IP e la sovraesposizione delle risorse in un VPC in peering.
Private Service Connect (PSC) è un metodo di connettività che consente ai producer di esporre un servizio su un singolo endpoint di cui un consumer esegue il provisioning nel VPC di un carico di lavoro. In questo modo si eliminano molti problemi riscontrati dagli utenti con il peering VPC. Anche se molti nuovi servizi vengono creati con PSC, ne esistono ancora molti come servizi di peering VPC.
Google Cloud è entusiasta di presentare un percorso di migrazione per i servizi che hai creato tramite il peering VPC per passare a un'architettura basata su PSC. Con questo metodo di migrazione, l'indirizzo IP del servizio producer esposto tramite peering VPC viene conservato nell'architettura basata su PSC, pertanto sono necessarie modifiche minime per il consumer. Segui questo codelab per conoscere i passaggi tecnici per eseguire questa migrazione.
NOTA: questo percorso di migrazione riguarda solo i servizi in cui il producer e il consumer risiedono all'interno della stessa organizzazione Google Cloud. Per tutti i servizi Google Cloud o di terze parti che utilizzano il peering VPC, sfrutteranno un metodo di migrazione simile, ma verrà personalizzato in base al servizio stesso. Contatta le parti appropriate per chiedere informazioni sul percorso di migrazione per questi tipi di servizi.
Cosa imparerai a fare
- Configurare un servizio basato su peering VPC
- Come configurare un servizio basato su PSC
- Utilizzo dell'API Internal-Ranges per eseguire la migrazione delle subnet su peering VPC per eseguire una migrazione del servizio dal peering VPC al servizio PSC.
- Capire quando si devono verificare tempi di inattività per la migrazione dei servizi
- Passaggi di pulizia della migrazione
Che cosa ti serve
- Progetto Google Cloud con autorizzazioni di proprietario
2. Topologia codelab
Per semplicità, questo codelab centralizza tutte le risorse in un unico progetto. Nel codelab verranno indicate quali azioni devono essere eseguite sul lato producer e quali azioni devono essere eseguite sul lato consumer nel caso in cui producer e consumer si trovino in progetti diversi.
Questo codelab avrà 4 stati.
Lo stato 1 è lo stato di peering VPC. Ci saranno due VPC, consumer-vpc e producer-vpc che saranno in peering insieme. Producer-vpc avrà un semplice servizio Apache esposto tramite un bilanciatore del carico Network Passthrough interno. Consumer-vpc avrà un'unica 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 al servizio. Creeremo quindi 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. Preserveremo l'intervallo di subnet in producer-vpc in cui è stato eseguito il deployment del servizio basato su peering VPC per l'utilizzo 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 di PSC. Ripuliremo l'endpoint PSC di test ed elimineremo il peering VPC tra consumer-vpc e producer-vpc.
3. Configurazione e requisiti
Configurazione dell'ambiente a tuo ritmo
- 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 al progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
- L'ID progetto è univoco per tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca; di solito non ti interessa quale sia. Nella maggior parte dei codelab, dovrai fare riferimento al tuo ID progetto (in genere identificato come
PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare il tuo e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimane invariato per tutta la durata del progetto. - Per tua informazione, esiste un terzo valore, un Numero progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.
- Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare le API/risorse Cloud. La partecipazione a questo codelab non ha costi, o quasi. Per arrestare le risorse ed evitare di incorrere in fatturazione al termine di questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud sono idonei al programma Prova senza costi di 300$.
Avvia Cloud Shell
Sebbene Google Cloud possa essere utilizzato 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:
Dovrebbe richiedere solo pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere qualcosa di simile a questo:
Questa macchina virtuale contiene tutti gli strumenti di sviluppo 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 di rete. Tutto il lavoro in questo codelab può essere svolto in un browser. Non devi installare nulla.
4. Prima di iniziare
Abilita API
All'interno di Cloud Shell, assicurati che il progetto sia impostato 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
Abilita tutti i servizi necessari
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. Creazione rete VPC del produttore (attività del produttore)
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 router Cloud del produttore e Cloud NAT
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 criterio firewall e regole firewall di rete del producer
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 applica a tutte le istanze VM a cui vuoi rendere accessibile tramite IAP.
- Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP 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, oltre a consentire 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à producer)
Verrà creato un servizio producer con una singola VM che esegue un server web Apache che verrà aggiunto a un gruppo di istanze non gestite che ha un bilanciatore del carico passthrough di rete interno regionale.
Crea la VM e il gruppo di istanze non gestite
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 passthrough di rete 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. Creazione rete VPC consumer (attività consumatore)
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 e regole firewall per il consumatore
Creeremo un altro criterio 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 di route nel consumer-vpc. Dovresti vedere le route sia per consumer-vpc che 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. Creazione zona DNS (attività consumer)
Creeremo una zona privata di Cloud DNS per chiamare il servizio producer tramite DNS anziché tramite un indirizzo IP privato per mostrare un esempio più realistico.
Aggiungeremo un record A al dominio example.com che rimanda a service.example.com all'indirizzo IP della regola di forwarding del bilanciatore del carico passthrough di rete 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. Servizio producer di test su peer VPC (attività consumer)
A questo punto, è stata creata l'architettura Stato 1.
Crea una VM consumer-client
Da Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Testa la connettività
Da Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Dalla VM consumer-client
curl service.example.com
Risultato previsto
I am a Producer Service.
Dalla VM consumer-client
exit
11. Prepara il servizio per Private Service Connect (attività producer)
Dopo aver completato tutti i passaggi di configurazione iniziali, iniziamo a preparare il servizio in peering VPC per la migrazione a Private Service Connect. In questa sezione apporteremo le modifiche a producer-vpc configurando il servizio da esporre tramite un collegamento al servizio. Dovremo creare una nuova subnet e una nuova regola di forwarding al suo interno in modo da poter migrare la subnet esistente alla consumer-vpc e mantenere intatto l'indirizzo IP esistente del servizio.
Crea la subnet in cui verrà ospitato l'IP della nuova 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 in modo da 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 traduzione degli indirizzi di rete. Per i casi d'uso di produzione, questa subnet deve essere dimensionata in modo appropriato per supportare il numero di endpoint collegati. Per ulteriori informazioni, consulta la documentazione relativa al 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'ulteriore regola firewall al criterio firewall di rete per consentire il traffico da psc-nat-subnet. Quando accedi al servizio tramite PSC, la subnet psc-nat-subnet è quella da cui verrà acquisito il 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 al servizio e prendi nota dell'URI del collegamento 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. Connetti l'endpoint PSC del consumatore "test" al servizio del produttore e testa (attività dei consumatori)
L'architettura ora è nello stato 2.
A questo punto, il servizio producer esistente esposto tramite peering VPC è ancora attivo e funziona correttamente in uno scenario di produzione. Creeremo un endpoint PSC "test" per garantire che il collegamento al servizio esposto funzioni correttamente prima di iniziare un periodo di interruzione per eseguire la migrazione dell'attuale subnet di peering VPC al VPC consumer. La nostra connettività dello stato finale sarà un endpoint PSC con lo stesso indirizzo IP dell'attuale regola di forwarding per il servizio basato su 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 consumatore-cliente
curl 10.0.1.3
Risultato previsto
I am a Producer Service.
Da consumatore-cliente
exit
13. Esegui la migrazione della subnet della regola di forwarding del producer esistente
L'esecuzione di questi passaggi avvierà un'interruzione per il servizio producer basato su peering VPC in tempo reale. Ora eseguiremo 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 verrà utilizzata nel periodo temporaneo quando la eliminiamo in producer-vpc e la designerà solo per scopi di migrazione per la creazione in consumer-vpc.
L'API Internal Range richiede la prenotazione della subnet esistente della regola di forwarding del peering VPC (producer-fr-subnet, 192.168.0.0/28) e designa un nome della subnet di destinazione in consumer-vpc (consumer-psc-subnet). In pochi passaggi creiamo una nuova subnet in consumer-vpc con questo nome.
Prenota 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 una descrizione dell'intervallo interno 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 subnet e la regola di forwarding basato 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
Eseguire la migrazione della subnet
Esegui la migrazione della subnet a 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 come target in precedenza (subnet consumer-psc-subnet). Lo scopo specifico di PEER_MIGRATION sottolinea che la subnet è riservata alla migrazione di subnet tra VPC in peering. Con questo flag "scopo", la 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. Creazione dell'endpoint PSC dello stato finale (attività del consumatore)
A questo punto, il servizio Producer è ancora inattivo. La subnet che abbiamo appena creato è ancora bloccata e può essere utilizzata solo per lo scopo specifico della migrazione. Puoi verificarlo tentando di creare una VM in questa subnet. La creazione della VM non riuscirà.
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 usare questa subnet solo per creare un endpoint PSC. Tieni presente che l'indirizzo IP che creiamo utilizza lo stesso IP della regola di forwarding che il nostro servizio producer utilizzava sul peer 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. Testare l'endpoint PSC dello stato finale (attività del consumatore)
A questo punto, ti trovi all'architettura State 3.
Da Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Dalla VM consumer-client
curl service.example.com
Risultato previsto
I am a Producer Service.
Dalla VM consumer-client
exit
A questo punto l'interruzione è terminata e il servizio è di nuovo attivo. Tieni presente che non abbiamo dovuto apportare modifiche al DNS esistente. Non è necessario apportare modifiche al client lato consumer. Le applicazioni possono semplicemente riprendere le operazioni nel servizio di cui è stata eseguita la migrazione.
16. Pulizia della migrazione
Per finalizzare la migrazione, sono necessari alcuni passaggi di pulizia. Dobbiamo eliminare e sbloccare le risorse.
Sblocca la subnet intervallo interno
Questa operazione sbloccherà la subnet migrata in modo che il suo scopo possa 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 peer 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 "di test"
Consumatore-attività
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à dell'utente)
A questo punto, è stata raggiunta l'architettura State 4 (lo stato finale).
Testa di nuovo la connettività dell'endpoint PSC per assicurarti che non vengano osservati effetti negativi dalla pulizia della migrazione.
Da Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Dalla VM consumer-client
curl service.example.com
Risultato previsto
I am a Producer Service.
Dalla VM consumer-client
exit
OPERAZIONE RIUSCITA.
18. Passaggi per la 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!
Complimenti per aver completato il codelab.
Argomenti trattati
- Configurare un servizio basato su peering VPC
- Come configurare un servizio basato su PSC
- Utilizzo dell'API Internal-Ranges per eseguire la migrazione delle subnet su peering VPC per eseguire una migrazione del servizio dal peering VPC al servizio PSC.
- Capire quando si devono verificare tempi di inattività per la migrazione dei servizi
- Passaggi di pulizia della migrazione