Private Service Connect: Migration von VPC-Peering zu Private Service Connect

1. Einführung

VPC-Peering ist eine gängige Methode, mit der Ersteller ihren Nutzern eine Dienstnutzung anbieten können. Die Verwendung von VPC-Peering bringt jedoch viele Routingkomplexitäten mit sich, wie z. B. bei nicht transitivem VPC-Peering, einem hohen Verbrauch von IP-Adressen und der übermäßigen Verfügbarkeit von Ressourcen in einer Peering-VPC.

Private Service Connect (PSC) ist eine Verbindungsmethode, mit der Ersteller einen Dienst über einen einzelnen Endpunkt verfügbar machen können, den ein Nutzer in einer Arbeitslast-VPC bereitstellt. Dadurch werden viele Probleme vermieden, mit denen Nutzer beim VPC-Peering konfrontiert sind. Während viele neue Dienste mit PSC erstellt werden, gibt es immer noch viele Dienste, die als VPC-Peering-Dienste vorhanden sind.

Für Google Cloud gibt es jetzt einen Migrationspfad für Dienste, den Sie über VPC-Peering erstellt haben, um zu einer PSC-basierten Architektur zu wechseln. Bei dieser Migrationsmethode wird die IP-Adresse für den Producer-Dienst, der über VPC-Peering verfügbar gemacht wird, bis zur PSC-basierten Architektur beibehalten, sodass für den Nutzer nur minimale Änderungen erforderlich sind. In diesem Codelab erfahren Sie mehr über die technischen Schritte für diese Migration.

HINWEIS: Dieser Migrationspfad gilt nur für Dienste, bei denen der Ersteller und der Nutzer in derselben Google Cloud-Organisation vorhanden sind. Für alle Google Cloud-Dienste oder Drittanbieterdienste, die VPC-Peering verwenden, wird eine ähnliche Migrationsmethode eingesetzt, die jedoch an den Dienst selbst angepasst wird. Erkundigen Sie sich bei den zuständigen Ansprechpartnern nach dem Migrationspfad für diese Arten von Diensten.

Aufgaben in diesem Lab

• VPC-Peering-basierten Dienst einrichten
• PSC-basierten Dienst einrichten
• Die Internal-Ranges API verwenden, um eine Subnetzmigration über VPC-Peering durchzuführen, um eine Migration von VPC-Peering zum PSC-Dienst zu erreichen.
• Verstehen, wann für die Dienstmigration Ausfallzeiten auftreten müssen
• Bereinigungsschritte für die Migration

Voraussetzungen

• Google Cloud-Projekt mit Inhaberberechtigungen

2. Codelab-Topologie

Der Einfachheit halber werden in diesem Codelab alle Ressourcen in einem einzigen Projekt zentralisiert. Im Codelab wird angegeben, welche Aktionen auf der Produzentenseite und welche auf der Verbraucherseite ausgeführt werden müssen, wenn sich Produzenten und Nutzer in verschiedenen Projekten befinden.

Dieses Codelab hat 4 Status.

Status 1 ist der Status des VPC-Peerings. Es wird zwei VPCs, „consumer-vpc“ und „produzent-vpc“, geben, die durch Peering verbunden werden. Producer-vpc verfügt über einen einfachen Apache-Dienst, der über einen internen Netzwerk-Passthrough-Load-Balancer verfügbar gemacht wird. Der Consumer-VPC verfügt zu Testzwecken über eine einzige Consumer-VM.

Status 2 ist der PSC-Teststatus. Wir erstellen eine neue Weiterleitungsregel und verknüpfen diese Regel mit unserem Dienstanhang. Anschließend erstellen wir einen PSC-Testendpunkt in der Nutzer-VM, um zu testen, ob unser PSC-Dienst wie erwartet funktioniert.

Status 3 ist der Migrationsstatus. Wir reservieren den Subnetzbereich im Producer-VPC-Bereich, in dem der VPC-Peering-basierte Dienst bereitgestellt wurde, für die Verwendung im Consumer-vpc. Anschließend erstellen wir einen neuen PSC-Endpunkt mit derselben IP-Adresse wie die bereits vorhandene Weiterleitungsregel in Producer-VPC.

Status 4 ist der endgültige PSC-Status. Wir bereinigen den PSC-Testendpunkt und löschen das VPC-Peering zwischen dem Nutzer-VPC und dem Producer-VPC.

3. Einrichtung und Anforderungen

