1. Introducción
El intercambio de tráfico entre VPC es un método común para que los productores ofrezcan el consumo de servicios a sus usuarios. Sin embargo, con el uso del intercambio de tráfico de VPC surgen muchas complejidades de enrutamiento, como el intercambio de tráfico de VPC no transitivo, el gran consumo de direcciones IP y la sobreexposición de los recursos en una VPC con intercambio de tráfico.
Private Service Connect (PSC) es un método de conectividad que permite a los productores exponer un servicio en un solo extremo que un consumidor aprovisiona en una VPC de carga de trabajo. Esto evita muchos problemas que los usuarios enfrentan con el intercambio de tráfico entre VPC. Si bien se crean muchos servicios nuevos con PSC, aún existen muchos servicios como servicios de intercambio de tráfico entre VPC.
Google Cloud se complace en presentar una ruta de migración para servicios que creaste a través del intercambio de tráfico entre VPC para migrar a una arquitectura basada en PSC. Con este método de migración, la dirección IP del servicio de productor que se expone a través del intercambio de tráfico entre VPC se conserva en la arquitectura basada en PSC, por lo que se requieren cambios mínimos para el consumidor. Sigue este codelab a fin de aprender los pasos técnicos para realizar esta migración.
NOTA: Esta ruta de migración es solo para servicios en los que el productor y el consumidor existen dentro de la misma organización de Google Cloud. Para cualquier servicio de Google Cloud o servicio de terceros que use intercambio de tráfico entre VPC, aprovecharán un método de migración similar, pero se personalizará para el servicio en sí. Comunícate con las partes adecuadas para solicitar información sobre la ruta de migración para estos tipos de servicios.
Qué aprenderás
- Cómo configurar un servicio basado en intercambio de tráfico entre VPC
- Cómo configurar un servicio basado en PSC
- Uso de la API de Internal-Ranges para realizar una migración de subred mediante el intercambio de tráfico entre VPC para lograr una migración del intercambio de tráfico entre VPC al servicio de PSC.
- Comprender cuándo debe ocurrir el tiempo de inactividad para la migración del servicio
- Pasos de limpieza de la migración
Requisitos
- Proyecto de Google Cloud con permisos de propietario
2. Topología de codelabs
Para simplificar, este codelab centraliza todos los recursos en un solo proyecto. En el codelab, se señalarán las acciones que deben realizarse en el lado del productor y las del consumidor en caso de que ambos estén en proyectos diferentes.
Este codelab tendrá 4 estados.
El estado 1 es el estado del intercambio de tráfico entre redes de VPC. Habrá dos VPC, consumer-vpc y producer-vpc, que intercambiarán tráfico en conjunto. Producer-vpc tendrá un servicio Apache simple expuesto a través de un balanceador de cargas de transferencia de red interno. Consumer-vpc tendrá una sola consumer-vm para realizar pruebas.
El estado 2 es el estado de la prueba de PSC. Crearemos una nueva regla de reenvío y la usaremos para asociarla con nuestro adjunto de servicio. Luego, crearemos un extremo de PSC de prueba en consumer-vpc para comprobar que nuestro servicio de PSC funcione según lo previsto.
El estado 3 es el estado de migración. Reservaremos el rango de subred en producer-vpc en el que se implementó el servicio basado en el intercambio de tráfico entre VPC para utilizar en consumer-vpc. Luego, crearemos un nuevo extremo de PSC con la misma dirección IP que la regla de reenvío preexistente en producer-vpc.
El estado 4 es el estado final de PSC. Limpiaremos el extremo de PSC de prueba y borraremos el intercambio de tráfico de VPC entre consumer-vpc y producer-vpc.
3. Configuración y requisitos
Configuración del entorno de autoaprendizaje
- Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.
- El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
- El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como
PROJECT_ID
). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto. - Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.
- A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.
Inicia Cloud Shell
Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.
En Google Cloud Console, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha:
El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:
Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Todo tu trabajo en este codelab se puede hacer en un navegador. No es necesario que instales nada.
4. Antes de comenzar
Habilita las APIs
En Cloud Shell, asegúrate de que tu proyecto esté configurado y configura las variables.
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
Habilita todos los servicios necesarios
gcloud services enable compute.googleapis.com gcloud services enable networkconnectivity.googleapis.com gcloud services enable dns.googleapis.com
5. Crea una red de VPC del productor (actividad de Producer)
Red de VPC
Desde Cloud Shell
gcloud compute networks create producer-vpc \ --subnet-mode=custom
Crea subredes
Desde 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 Cloud Router y Cloud NAT de Producer
Desde 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 reglas de firewall y una política de firewall de red del productor
Desde 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 IAP se conecte a tus instancias de VM, crea una regla de firewall que haga lo siguiente:
- Se aplica a todas las instancias de VM a las que deseas que sean accesibles mediante IAP.
- Permite el tráfico de entrada del rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.
Desde 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
También crearemos dos reglas más para permitir las verificaciones de estado del balanceador de cargas en el servicio y el tráfico de red desde las VMs que se conectarán desde consumer-vpc.
Desde 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. Configuración del servicio de productor (actividad del productor)
Crearemos un servicio de productor con una sola VM que ejecuta un servidor web Apache que se agregará a un grupo de instancias no administrado con un balanceador de cargas de transferencia de red interno regional.
Crea la VM y el grupo de instancias no administrado
Desde 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'
Desde 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 el balanceador de cargas de transferencia de red interno regional
Desde 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. Crear red de VPC del consumidor (actividad del consumidor)
Red de VPC
Desde Cloud Shell
gcloud compute networks create consumer-vpc \ --subnet-mode=custom
Crear subred
Desde Cloud Shell
gcloud compute networks subnets create consumer-vm-subnet \ --network=consumer-vpc \ --range=10.0.1.0/28 \ --region=$region
Crea reglas de firewall y una política de firewall de red del consumidor
Crearemos otra política de firewall de red para consumer-vpc.
Desde 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. Crear intercambio de tráfico de VPC
Actividad del productor
Desde Cloud Shell
gcloud compute networks peerings create producer-vpc-peering \ --network=producer-vpc \ --peer-project=$projectid \ --peer-network=consumer-vpc
Actividad del consumidor
Desde Cloud Shell
gcloud compute networks peerings create consumer-vpc-peering \ --network=consumer-vpc \ --peer-project=$projectid \ --peer-network=producer-vpc
Para confirmar que el intercambio de tráfico se haya establecido, verifica la lista de rutas en consumer-vpc. Deberías ver las rutas para consumer-vpc y producer-vpc.
Actividad del consumidor
Desde Cloud Shell
gcloud compute routes list --filter="network=consumer-vpc"
Resultado esperado
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 una zona del DNS (actividad del consumidor)
Crearemos una zona privada de Cloud DNS para llamar al servicio del productor a través de DNS en lugar de hacerlo a través de una dirección IP privada para mostrar un ejemplo más realista.
Agregaremos un registro A al dominio example.com que dirija a service.example.com a la dirección IP de regla de reenvío del balanceador de cargas de transferencia de red que creamos anteriormente. La dirección IP de la regla de reenvío es 192.168.0.2.
Desde 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. Prueba el servicio de productor sobre el intercambio de tráfico de VPC (actividad del consumidor)
En este punto, ya se creó la arquitectura State 1.
Crea una VM de consumidor-cliente
Desde Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Prueba la conectividad
Desde Cloud Shell
gcloud compute ssh \ --zone "$zone" "consumer-client" \ --tunnel-through-iap \ --project $projectid
Desde una VM de consumidor-cliente
curl service.example.com
Resultado esperado
I am a Producer Service.
Desde una VM de consumidor-cliente
exit
11. Prepara el servicio para Private Service Connect (Actividad de Producer)
Ahora que terminamos todos los pasos iniciales de configuración, comenzaremos a preparar el servicio con intercambio de tráfico de VPC para la migración a Private Service Connect. En esta sección, realizaremos cambios en producer-vpc. Para ello, configuraremos el servicio que se debe exponer a través de un adjunto de servicio. Tendremos que crear una subred y una regla de reenvío nuevas dentro de esa subred para poder migrar la subred existente a consumer-vpc y mantener intacta la dirección IP existente del servicio.
Crea la subred en la que se alojará la IP de la regla de reenvío del balanceador de cargas nuevo.
Desde Cloud Shell
gcloud compute networks subnets create producer-psc-fr-subnet \ --network=producer-vpc \ --range=10.0.2.64/28 \ --region=$region
Crea la dirección IP interna de la regla de reenvío del balanceador de cargas.
Desde Cloud Shell
gcloud compute addresses create producer-psc-ip \ --region $region \ --subnet producer-psc-fr-subnet \ --addresses 10.0.2.66
Crea la nueva regla de reenvío del balanceador de cargas. Esta regla está configurada para usar el mismo servicio de backend y las mismas verificaciones de estado que configuramos antes.
Desde 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
psc-nat-subnet se asociará con el adjunto de servicio de PSC para la traducción de direcciones de red. Para casos de uso de producción, esta subred debe tener el tamaño adecuado para admitir la cantidad de extremos adjuntos. Consulta la documentación sobre el tamaño de subredes de NAT de PSC para obtener más información.
Desde 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
Debemos agregar una regla de firewall adicional a la política de firewall de red para permitir el tráfico desde psc-nat-subnet. Cuando se accede al servicio a través de PSC, psc-nat-subnet es donde se originará el tráfico.
Desde 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 el adjunto de servicio y anota el URI del adjunto de servicio para configurar el extremo de PSC en la siguiente sección.
Desde 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
Desde Cloud Shell
gcloud compute service-attachments describe producer-sa --region=$region
Resultado de muestra
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. Conecta el extremo de PSC del consumidor “de prueba” al servicio y la prueba del productor (actividad del consumidor)
La arquitectura ahora está en State 2.
En este punto, el servicio del productor existente expuesto a través del intercambio de tráfico entre VPC sigue activo y funcionando correctamente en una situación de producción. Crearemos un extremo de PSC de “prueba” para asegurarnos de que el adjunto de servicio expuesto funcione correctamente antes de iniciar un período de interrupción para migrar la subred actual de intercambio de tráfico entre VPC a la VPC del consumidor. Nuestra conectividad de estado final será un extremo de PSC con la misma dirección IP que la regla de reenvío actual para el servicio basado en el intercambio de tráfico entre VPC.
Crear extremo de PSC
Desde Cloud Shell
gcloud compute addresses create test-psc-endpoint-ip \ --region=$region \ --subnet=consumer-vm-subnet \ --addresses 10.0.1.3
El servicio de destino que aparece a continuación será el URI del adjunto de servicio que anotaste en el último paso.
Desde 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
Prueba el extremo de PSC “test”
Desde Cloud Shell
gcloud compute ssh \ --zone "$zone" "consumer-client" \ --tunnel-through-iap \ --project $projectid
De consumidor-cliente
curl 10.0.1.3
Resultado esperado
I am a Producer Service.
De consumidor-cliente
exit
13. Migra la subred de reglas de reenvío del productor existente
Estos pasos iniciarán una interrupción en el servicio productor basado en el intercambio de tráfico entre VPC en vivo. Ahora, migraremos la subred de la regla de reenvío de producer-vpc a consumer-vpc con la API de Internal Ranges. Esto bloqueará el uso de la subred en el período temporal en el que borramos la subred en producer-vpc y la designará solo con fines de migración para la creación en consumer-vpc.
La API de rango interno requiere que reserves la subred existente de la regla de reenvío de intercambio de tráfico de VPC (producer-fr-subnet, 192.168.0.0/28) y que designes un nombre de subred de destino en consumer-vpc (consumer-psc-subnet). Crearemos una nueva subred en consumer-vpc con este nombre en unos pocos pasos.
Reserva producer-fr-subnet para la migración
Actividad del productor
Desde 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
Ejecutamos una descripción en el rango interno que creamos para ver el estado de la subred.
Actividad del productor
Desde Cloud Shell
gcloud network-connectivity internal-ranges describe producer-peering-internal-range
Resultado de muestra
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
Borra la regla de reenvío y la subred basadas en el intercambio de tráfico entre VPC
Actividad del productor
Desde 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
Migra la subred
Para migrar la subred a consumer-vpc, crea una subred nueva con el rango interno que creamos anteriormente. El nombre de esta subred debe ser el mismo que segmentamos antes (consumer-psc-subnet). El propósito específico de PEER_MIGRATION indica que la subred está reservada para la migración de subredes entre VPC con intercambio de tráfico. Con esta marca de propósito, esta subred solo puede contener direcciones IP estáticas reservadas y extremos de PSC.
Actividad del consumidor
Desde 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 el extremo de PSC de estado final (actividad del consumidor)
En este punto, el servicio de Productor sigue inactivo. La subred que acabamos de crear sigue bloqueada y solo se puede usar con el propósito específico de la migración. Para probar esto, intenta crear una VM en esta subred. La creación de la VM fallará.
Desde Cloud Shell
gcloud compute instances create test-consumer-vm \ --zone=$zone \ --subnet=consumer-psc-subnet \ --no-address
Resultado esperado
ERROR: (gcloud.compute.instances.create) Could not fetch resource: - Subnetwork must have purpose=PRIVATE.
Solo podemos usar esta subred para crear un extremo de PSC. Ten en cuenta que la dirección IP que creamos usa la misma IP que la regla de reenvío que usó nuestro servicio de productor en el intercambio de tráfico de VPC.
Desde Cloud Shell
gcloud compute addresses create psc-endpoint-ip \ --region=$region \ --subnet=consumer-psc-subnet \ --addresses 192.168.0.2
Una vez más, debes usar el mismo URI del adjunto de servicio que anotaste antes y que también se usó para crear el extremo de PSC “de prueba”.
Desde 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. Prueba el extremo de PSC de estado final (actividad del consumidor)
En este punto, te encuentras en la arquitectura State 3.
Desde Cloud Shell
gcloud compute ssh \ --zone "$zone" "consumer-client" \ --tunnel-through-iap \ --project $projectid
Desde una VM de consumidor-cliente
curl service.example.com
Resultado esperado
I am a Producer Service.
Desde una VM de consumidor-cliente
exit
En este punto, la interrupción finalizó y el servicio está funcionando de nuevo. Ten en cuenta que no tuvimos que hacer ningún cambio en el DNS existente. No es necesario realizar cambios en los clientes del consumidor. Las aplicaciones solo pueden reanudar las operaciones en el servicio migrado.
16. Limpieza de la migración
Para finalizar la migración, hay que seguir algunos pasos de limpieza. Debemos borrar y desbloquear recursos.
Desbloquea la subred de Internal Range
Esta acción desbloqueará la subred migrada para que su propósito se pueda cambiar de “PEER_MIGRATION” a “PRIVATE”.
Actividad del productor
Desde Cloud Shell
gcloud network-connectivity internal-ranges delete producer-peering-internal-range
Actividad del consumidor
Desde Cloud Shell
gcloud compute networks subnets update consumer-psc-subnet \ --region=$region \ --purpose=PRIVATE gcloud compute networks subnets describe consumer-psc-subnet --region=$region
Resultado de muestra
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
Borra los intercambios de tráfico de VPC
Actividad del productor
Desde Cloud Shell
gcloud compute networks peerings delete producer-vpc-peering \ --network=producer-vpc
Actividad del consumidor
Desde Cloud Shell
gcloud compute networks peerings delete consumer-vpc-peering \ --network=consumer-vpc
Borra el extremo de PSC “test”
Actividad del consumidor
Desde Cloud Shell
gcloud compute forwarding-rules delete test-psc-endpoint --region=$region gcloud compute addresses delete test-psc-endpoint-ip --region=$region
17. Prueba final después de la limpieza de la migración (actividad del consumidor)
En este punto, se alcanzó la arquitectura State 4 (el estado final).
Vuelve a probar la conectividad del extremo de PSC para asegurarte de que no se observen efectos adversos a partir de la limpieza de la migración.
Desde Cloud Shell
gcloud compute ssh \ --zone "$zone" "consumer-client" \ --tunnel-through-iap \ --project $projectid
Desde una VM de consumidor-cliente
curl service.example.com
Resultado esperado
I am a Producer Service.
Desde una VM de consumidor-cliente
exit
Operación exitosa
18. Pasos de limpieza
Desde 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. ¡Felicitaciones!
Felicitaciones por completar el codelab.
Temas abordados
- Cómo configurar un servicio basado en intercambio de tráfico entre VPC
- Cómo configurar un servicio basado en PSC
- Uso de la API de Internal-Ranges para realizar una migración de subred mediante el intercambio de tráfico entre VPC para lograr una migración del intercambio de tráfico entre VPC al servicio de PSC.
- Comprender cuándo debe ocurrir el tiempo de inactividad para la migración del servicio
- Pasos de limpieza de la migración