Verbindung zu lokalen Diensten über Hybridnetzwerke mit Private Service Connect und Hybrid-NEG mit internem HTTP(S)-Load-Balancer herstellen

1. Einführung

Cloud Load Balancing unterstützt Load-Balancing-Traffic zu Endpunkten, die über Google Cloud hinausgehen, z. B. lokale Rechenzentren und andere öffentliche Clouds, die Sie über Hybridkonnektivität erreichen können.

Eine Hybridstrategie ist eine pragmatische Lösung, mit der Sie Ihr Unternehmen an wechselnde Marktbedürfnisse anpassen und Ihre Anwendungen schrittweise modernisieren können. Dies kann eine temporäre Hybridbereitstellung sein, um die Migration zu einer modernen cloudbasierten Lösung zu ermöglichen, oder eine dauerhafte Bereitstellung der IT-Infrastruktur Ihres Unternehmens.

Mit der Einrichtung des Hybrid-Load-Balancings können Sie außerdem die Vorteile der Netzwerkfunktionen von Cloud Load Balancing für Dienste nutzen, die in Ihrer vorhandenen Infrastruktur außerhalb von Google Cloud ausgeführt werden.

Wenn Sie den Hybriddienst in anderen VPC-Netzwerken verfügbar machen möchten, können Sie den Dienst mit Private Service Connect veröffentlichen. Wenn Sie einen Dienstanhang vor Ihrem regionalen internen HTTP(S)-Load-Balancer platzieren, können Sie Clients in anderen VPC-Netzwerken den Zugriff auf die Hybriddienste ermöglichen, die lokal oder in anderen Cloud-Umgebungen ausgeführt werden.

Umfang

In diesem Codelab erstellen Sie einen internen HTTP(S)-Load-Balancer mit Hybridkonnektivität zu einem lokalen Dienst mithilfe einer Netzwerkendpunktgruppe. Die Consumer-VPC kann über die Ports 80 mit dem lokalen Dienst kommunizieren. Port 443 ist nicht im Umfang des Codelabs enthalten.

Lerninhalte

Internen HTTP(S)-Load-Balancer mit einem Hybrid-NEG-Backend erstellen
Private Service Connect-Producer (Dienstanhang) und -Consumer (Weiterleitungsregel) einrichten

Voraussetzungen

Eingerichtetes Hybrid Networking, z. B. HA VPN, Interconnect, SW-WAN
Google Cloud-Projekt

Hybridkonnektivität einrichten

Ihre Google Cloud-Umgebung, lokale Umgebung oder sonstige Cloud-Umgebung muss über Hybridkonnektivität verbunden sein. Dafür werden entweder Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel mit Cloud Router verwendet. Wir empfehlen die Verwendung einer Verbindung mit Hochverfügbarkeit.

Ein Cloud Router, der für das globale dynamische Routing aktiviert ist, erkennt den spezifischen Endpunkt über BGP und programmiert ihn in Ihrem Google Cloud-VPC-Netzwerk. Regionales dynamisches Routing wird nicht unterstützt. Statische Routen werden ebenfalls nicht unterstützt.

Das Google Cloud-VPC-Netzwerk, mit dem Sie entweder Cloud Interconnect oder Cloud VPN konfigurieren, ist dasselbe Netzwerk, das Sie auch zum Konfigurieren der Bereitstellung des Hybrid-Load-Balancing verwenden. Achten Sie darauf, dass die Subnetz-CIDR-Bereiche Ihres VPC-Netzwerks nicht mit Ihren Remote-CIDR-Bereichen in Konflikt stehen. Bei Überschneidung von IP-Adressen haben Subnetzrouten Vorrang vor Remote-Verbindungen.

Weitere Informationen finden Sie unter:

Benutzerdefiniertes Routen-Advertising

Für Subnetze unterhalb von sind benutzerdefinierte Advertisements vom Cloud Router zum lokalen Netzwerk erforderlich, damit die lokalen Firewallregeln aktualisiert werden.

Subnetz	Beschreibung
172.16.0.0/23	Proxy-Subnetz für die direkte Kommunikation mit dem lokalen Dienst
130.211.0.0/22, 35.191.0.0/16	Google Cloud Health Check

2. Hinweis

Projekt für das Codelab aktualisieren

In diesem Codelab werden $Variablen verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu erleichtern.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Einrichtung für Ersteller

Ersteller-VPC erstellen

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Producer-Subnetze erstellen

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

IP-Adresse für den internen Load Balancer reservieren

Führen Sie in Cloud Shell die folgenden Schritte aus. Die Verwendung von SHARED_VIP wird mit Private Service Connect nicht unterstützt. Verwenden Sie stattdessen GCE_ENDPOINT.

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