Einrichtung der Umgebung im eigenen Tempo

1. Melden Sie sich in der Google Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie ein Konto erstellen.

• Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es ist ein Zeichenstring, der von Google APIs nicht verwendet wird. Sie können ihn jederzeit aktualisieren.
• Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und kann nach der Festlegung nicht mehr geändert werden. In der Cloud Console wird automatisch ein eindeutiger String generiert. In der Regel spielt es keine Rolle, wie er lautet. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (normalerweise als PROJECT_ID gekennzeichnet). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige generieren. Alternativ können Sie Ihr eigenes Konto ausprobieren und prüfen, ob es verfügbar ist. Sie kann nach diesem Schritt nicht mehr geändert werden und bleibt für die Dauer des Projekts bestehen.
• Zur Information: Es gibt einen dritten Wert, die Projektnummer, die von einigen APIs verwendet wird. Weitere Informationen zu diesen drei Werten finden Sie in der Dokumentation.

Achtung:Eine Projekt-ID ist global eindeutig und kann nach der Auswahl nicht mehr von anderen verwendet werden. Sie sind der einzige Nutzer dieser ID. Auch wenn ein Projekt gelöscht wird, kann die ID nicht wiederverwendet werden.

Hinweis:Wenn Sie ein Gmail-Konto verwenden, können Sie den Standardspeicherort auf Keine Organisation belassen. Wenn Sie ein Google Workspace-Konto verwenden, wählen Sie einen Standort aus, der für Ihre Organisation sinnvoll ist.

2. Als Nächstes müssen Sie in der Cloud Console die Abrechnung aktivieren, um Cloud-Ressourcen/-APIs verwenden zu können. Die Durchführung dieses Codelabs ist kostenlos oder kostet nur sehr wenig. Wenn Sie die Ressourcen deaktivieren möchten, um weitere Kosten nach Abschluss dieser Anleitung zu vermeiden, können Sie die von Ihnen erstellten Ressourcen oder das Projekt löschen. Neuen Google Cloud-Nutzern steht das kostenlose Testprogramm mit einem Guthaben von 300$ zur Verfügung.

Cloud Shell starten

Sie können Google Cloud zwar per Fernzugriff von Ihrem Laptop aus nutzen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der Google Cloud Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Minuten dauern. Wenn der Vorgang abgeschlossen ist, sollte in etwa Folgendes angezeigt werden:

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Dadurch werden Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.

4. Hinweis

APIs aktivieren

Prüfen Sie in Cloud Shell, ob Ihr Projekt eingerichtet ist, und konfigurieren Sie Variablen.

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

Alle erforderlichen Dienste aktivieren

gcloud services enable compute.googleapis.com
gcloud services enable networkconnectivity.googleapis.com
gcloud services enable dns.googleapis.com

5. Producer-VPC-Netzwerk erstellen (Producer-Aktivität)

VPC-Netzwerk

Aus Cloud Shell

gcloud compute networks create producer-vpc \
    --subnet-mode=custom

Subnetze erstellen

Aus 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

Producer-Cloud Router und Cloud NAT erstellen

Aus 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

Firewallrichtlinie und Firewallregeln für Producer-Netzwerk erstellen

Aus 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

Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, müssen Sie eine Firewallregel erstellen, die:

• Gilt für alle VM-Instanzen, die mit IAP zugänglich sein sollen.
• Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.

Aus 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

Außerdem werden wir zwei weitere Regeln erstellen, die Load-Balancer-Systemdiagnosen für den Dienst sowie Netzwerktraffic von VMs zulassen, die eine Verbindung vom Nutzer-VPC-Computer herstellen.

Aus 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. Einrichtung des Producer-Dienstes (Producer-Aktivität)

Wir erstellen einen Producer-Dienst mit einer einzelnen VM, auf der ein Apache-Webserver ausgeführt wird. Dieser wird einer nicht verwalteten Instanzgruppe mit einem regionalen internen Netzwerk-Passthrough-Load-Balancer hinzugefügt.

VM und nicht verwaltete Instanzgruppe erstellen

Aus 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'

Aus 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

Regionalen internen Netzwerk-Passthrough-Load-Balancer erstellen

Aus 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. Nutzer-VPC-Netzwerk erstellen (Nutzeraktivität)

VPC-Netzwerk

Aus Cloud Shell

gcloud compute networks create consumer-vpc \
    --subnet-mode=custom

Subnetz erstellen

Aus Cloud Shell

