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, el uso del intercambio de tráfico entre VPCs conlleva muchas complejidades de enrutamiento, como el intercambio de tráfico entre VPCs no transitivo, el gran consumo de direcciones IP y la sobreexposición de 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 a través de un solo extremo que un consumidor aprovisiona en una VPC de cargas de trabajo. Esto elimina muchos de los problemas que enfrentan los usuarios con el intercambio de tráfico entre VPCs. Si bien se están creando muchos servicios nuevos con PSC, aún existen muchos servicios que se ofrecen como servicios de intercambio de tráfico entre VPCs.
Google Cloud se complace en presentar una ruta de migración para los servicios que creaste a través del intercambio de tráfico entre VPC para que se trasladen a una arquitectura basada en PSC. Con este método de migración, la dirección IP del servicio del 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 para conocer los pasos técnicos necesarios para realizar esta migración.
NOTA: Esta ruta de migración solo es para los servicios en los que el productor y el consumidor existen dentro de la misma organización de Google Cloud. En el caso de los servicios de Google Cloud o de terceros que usen el intercambio de tráfico de VPC, se aprovechará un método de migración similar, pero se personalizará para el servicio en sí. Comunícate con las partes correspondientes para consultar sobre la ruta de migración de estos tipos de servicios.
Qué aprenderás
- Cómo configurar un servicio basado en el intercambio de tráfico entre VPCs
- Cómo configurar un servicio basado en PSC
- Usa la API de Internal-Ranges para realizar la migración de subredes a través del intercambio de tráfico entre VPC y lograr una migración del intercambio de tráfico entre VPC al servicio de PSC.
- Cuándo debe ocurrir el tiempo de inactividad para la migración del servicio
- Pasos para limpiar la migración
Requisitos
- Proyecto de Google Cloud con permisos de propietario
2. Topología del codelab
Para simplificar, este codelab centraliza todos los recursos en un solo proyecto. En el codelab, se indicará qué acciones se deben realizar del lado del productor y qué acciones se deben realizar del lado del consumidor en caso de que los productores y los consumidores estén en proyectos diferentes.
Este codelab tendrá 4 estados.
El estado 1 es el estado de intercambio de tráfico entre VPC. Habrá dos VPC, consumer-vpc y producer-vpc, que se intercambiarán tráfico entre sí. Producer-vpc tendrá un servicio de Apache simple expuesto a través de un balanceador de cargas de red de transferencia interno. Consumer-vpc tendrá una sola VM de consumidor para fines de prueba.
El estado 2 es el estado de la prueba del 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 verificar que nuestro servicio de PSC funcione según lo esperado.
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 de VPC para que se use 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 del PSC. Limpiarás el extremo de PSC de prueba y borrarás 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 la red de VPC del productor (actividad del productor)
Red de VPC
Desde Cloud Shell
gcloud compute networks create producer-vpc \
--subnet-mode=custom
Crear 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 un Cloud Router y una puerta de enlace de Cloud NAT del productor
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 una política de firewall de red del productor y reglas de firewall
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 cumpla con lo siguiente:
- Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
- Permite el tráfico de entrada desde el 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 que permitan las verificaciones de estado del balanceador de cargas en el servicio, así como el tráfico de red de 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 ejecute un servidor web Apache que se agregará a un grupo de instancias no administrado con un balanceador de cargas de red de transferencia 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 red de transferencia 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. Crea la 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 una política de firewall de red del consumidor y reglas de firewall
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. Crea un par 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 se estableció el intercambio de tráfico, consulta la lista de rutas en consumer-vpc. Deberías ver 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. Crear zona del DNS (actividad del consumidor)
Crearemos una zona privada de Cloud DNS para llamar al servicio del productor a través del DNS en lugar de una dirección IP privada para mostrar un ejemplo más realista.
Agregaremos un registro A al servicio de ejemplo de dominio.com que apunta a ejemplo.servicio.com a la dirección IP de la regla de reenvío del balanceador de cargas de red de transferencia que creamos anteriormente. La dirección IP de esa 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 del productor a través del intercambio de tráfico entre VPC (actividad del consumidor)
En este punto, se creó la arquitectura del estado 1.
Crea una VM de cliente de consumidor
Desde Cloud Shell
gcloud compute instances create consumer-client \ --zone=$zone \ --subnet=consumer-vm-subnet \ --no-address
Probar la conectividad
Desde Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Desde la VM del cliente de consumidor
curl service.example.com
Resultado esperado
I am a Producer Service.
Desde la VM del cliente de consumidor
exit
11. Prepara el servicio para Private Service Connect (actividad del productor)
Ahora que terminamos todos los pasos de configuración inicial, comenzaremos a preparar el servicio con VPC interconectada para la migración a Private Service Connect. En esta sección, realizaremos cambios en producer-vpc configurando el servicio para que se exponga a través de un adjunto de servicio. Deberemos crear una subred nueva y una regla de reenvío nueva dentro de esa subred para poder migrar la subred existente a la VPC del consumidor y mantener intacta la dirección IP existente del servicio.
Crea la subred en la que se alojará la nueva IP de la regla de reenvío del balanceador de cargas.
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 anteriormente.
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
La subred psc-nat-subnet se asociará con el adjunto de servicio de PSC para la traducción de direcciones de red. Para los 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 la subred 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 de psc-nat-subnet. Cuando se accede al servicio a través de PSC, la subred 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 su URI 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 "test" al servicio del productor y realiza pruebas (actividad del consumidor)
La arquitectura ahora está en el estado 2.
En este punto, el servicio del productor existente expuesto a través del intercambio de tráfico entre VPC sigue activo y funciona 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 VPC Peering 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 se muestra 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
Del cliente consumidor
curl 10.0.1.3
Resultado esperado
I am a Producer Service.
Del cliente consumidor
exit
13. Migra la subred de la regla de reenvío del productor existente
Si realizas estos pasos, se iniciará una interrupción del servicio de productor basado en el intercambio de tráfico de VPC en vivo. Ahora migraremos la subred de la regla de reenvío de producer-vpc a consumer-vpc con la API de rangos internos. Esto bloqueará la subred para que no se use durante el período intermedio en el que borramos la subred en la VPC del productor y la designamos solo para fines de migración para su creación en la VPC del consumidor.
La API de rangos internos requiere que reserves la subred de la regla de reenvío de intercambio de tráfico entre VPCs existente (producer-fr-subnet, 192.168.0.0/28) y designes un nombre de subred de destino en la VPC del consumidor (consumer-psc-subnet). En unos pasos, crearemos una subred nueva en consumer-vpc con este nombre.
Reserva la subred 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
Ejecuta 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
Migra la subred a la VPC del consumidor creando una subred nueva con el rango interno que creamos antes. El nombre de esta subred debe ser el mismo que usamos anteriormente (consumer-psc-subnet). El propósito específico de PEER_MIGRATION indica que la subred está reservada para la migración de subredes entre VPCs con intercambio de tráfico. Con esta marca de propósito, la 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 Producer sigue inactivo. La subred que acabamos de crear sigue bloqueada y solo se puede usar para 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 a través de la interconexión 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 de vinculación de servicio que anotaste antes y que también se usó para crear el extremo de PSC "test".
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 del Estado 3.
Desde Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Desde la VM del cliente de consumidor
curl service.example.com
Resultado esperado
I am a Producer Service.
Desde la VM del cliente de consumidor
exit
En este punto, la interrupción finalizó y el servicio volvió a estar disponible. Ten en cuenta que no tuvimos que realizar ningún cambio en el DNS existente. No es necesario realizar cambios en el cliente del lado del consumidor. Las aplicaciones pueden reanudar las operaciones en el servicio migrado.
16. Limpieza de la migración
Para finalizar la migración, debemos realizar algunos pasos de limpieza. Debemos borrar y desbloquear recursos.
Desbloquea la subred del rango interno
Esto 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 pares 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"
Consumer-Activity
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 logró la arquitectura del Estado 4 (el estado final).
Vuelve a probar la conectividad del extremo de PSC para asegurarte de que no se observen efectos adversos por la limpieza de la migración.
Desde Cloud Shell
gcloud compute ssh \
--zone "$zone" "consumer-client" \
--tunnel-through-iap \
--project $projectid
Desde la VM del cliente de consumidor
curl service.example.com
Resultado esperado
I am a Producer Service.
Desde la VM del cliente de consumidor
exit
Operación exitosa
18. Pasos para la 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 el intercambio de tráfico entre VPCs
- Cómo configurar un servicio basado en PSC
- Usa la API de Internal-Ranges para realizar la migración de subredes a través del intercambio de tráfico entre VPC y lograr una migración del intercambio de tráfico entre VPC al servicio de PSC.
- Cuándo debe ocurrir el tiempo de inactividad para la migración del servicio
- Pasos para limpiar la migración