Verwenden Sie den compute addresses describe-Befehl, um die zugewiesene IP-Adresse aufzurufen.

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

Regionale Proxy-Subnetze erstellen

Die Proxyzuweisung erfolgt auf VPC-Ebene, nicht auf der Load-Balancer-Ebene. Sie müssen in jeder Region eines virtuellen Netzwerks (VPC), in dem Sie Envoy-basierte Load-Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Wenn Sie mehrere Load-Balancer in derselben Region und im selben VPC-Netzwerk bereitstellen, nutzen sie dasselbe Nur-Proxy-Subnetz für das Load-Balancing.

Ein Client stellt eine Verbindung zur IP-Adresse und zum Port der Weiterleitungsregel des Load-Balancers her.
Jeder Proxy überwacht die IP-Adresse und den Port, die in der Weiterleitungsregel des entsprechenden Load-Balancers angegeben sind. Einer der Proxys empfängt und beendet die Netzwerkverbindung des Clients.
Der Proxy stellt eine Verbindung zur entsprechenden Back-End-VM oder zum entsprechenden Back-End-Endpunkt einer Netzwerk-Endpunktgruppe her. Dies richtet sich nach der URL-Zuordnung und den Back-End-Diensten des Load-Balancers.

Nur-Proxy-Subnetze müssen unabhängig davon erstellt werden, ob Ihr Netzwerk im automatischen oder im benutzerdefinierten Modus arbeitet. Ein Nur-Proxy-Subnetz muss mindestens 64 IP-Adressen bereitstellen. Das entspricht einer Präfixlänge von maximal /26. Als Subnetzgröße wird /23 (512 Nur-Proxy-Adressen) empfohlen.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Private Service Connect-NAT-Subnetze erstellen

Erstellen Sie ein oder mehrere dedizierte Subnetze für die Verwendung von Private Service Connect. Wenn Sie die Google Cloud Console zum Veröffentlichen eines Dienstes verwenden, können Sie die Subnetze während dieses Verfahrens erstellen. Erstellen Sie das Subnetz in derselben Region wie den Load-Balancer des Dienstes. Sie können ein reguläres Subnetz nicht in ein Private Service Connect-Subnetz umwandeln.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Firewallregeln für den Producer erstellen

Konfigurieren Sie Firewallregeln, um Traffic zwischen den Private Service Connect-Endpunkten und dem Dienstanhang zuzulassen. Im Codelab wurde eine Firewallregel für eingehenden Traffic erstellt, die dem NAT-Subnetz 100.100.10.0/24 den Zugriff auf den Private Service Connect-Dienstanhang (interner Load-Balancer) ermöglicht.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

Erstellen Sie in Cloud Shell die Regel „fw-allow-health-check“, damit die Google Cloud-Systemdiagnosen den lokalen Dienst (Back-End-Dienst) auf dem TCP-Port 80 erreichen können.

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

Erstellen Sie eine Firewallregel zum Zulassen von eingehendem Traffic für das Nur-Proxy-Subnetz, damit der Load-Balancer mit Backend-Instanzen auf dem TCP-Port 80 kommunizieren kann.

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Hybridkonnektivitäts-NEG einrichten

Verwenden Sie beim Erstellen der NEG eine ZONE,die die geografische Entfernung zwischen Google Cloud und Ihrer lokalen oder sonstigen Cloud-Umgebung minimiert. Wenn Sie beispielsweise einen Dienst in einer lokalen Umgebung in Frankfurt hosten, können Sie beim Erstellen der NEG die Google Cloud-Zone „europe-west3-a“ angeben.

Wenn Sie Cloud Interconnect verwenden, sollte sich die ZONE zum Erstellen der NEG in derselben Region befinden, in der der Cloud Interconnect-Anhang konfiguriert wurde.

Informationen zu den verfügbaren Regionen und Zonen finden Sie in der Compute Engine-Dokumentation: Verfügbare Regionen und Zonen.

Erstellen Sie in Cloud Shell mit dem Befehl gcloud compute network-endpoint-groups create eine Hybridkonnektivitäts-NEG.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

Fügen Sie in Cloud Shell den lokalen IP:Port-Endpunkt zur Hybrid-NEG hinzu.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Load-Balancer konfigurieren

In den folgenden Schritten konfigurieren Sie den Load Balancer (Weiterleitungsregel) und verknüpfen ihn mit der Netzwerk-Endpunktgruppe.

Erstellen Sie in Cloud Shell die regionale Systemdiagnose, die an den lokalen Dienst übergeben wird.

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

Erstellen Sie in Cloud Shell den Back-End-Dienst für das lokale Back-End mit dem hybriden NEG.

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

Fügen Sie dem Backend-Dienst in Cloud Shell das hybride NEG-Backend hinzu. Geben Sie für RATE die maximale RATE ein, die das Backend verarbeiten soll.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