gcloud compute networks subnets create consumer-vm-subnet \
    --network=consumer-vpc \
    --range=10.0.1.0/28 \
    --region=$region

Firewallrichtlinie und Firewallregeln für Nutzernetzwerke erstellen

Wir erstellen eine weitere Netzwerk-Firewallrichtlinie für den Nutzer-VPC.

Aus 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. VPC-Peer erstellen

Aktivität des Erstellers

Aus Cloud Shell

gcloud compute networks peerings create producer-vpc-peering \
    --network=producer-vpc \
    --peer-project=$projectid \
    --peer-network=consumer-vpc

Verbraucheraktivität

Aus Cloud Shell

gcloud compute networks peerings create consumer-vpc-peering \
    --network=consumer-vpc \
    --peer-project=$projectid \
    --peer-network=producer-vpc

Prüfen Sie anhand der Liste der Routen im Nutzer-VPC, ob das Peering eingerichtet wurde. Sie sollten Routen sowohl für Nutzer-VPC als auch für Producer-VPC sehen.

Verbraucheraktivität

Aus Cloud Shell

gcloud compute routes list --filter="network=consumer-vpc"

Erwartete Ausgabe

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. DNS-Zone erstellen (Nutzeraktivität)

Um ein realistischeres Beispiel zu zeigen, erstellen wir eine private Cloud DNS-Zone, um den Producer-Dienst über DNS statt über eine private IP-Adresse aufzurufen.

Wir fügen der Domain "example.com", die auf "service.example.com" verweist, der IP-Adresse der Weiterleitungsregel des Netzwerk-Passthrough-Load-Balancers, die wir zuvor erstellt haben, einen A-Eintrag hinzu. Die IP-Adresse der Weiterleitungsregel lautet 192.168.0.2.

Aus 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. Producer-Dienst über VPC-Peer testen (Nutzeraktivität)

Jetzt wurde die State 1-Architektur erstellt.

Nutzer-Client-VM erstellen

Aus Cloud Shell

gcloud compute instances create consumer-client \
   --zone=$zone \
   --subnet=consumer-vm-subnet \
   --no-address

Konnektivität testen

Aus Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

Von Nutzer-Client-VM

curl service.example.com

Erwartete Ausgabe

I am a Producer Service. 

Von Nutzer-Client-VM

exit

11. Dienst für Private Service Connect vorbereiten (Producer-Aktivität)

Nachdem Sie nun alle ersten Einrichtungsschritte abgeschlossen haben, beginnen wir damit, den VPC-Peering-Dienst für die Migration zu Private Service Connect vorzubereiten. In diesem Abschnitt nehmen wir Änderungen an der Producer-VPC vor, indem wir den Dienst so konfigurieren, dass er über einen Dienstanhang verfügbar gemacht wird. Wir müssen ein neues Subnetz und eine neue Weiterleitungsregel in diesem Subnetz erstellen, damit wir das vorhandene Subnetz zum Nutzer-VPC-Netzwerk migrieren können, damit die vorhandene IP-Adresse des Dienstes intakt bleibt.

Erstellen Sie das Subnetz, in dem die neue IP-Adresse der Weiterleitungsregel für den Load-Balancer gehostet wird.

Aus Cloud Shell

gcloud compute networks subnets create producer-psc-fr-subnet \
    --network=producer-vpc \
    --range=10.0.2.64/28 \
    --region=$region

Erstellen Sie die interne IP-Adresse des Load-Balancers.

Aus Cloud Shell

gcloud compute addresses create producer-psc-ip \
  --region $region \
  --subnet producer-psc-fr-subnet \
  --addresses 10.0.2.66

Erstellen Sie die neue Weiterleitungsregel für den Load-Balancer. Diese Regel ist so konfiguriert, dass sie denselben Back-End-Dienst und dieselben Systemdiagnosen verwendet, die wir zuvor konfiguriert haben.

Aus 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

Das psc-nat-subnet wird zum Zweck der Netzwerkadressübersetzung mit dem PSC-Dienstanhang verknüpft. Für Anwendungsfälle in der Produktion muss dieses Subnetz so groß sein, dass es die Anzahl der angehängten Endpunkte unterstützt. Weitere Informationen finden Sie in der Dokumentation zur PSC NAT-Subnetzgröße.

Aus 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

Wir müssen der Netzwerk-Firewallrichtlinie eine zusätzliche Firewallregel hinzufügen, um jetzt Traffic aus dem psc-nat-subnet zuzulassen. Wenn Sie über PSC auf den Dienst zugreifen, wird der Traffic aus dem psc-nat-subnet stammen.

