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

1. Einführung

VPC-Peering ist eine gängige Methode für Ersteller, ihren Nutzern die Nutzung von Diensten zu ermöglichen. Die Verwendung von VPC-Peering bringt jedoch viele Routing-Komplexitäten mit sich, z. B. nicht transitive VPC-Peering-Verbindungen, hoher IP-Adressverbrauch und übermäßige Offenlegung von Ressourcen in einer VPC mit Peering.

Private Service Connect (PSC) ist eine Verbindungsmethode, mit der Ersteller einen Dienst über einen einzelnen Endpunkt bereitstellen können, den ein Nutzer in einer Arbeitslast-VPC bereitstellt. Dadurch werden viele Probleme vermieden, die Nutzer mit VPC-Peering haben. Viele neue Dienste werden mit PSC erstellt, aber es gibt immer noch viele Dienste, die als VPC-Peering-Dienste vorhanden sind.

Google Cloud bietet jetzt einen Migrationspfad für Dienste, die Sie über VPC-Peering erstellt haben, um zu einer PSC-basierten Architektur zu wechseln. Bei dieser Migrationsmethode bleibt die IP-Adresse für den Erstellerservice, der über VPC-Peering bereitgestellt wird, bis zur PSC-basierten Architektur erhalten. Daher sind nur minimale Änderungen für den Consumer erforderlich. In diesem Codelab erfahren Sie, welche technischen Schritte für die Migration erforderlich sind.

HINWEIS: Dieser Migrationspfad ist nur für Dienste vorgesehen, bei denen sich Ersteller und Nutzer in derselben Google Cloud-Organisation befinden. Für alle Google Cloud-Dienste oder Dienste von Drittanbietern, die VPC-Peering verwenden, wird eine ähnliche Migrationsmethode genutzt, die jedoch für den jeweiligen Dienst angepasst wird. Wenden Sie sich bitte an die entsprechenden Stellen, um sich über den Migrationspfad für diese Arten von Diensten zu informieren.

Lerninhalte

VPC-Peering-basierte Dienste einrichten
PSC-basierten Dienst einrichten
Verwenden der Internal-Ranges API, um die Subnetzmigration über VPC-Peering durchzuführen und so eine Migration von VPC-Peering zu PSC-Diensten zu erreichen.
Ausfallzeiten bei der Dienstmigration
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 Erstellerseite und welche auf der Nutzerseite ausgeführt werden müssen, wenn sich Ersteller und Nutzer in verschiedenen Projekten befinden.

Dieses Codelab hat vier Status.

Status 1 ist der VPC-Peering-Status. Es gibt zwei VPCs, consumer-vpc und producer-vpc, die miteinander gepeert werden. In producer-vpc wird ein einfacher Apache-Dienst über einen internen Network Passthrough Load Balancer bereitgestellt. In consumer-vpc gibt es nur eine consumer-vm zu Testzwecken.

Zustand 2 ist der PSC-Testzustand. Wir erstellen eine neue Weiterleitungsregel und verknüpfen sie mit unserem Dienstanhang. Anschließend erstellen wir einen PSC-Testendpunkt in consumer-vpc, um zu prüfen, ob unser PSC-Dienst wie erwartet funktioniert.

Status 3 ist der Migrationsstatus. Wir reservieren den Subnetzbereich in producer-vpc, in dem der auf VPC-Peering basierende Dienst bereitgestellt wurde, für die Verwendung in consumer-vpc. Anschließend erstellen wir einen neuen PSC-Endpunkt mit derselben IP-Adresse wie die 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 der Nutzer-VPC und der Ersteller-VPC.

3. Einrichtung und Anforderungen

Umgebung zum selbstbestimmten Lernen einrichten

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 eines erstellen.

Der Projektname ist der Anzeigename für die Teilnehmer dieses Projekts. Es handelt sich um einen String, der nicht von Google APIs verwendet wird. Sie können sie jederzeit aktualisieren.
Die Projekt-ID ist für alle Google Cloud-Projekte eindeutig und unveränderlich (kann nach dem Festlegen nicht mehr geändert werden). In der Cloud Console wird automatisch ein eindeutiger String generiert. Normalerweise ist es nicht wichtig, wie dieser String aussieht. In den meisten Codelabs müssen Sie auf Ihre Projekt-ID verweisen (in der Regel als PROJECT_ID angegeben). Wenn Ihnen die generierte ID nicht gefällt, können Sie eine andere zufällige ID generieren. Alternativ können Sie es mit einem eigenen Namen versuchen und sehen, ob er 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

Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Cloud-Ressourcen/-APIs zu verwenden. Die Durchführung dieses Codelabs kostet wenig oder gar nichts. Wenn Sie Ressourcen herunterfahren möchten, um Kosten zu vermeiden, die über diese Anleitung hinausgehen, können Sie die erstellten Ressourcen oder das Projekt löschen. Neue Google Cloud-Nutzer können am kostenlosen Testzeitraum mit einem Guthaben von 300$ teilnehmen.

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

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

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

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 in Google Cloud, was die 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. Ersteller-VPC-Netzwerk erstellen (Erstelleraktivität)