Erstellen Sie in Cloud Shell die URL-Zuordnung, um eingehende Anfragen an den Backend-Dienst weiterzuleiten.

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

HTTP-Ziel-Proxy erstellen

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-map \
    --url-map-region=us-central1 \
    --region=us-central1

Erstellen Sie eine Weiterleitungsregel, um eingehende Anfragen an den Proxy weiterzuleiten. Verwenden Sie nicht das Nur-Proxy-Subnetz, um die Weiterleitungsregel zu erstellen.

 gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --target-http-proxy-region=us-central1

4. Load Balancer überprüfen

Rufen Sie in der Cloud Console Netzwerkdienste → Load Balancing → Load Balancer auf. Hinweis: Das NEG 1 ist „Grün“, was darauf hinweist, dass die Systemdiagnose für den lokalen Dienst erfolgreich war.

Wenn Sie ‘on-premise-svc-url-map' auswählen, wird die Front-End-IP-Adresse angezeigt und der Back-End-Dienst identifiziert.

5. Erkannte Routen aus dem lokalen Netzwerk ansehen

Rufen Sie VPC-Netzwerk → Routen auf. Das erkannte lokale Dienstsubnetz 192.168.1.0/27

6. Verbindung zum lokalen Dienst prüfen

Aus der VPC des Diensterstellers erstellen wir eine VM, um die Verbindung zum lokalen Dienst zu testen. Danach wird die Dienstanhangkonfiguration vorgenommen.

Erstellen Sie in Cloud Shell die Testinstanz in der Producer-VPC.

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

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.

Erstellen Sie in Cloud Shell die Testinstanz in der Producer-VPC.

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Melden Sie sich in Cloud Shell mit IAP bei test-box-us-central1 an, um die Verbindung zum lokalen Dienst zu prüfen. Führen Sie dazu einen curl-Befehl für die Load-Balancer-IP-Adresse aus. Bei einer Zeitüberschreitung versuchen Sie es noch einmal.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Führen Sie einen curl-Befehl aus, um die Verbindung zum lokalen Dienst zu prüfen. Beenden Sie die VM, nachdem Sie die Validierung abgeschlossen haben, und kehren Sie zur Cloud Shell-Eingabeaufforderung zurück. Ersetzen Sie die IP-Adresse des internen Load-Balancers basierend auf der Ausgabe, die Sie in Schritt 4 ermittelt haben.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

7. Private Service Connect-Dienstanhang erstellen

In den folgenden Schritten erstellen wir den Dienstanhang. Nach der Verknüpfung mit einem Consumer-Endpunkt ist der Zugriff auf den lokalen Dienst ohne VPC-Peering möglich.

Dienstanhang erstellen

Erstellen Sie in Cloud Shell die Service Attachment.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

Optional:Wenn Sie eine freigegebene VPC verwenden, erstellen Sie den Dienstanhang im Dienstprojekt.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

TCP-Dienstanhang validieren

gcloud compute service-attachments describe service-1 --region us-central1

Optional: Rufen Sie Network Services → Private Service Connect auf, um den neu eingerichteten Dienstanhang anzusehen.

Wenn Sie Service-1 auswählen, werden weitere Details angezeigt, einschließlich des URI des Dienstanhangs, der vom Nutzer zum Herstellen einer Private Service Connect-Verbindung verwendet wird. Notieren Sie sich den URI, da er in einem späteren Schritt verwendet wird.

Details zum Service Attachment:projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. Einrichtung durch Nutzer

Consumer-VPC erstellen

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Nutzer-Subnetze erstellen

Erstellen Sie das GCE-Subnetz in Cloud Shell.

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

Erstellen Sie in Cloud Shell das Nutzerendpunkt-Subnetz.

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Nutzerendpunkt (Weiterleitungsregel) erstellen

Erstellen Sie in Cloud Shell die statische IP-Adresse, die als Nutzerendpunkt verwendet wird.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Erstellen Sie den Nutzerendpunkt mit dem zuvor generierten URI des Dienstanhangs.

Nutzerendpunkt in Cloud Shell erstellen

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. Private Service Connect für Nutzer validieren – Nutzer-VPC

Prüfen Sie im VPC-Netzwerk des Nutzers, ob die Private Service Connect-Verbindung erfolgreich hergestellt wurde. Rufen Sie dazu Network Services → Private Service Connect → Connected Endpoints auf. Notieren Sie sich die hergestellte Verbindung „psc-consumer-1“ und die entsprechende IP-Adresse, die wir zuvor erstellt haben.

Wenn Sie „psc-consumer-1“ auswählen, werden Details wie der URI des Dienstanhangs angezeigt.

10. Private Service Connect-Nutzer – Producer-VPC validieren