Aus 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

Erstellen Sie den Dienstanhang und notieren Sie sich den URI des Dienstanhangs, um den PSC-Endpunkt im nächsten Abschnitt zu konfigurieren.

Aus 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

Aus Cloud Shell

gcloud compute service-attachments describe producer-sa --region=$region

Beispielausgabe

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. Verbinden Sie den „test“-Nutzer-PSC-Endpunkt mit dem Producer-Dienst und dem Test (Nutzeraktivität)

Die Architektur befindet sich jetzt im Status 2.

Zu diesem Zeitpunkt ist der vorhandene Producer-Dienst, der über VPC-Peering verfügbar gemacht wird, noch live und funktioniert im Produktionsszenario ordnungsgemäß. Wir erstellen einen Test-PSC-Endpunkt, um sicherzustellen, dass der bereitgestellte Dienstanhang ordnungsgemäß funktioniert, bevor wir eine Ausfallzeit einleiten, um das aktuelle VPC-Peering-Subnetz zur Nutzer-VPC zu migrieren. Unsere Endstatusverbindung ist ein PSC-Endpunkt mit derselben IP-Adresse wie die aktuelle Weiterleitungsregel für den VPC-Peering-basierten Dienst.

PSC-Endpunkt erstellen

Aus Cloud Shell

gcloud compute addresses create test-psc-endpoint-ip \
    --region=$region \
    --subnet=consumer-vm-subnet \
    --addresses 10.0.1.3

Der unten aufgeführte Zieldienst ist der URI des Dienstanhangs, den Sie im letzten Schritt notiert haben.

Aus 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

Testen Sie den PSC-Endpunkt „test“.

Aus Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

Von Privatkunde

curl 10.0.1.3

Erwartete Ausgabe

I am a Producer Service. 

Von Privatkunde

exit

13. Vorhandenes Subnetz für die Weiterleitungsregel des Erstellers migrieren

Durch das Ausführen dieser Schritte wird ein Ausfall des Producer-Dienstes auf Basis des Live-VPC-Peerings ausgelöst. Nun migrieren wir das Subnetz für die Weiterleitungsregel mit der Internal Ranges API vom Producer-VPC- zum Consumer-VPC. Dadurch wird das Subnetz gesperrt, sodass es in der Zwischenzeit nicht verwendet werden kann, wenn wir das Subnetz im Producer-VPC löschen und es nur für Migrationszwecke zur Erstellung im Consumer-VPC-PC festlegen.

Für die API des internen Bereichs müssen Sie das vorhandene Subnetz der VPC-Peering-Weiterleitungsregel (Producer-fr-subnet, 192.168.0.0/28) reservieren und einen Zielsubnetznamen im Nutzer-VPC-Netzwerk (consumer-psc-subnet) festlegen. Wir erstellen in wenigen Schritten ein neues Subnetz mit diesem Namen im Nutzer-VPC.

Producer-fr-subnet für Migration reservieren

Aktivität des Erstellers

Aus 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

Führen Sie eine Beschreibung für den von uns erstellten internen Bereich aus, um den Status des Subnetzes anzuzeigen.

Aktivität des Erstellers

Aus Cloud Shell

gcloud network-connectivity internal-ranges describe producer-peering-internal-range

Beispielausgabe

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

VPC-Peering-basierte Weiterleitungsregel und Subnetz löschen

Aktivität des Erstellers

Aus 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

Subnetz migrieren

Migrieren Sie das Subnetz zum Nutzer-VPN. Dazu erstellen Sie mit dem zuvor erstellten internen Bereich ein neues Subnetz. Der Name dieses Subnetzes muss mit dem Namen übereinstimmen, den wir zuvor für das Targeting ausgewählt haben (consumer-psc-subnet). PEER_MIGRATION hat den speziellen Zweck, dass das Subnetz für die Subnetzmigration zwischen Peering-VPCs reserviert ist. Mit diesem Zweck-Flag kann dieses Subnetz nur reservierte statische IP-Adressen und PSC-Endpunkte enthalten.

Verbraucheraktivität

Aus 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. PSC-Endpunkt für Endstatus (Nutzeraktivität) erstellen

Zu diesem Zeitpunkt ist der Producer-Dienst noch nicht verfügbar. Das soeben erstellte Subnetz ist immer noch gesperrt und kann nur für den speziellen Zweck der Migration verwendet werden. Sie können dies testen, indem Sie versuchen, eine VM in diesem Subnetz zu erstellen. Die VM-Erstellung schlägt fehl.