VPC-Netzwerk

Über Cloud Shell

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

Subnetze erstellen

Über 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

Über 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 das Produzentennetzwerk erstellen

Über 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, erstellen Sie eine Firewallregel, die:

Gilt für alle VM-Instanzen, die über 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.

Über 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 erstellen wir zwei weitere Regeln, die Systemdiagnosen des Load-Balancers für den Dienst sowie Netzwerkverkehr von VMs, die eine Verbindung über die Consumer-VPC herstellen, zulassen.

Über 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. Die VM wird einer nicht verwalteten Instanzgruppe hinzugefügt, die von einem regionalen internen Passthrough-Network Load Balancer geschützt wird.

VM und nicht verwaltete Instanzgruppe erstellen

Über 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'

Über 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 Passthrough-Network-Load-Balancer erstellen

Über 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

Über Cloud Shell

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

Subnetz erstellen

Über Cloud Shell

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

Consumer-Netzwerk-Firewallrichtlinie und Firewallregeln erstellen

Wir erstellen eine weitere Netzwerk-Firewallrichtlinie für die Consumer-VPC.

Über 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

Über Cloud Shell

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

Verbraucheraktivität

Über Cloud Shell

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

Prüfen Sie, ob das Peering eingerichtet ist, indem Sie die Liste der Routen in der Nutzer-VPC aufrufen. Sie sollten Routen für die Consumer-VPC und die Producer-VPC sehen.

Verbraucheraktivität

Über 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 (Consumer-Aktivität)

Wir erstellen eine private Cloud DNS-Zone, um den Producer-Dienst über DNS anstelle einer privaten IP-Adresse aufzurufen. So wird ein realistischeres Beispiel dargestellt.

Wir fügen der Domain „beispiel.de“ einen A-Eintrag hinzu, der „service.beispiel.de“ auf die IP-Adresse der Weiterleitungsregel des Network Passthrough Load Balancers verweist, die wir zuvor erstellt haben. Die IP-Adresse der Weiterleitungsregel ist 192.168.0.2.

Über 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. Erstellerdienst über VPC-Peer testen (Nutzeraktivität)

An diesem Punkt wurde die Architektur für State 1 erstellt.

VM für Consumer-Client erstellen

Über Cloud Shell

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

Konnektivität testen

Über Cloud Shell

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

Von der Consumer-Client-VM

curl service.example.com

Erwartete Ausgabe

I am a Producer Service.

Von der Consumer-Client-VM

exit

11. Dienst für Private Service Connect vorbereiten (Erstelleraktivität)

Nachdem wir alle Schritte zur Ersteinrichtung abgeschlossen haben, bereiten wir den VPC-Peering-Dienst nun für die Migration zu Private Service Connect vor. 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 in die Consumer-VPC migrieren können, um die vorhandene IP-Adresse des Dienstes beizubehalten.

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

Über 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 der Load-Balancer-Weiterleitungsregel.

Über 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. Für diese Regel sind derselbe Back-End-Dienst und dieselben Systemdiagnosen konfiguriert, die wir zuvor konfiguriert haben.

Über 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 dem PSC-Dienstanhang für die Network Address Translation zugeordnet. Für Produktionsanwendungsfälle muss dieses Subnetzwerk so dimensioniert sein, dass die Anzahl der angehängten Endpunkte unterstützt wird. Weitere Informationen finden Sie in der Dokumentation zur Größenanpassung von PSC-NAT-Subnetzen.

Über 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 Traffic aus dem psc-nat-subnet zuzulassen. Wenn Sie über PSC auf den Dienst zugreifen, stammt der Traffic aus dem psc-nat-subnet.

Über 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.

Über 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

Über 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. „test“-PSC-Nutzerendpunkt mit dem Dienst des Anbieters verbinden und testen (Nutzeraktivität)

Die Architektur befindet sich jetzt in Zustand 2.

Der vorhandene Erstellerdienst, der über VPC-Peering bereitgestellt wird, ist in einem Produktionsszenario weiterhin aktiv und funktioniert ordnungsgemäß. Wir erstellen einen PSC-Endpunkt für Tests, um sicherzustellen, dass die bereitgestellte Dienstanhänge ordnungsgemäß funktioniert, bevor wir einen Ausfallzeitraum einleiten, um das aktuelle VPC-Peering-Subnetz in die VPC des Kunden zu migrieren. Die Konnektivität im Endzustand ist ein PSC-Endpunkt mit derselben IP-Adresse wie die aktuelle Weiterleitungsregel für den auf VPC-Peering basierenden Dienst.