Prüfen Sie in der VPC des Diensterstellers, ob die private Dienstverbindung erfolgreich hergestellt wurde. Rufen Sie dazu Network Services → Private Service Connect → Published Service auf. Die Verbindung für den veröffentlichten Dienst 1 verweist jetzt auf eine Weiterleitungsregel (Verbindungs-Endpunkt).

11. Private DNS-Zone und A-Eintrag erstellen

Erstellen Sie die private DNS-Zone, die dem PSC-Verbindungs-Endpunkt zugeordnet ist, um nahtlosen Zugriff auf den Producer von jedem Host innerhalb der VPC zu ermöglichen.

Über Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. Nutzerzugriff auf den Dienst des Erstellers über eine VM validieren

Im VPC-Netzwerk des Nutzers erstellen wir eine VM, um die Verbindung zum lokalen Dienst zu testen, indem wir auf den Nutzerendpunkt service1.codelabs.net zugreifen.

Erstellen Sie in Cloud Shell die Testinstanz in der Consumer-VPC.

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

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.

Erstellen Sie in Cloud Shell die Testinstanz in der Consumer-VPC.

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Melden Sie sich mit IAP in Cloud Shell in der consumer-vm an, um die Verbindung zum lokalen Dienst zu prüfen, indem Sie einen curl-Befehl für den DNS-FQDN service1.codelab.net ausführen. Wiederholen Sie den Vorgang, wenn es zu einem Zeitüberschreitungsfehler kommt.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

Führen Sie in Cloud Shell einen curl-Befehl aus.

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Unten sehen Sie ein Beispiel für eine Erfassung vom lokalen Dienst. Beachten Sie, dass die Quell-IP-Adresse 172.16.0.13 aus dem Proxy-Subnetzbereich 172.16.0.0/23 stammt.

13. Bereinigung von Produzenten

Produzentenkomponenten löschen

Löschen Sie in Cloud Shell die Testinstanzen in der Producer-VPC.

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. Bereinigung durch Nutzer

Consumer-Komponenten löschen

Löschen Sie in Cloud Shell die Testinstanzen in der Nutzer-VPC.

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet

15. Glückwunsch

Sie haben Private Service Connect mit einem internen HTTP(S)-Load-Balancer erfolgreich konfiguriert und validiert.

Sie haben die Erstellerinfrastruktur erstellt und einen Dienstanhang in der Ersteller-VPC hinzugefügt, der auf einen lokalen Dienst verweist. Sie haben gelernt, wie Sie einen Nutzerendpunkt in der Nutzer-VPC erstellen, der die Verbindung zum lokalen Dienst ermöglicht.

Nächste Schritte

Hier finden Sie einige Codelabs:

Verbindung zu lokalen Diensten über Hybridnetzwerke mit Private Service Connect und Hybrid-NEG mit internem HTTP(S)-Load-Balancer herstellen

1. Einführung

Umfang

Lerninhalte

Voraussetzungen

Hybridkonnektivität einrichten

Benutzerdefiniertes Routen-Advertising

2. Hinweis

Projekt für das Codelab aktualisieren

3. Einrichtung für Ersteller

Ersteller-VPC erstellen

Producer-Subnetze erstellen

IP-Adresse für den internen Load Balancer reservieren

Verwenden Sie den compute addresses describe-Befehl, um die zugewiesene IP-Adresse aufzurufen.

Regionale Proxy-Subnetze erstellen

Private Service Connect-NAT-Subnetze erstellen

Firewallregeln für den Producer erstellen

Hybridkonnektivitäts-NEG einrichten

Load-Balancer konfigurieren

4. Load Balancer überprüfen

5. Erkannte Routen aus dem lokalen Netzwerk ansehen

6. Verbindung zum lokalen Dienst prüfen

7. Private Service Connect-Dienstanhang erstellen

Dienstanhang erstellen

8. Einrichtung durch Nutzer

Consumer-VPC erstellen

Nutzer-Subnetze erstellen

Nutzerendpunkt (Weiterleitungsregel) erstellen

9. Private Service Connect für Nutzer validieren – Nutzer-VPC

10. Private Service Connect-Nutzer – Producer-VPC validieren

11. Private DNS-Zone und A-Eintrag erstellen

12. Nutzerzugriff auf den Dienst des Erstellers über eine VM validieren

Unten sehen Sie ein Beispiel für eine Erfassung vom lokalen Dienst. Beachten Sie, dass die Quell-IP-Adresse 172.16.0.13 aus dem Proxy-Subnetzbereich 172.16.0.0/23 stammt.

13. Bereinigung von Produzenten

Produzentenkomponenten löschen

14. Bereinigung durch Nutzer

Consumer-Komponenten löschen

15. Glückwunsch

Nächste Schritte

Weitere Informationen und Videos

Referenzdokumente