Aus Cloud Shell

gcloud compute instances create test-consumer-vm \
    --zone=$zone \
    --subnet=consumer-psc-subnet \
    --no-address

Erwartete Ausgabe

ERROR: (gcloud.compute.instances.create) Could not fetch resource:
 - Subnetwork must have purpose=PRIVATE.

Wir können dieses Subnetz nur zum Erstellen eines PSC-Endpunkts verwenden. Die erstellte IP-Adresse verwendet dieselbe IP-Adresse wie die Weiterleitungsregel, die unser Producer-Dienst über den VPC-Peer verwendet hat.

Aus Cloud Shell

gcloud compute addresses create psc-endpoint-ip \
    --region=$region \
    --subnet=consumer-psc-subnet \
    --addresses 192.168.0.2

Auch hier müssen Sie denselben Dienstanhang-URI verwenden, den Sie zuvor notiert haben und der auch zum Erstellen des PSC-Endpunkts "test" verwendet wurde.

Aus 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. PSC-Endpunkt für Endstatus (Nutzeraktivität) testen

Sie befinden sich jetzt in der State 3-Architektur.

Aus Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

Von Nutzer-Client-VM

curl service.example.com

Erwartete Ausgabe

I am a Producer Service. 

Von Nutzer-Client-VM

exit

Zu diesem Zeitpunkt ist der Ausfall beendet und der Dienst ist wieder verfügbar. Am bestehenden DNS mussten keine Änderungen vorgenommen werden. Kundenseitige Änderungen am Client sind nicht erforderlich. Anwendungen können Vorgänge für den migrierten Dienst einfach wieder aufnehmen.

16. Bereinigung der Migration

Zum Abschluss der Migration müssen wir noch einige Bereinigungsschritte ausführen. Wir müssen Ressourcen löschen und freischalten.

Subnetz für den internen Bereich entsperren

Dadurch wird das migrierte Subnetz entsperrt und sein Zweck kann von „PEER_MIGRATION“ in „PRIVATE“ geändert werden.

Aktivität des Erstellers

Aus Cloud Shell

gcloud network-connectivity internal-ranges delete producer-peering-internal-range

Verbraucheraktivität

Aus Cloud Shell

gcloud compute networks subnets update consumer-psc-subnet \
    --region=$region \
    --purpose=PRIVATE

gcloud compute networks subnets describe consumer-psc-subnet --region=$region

Beispielausgabe

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

VPC-Peers löschen

Aktivität des Erstellers

Aus Cloud Shell

gcloud compute networks peerings delete producer-vpc-peering \
    --network=producer-vpc

Verbraucheraktivität

Aus Cloud Shell

gcloud compute networks peerings delete consumer-vpc-peering \
        --network=consumer-vpc

Löschen Sie den PSC-Endpunkt „test“

Verbraucheraktivität

Aus Cloud Shell

gcloud compute forwarding-rules delete test-psc-endpoint --region=$region
gcloud compute addresses delete test-psc-endpoint-ip --region=$region

17. Letzter Test nach der Bereinigung der Migration (Nutzeraktivität)

Zu diesem Zeitpunkt wurde die State 4-Architektur (der endgültige Zustand) erreicht.

Testen Sie die PSC-Endpunktverbindung noch einmal, um sicherzustellen, dass keine negativen Auswirkungen der Migrationsbereinigung beobachtet werden.

Aus Cloud Shell

gcloud compute ssh \
    --zone "$zone" "consumer-client" \
    --tunnel-through-iap \
    --project $projectid

Von Nutzer-Client-VM

curl service.example.com

Erwartete Ausgabe

I am a Producer Service. 

Von Nutzer-Client-VM

exit

Erfolgreich!

18. Bereinigungsschritte

Aus 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. Glückwunsch!

Herzlichen Glückwunsch zum Abschluss des Codelabs.

Behandelte Themen

• VPC-Peering-basierten Dienst einrichten
• PSC-basierten Dienst einrichten
• Die Internal-Ranges API verwenden, um eine Subnetzmigration über VPC-Peering durchzuführen, um eine Migration von VPC-Peering zum PSC-Dienst zu erreichen.
• Verstehen, wann für die Dienstmigration Ausfallzeiten auftreten müssen
• Bereinigungsschritte für die Migration