Private Service Connect: Migración de intercambio de tráfico entre VPC a Private Service Connect

Acerca de este codelab
schedule74 minutos
subjectÚltima actualización: 28 de abril de 2025
account_circleEscrito por Lorin Price

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.

7dbf27cf215f9703.png

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.

7f64427c0e59d417.png

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.

98c324c59c1fbf68.png

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.

a64ab7b69132c722.png

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

  1. 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.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • 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.
  1. 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:

55efc1aaa7a4d3ad.png

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:

7ffe5cbb04455448.png

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