PSC-Endpunkt erstellen

Über Cloud Shell

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

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

Über 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

PSC-Testendpunkt testen

Über Cloud Shell

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

Vom Consumer-Client

curl 10.0.1.3

Erwartete Ausgabe

I am a Producer Service.

Vom Consumer-Client

exit

13. Subnetz der vorhandenen Weiterleitungsregel des Erstellers migrieren

Wenn Sie diese Schritte ausführen, wird ein Ausfall für den Live-VPC-Peering-basierten Erstellerdienst initiiert. Wir migrieren das Subnetz der Weiterleitungsregel jetzt mithilfe der Internal Ranges API vom Ersteller-VPC zum Nutzer-VPC. Dadurch wird das Subnetz gesperrt und kann in der Zwischenzeit nicht verwendet werden, in der wir das Subnetz in der Producer-VPC löschen und es nur für Migrationszwecke für die Erstellung in der Consumer-VPC vorsehen.

Für die Internal Range API müssen Sie das vorhandene VPC-Peering-Weiterleitungsregel-Subnetz (producer-fr-subnet, 192.168.0.0/28) reservieren und einen Zielsubnetznamen in der Consumer-VPC (consumer-psc-subnet) angeben. Wir erstellen in wenigen Schritten ein neues Subnetz in der Nutzer-VPC mit diesem Namen.

Producer-fr-Subnetz für die Migration reservieren

Aktivität des Erstellers

Über 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 einen „describe“-Befehl für den erstellten internen Bereich aus, um den Status des Subnetzes aufzurufen.

Aktivität des Erstellers

Über 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

Über 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 zur Consumer-VPC, indem Sie ein neues Subnetz mit dem zuvor erstellten internen Bereich erstellen. Der Name dieses Subnetzes muss mit dem Namen übereinstimmen, den wir zuvor angegeben haben (consumer-psc-subnet). Der spezifische Zweck von PEER_MIGRATION gibt an, dass das Subnetz für die Subnetzmigration zwischen VPCs mit Peering reserviert ist. Mit diesem Zweck-Flag kann dieses Subnetz nur reservierte statische IP-Adressen und PSC-Endpunkte enthalten.

Verbraucheraktivität

Über 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 den Endstatus erstellen (Nutzeraktivität)

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

Über 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 von uns erstellte IP-Adresse verwendet dieselbe IP-Adresse wie die Weiterleitungsregel, die von unserem Erstellerdienst über das VPC-Peering verwendet wurde.

Über Cloud Shell

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

Sie müssen noch einmal denselben Service Attachment-URI verwenden, den Sie sich zuvor notiert haben und der auch zum Erstellen des PSC-Endpunkts „test“ verwendet wurde.

Über 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 testen (Nutzeraktivität)

Sie befinden sich jetzt in der Architektur von State 3.

Über Cloud Shell

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

Von der Consumer-Client-VM

curl service.example.com

Erwartete Ausgabe

I am a Producer Service.

Von der Consumer-Client-VM

exit

Der Ausfall ist jetzt beendet und der Dienst ist wieder verfügbar. Wir mussten keine Änderungen an den bestehenden DNS-Einträgen vornehmen. Auf Nutzerseite sind keine Clientänderungen erforderlich. Anwendungen können einfach den Betrieb des migrierten Dienstes fortsetzen.

16. Migration bereinigen

Um die Migration abzuschließen, müssen wir noch einige Bereinigungsschritte durchführen. Wir müssen Ressourcen löschen und entsperren.

Subnetz für internen Bereich entsperren

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

Aktivität des Erstellers

Über Cloud Shell

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

Verbraucheraktivität

Über 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

Über Cloud Shell

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

Verbraucheraktivität

Über Cloud Shell

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

PSC-Endpunkt „test“ löschen

Verbraucheraktivität

Über Cloud Shell

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

17. Abschlusstest nach der Bereinigung der Migration (Verbraucheraktivität)

An diesem Punkt wurde die Architektur von Zustand 4 (der endgültige Zustand) erreicht.

Testen Sie die PSC-Endpunktverbindung noch einmal, um sicherzustellen, dass durch die Bereinigung der Migration keine negativen Auswirkungen auftreten.

Über Cloud Shell

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

Von der Consumer-Client-VM

curl service.example.com

Erwartete Ausgabe

I am a Producer Service.

Von der Consumer-Client-VM

exit

Erfolgreich!

18. Bereinigungsschritte

Über 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-basierte Dienste einrichten
PSC-basierten Dienst einrichten
Verwenden der Internal-Ranges API, um die Subnetzmigration über VPC-Peering durchzuführen und so eine Migration von VPC-Peering zu PSC-Diensten zu erreichen.
Ausfallzeiten bei der Dienstmigration
Bereinigungsschritte für die Migration