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 Marktanforderungen 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 internen regionalen 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 VPC des Kunden kann über die Ports 80 mit dem lokalen Dienst kommunizieren. Port 443 fällt nicht in den Geltungsbereich des Codelabs.
Aufgaben in diesem Lab
- Internen HTTP(S)-Load Balancer mit Hybrid-NEG-Backend erstellen
- Private Service Connect-Ersteller (Dienstanhang) und -Nutzer (Weiterleitungsregel) einrichten
Voraussetzungen
- Bestehende hybride Netzwerke, 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 darunter sind benutzerdefinierte Advertisements vom Cloud Router an das lokale Netzwerk erforderlich, damit die Firewallregeln vor Ort aktualisiert werden.
Subnetz | Beschreibung |
172.16.0.0/23 | Proxy-Subnetz, das für die direkte Kommunikation mit dem On-Premise-Dienst verwendet wird |
130.211.0.0/22, 35.191.0.0/16 |
2. Hinweis
Projekt für das Codelab aktualisieren
In diesem Codelab werden $variables verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu unterstützen.
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab
3. Einrichtung des Erstellers
VPC für den Ersteller erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
Produzentsubnetze erstellen
Führen Sie in Cloud Shell folgende 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. SHARED_VIP wird von 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 Befehl compute addresses describe, 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 anlegen. 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 folgende 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 mit 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 konvertieren.
Führen Sie in Cloud Shell folgende 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 Produzenten erstellen
Konfigurieren Sie Firewallregeln, um Traffic zwischen den Private Service Connect-Endpunkten und dem Dienstanhang zuzulassen. Im Codelab wurde eine Ingress-Firewallregel erstellt, die dem NAT-Subnetz 100.100.10.0/24 Zugriff auf den Private Service Connect-Dienstanhang (interner Load Balancer) gewährt.
Führen Sie in Cloud Shell folgende 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 On-Premise-Dienst (Backend-Dienst) über den 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 NEG für die Hybridkonnektivität.
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 On-Premise-Backend mithilfe von Hybrid-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 unter 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 eine 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
Gehen Sie in der Cloud Console zu Netzwerkdienste → Load Balancing → Load Balancer. Hinweis: Die 1 NEG ist „Grün“, was eine erfolgreiche Systemdiagnose für den lokalen Dienst bedeutet.
Wenn Sie ‘on-premise-svc-url-map' auswählen, wird die Front-End-IP-Adresse zurückgegeben und der Back-End-Dienst identifiziert.
5. Erkannte Routen auf On-Premise-Geräten ansehen
Gehen Sie zu VPC-Netzwerk → Routen. Hinweis: Das Subnetz des lokalen Dienstes 192.168.1.0/27
6. Verbindung zum On-Premise-Dienst prüfen
Im VPC des Diensterstellers erstellen wir eine VM, um die Verbindung zum On-Premise-Dienst zu testen. Danach folgt die Konfiguration der Dienstverknüpfung.
Erstellen Sie in Cloud Shell die Testinstanz im VPC des Produzenten.
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 im VPC des Produzenten.
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. Wiederholen Sie den Vorgang bei einer Zeitüberschreitung.
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 On-Premise-Dienst zu prüfen. Wenn die Überprüfung abgeschlossen ist, beenden Sie die VM und kehren Sie zur Cloud Shell-Eingabeaufforderung zurück. Ersetzen Sie die interne Load Balancer-IP-Adresse durch die in Schritt 4 ermittelte Ausgabe.
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. Sobald er mit einem Endpunkt des Verbrauchers gekoppelt ist, ist der Zugriff auf den lokalen Dienst möglich, ohne dass ein VPC-Peering erforderlich ist.
Dienstanhang erstellen
Erstellen Sie in Cloud Shell die Dienstanhänge
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 Netzwerkdienste → Private Service Connect auf, um den neu erstellten Dienstanhang aufzurufen.
Wenn Sie Service-1 auswählen, erhalten Sie weitere Details, einschließlich des URI des Dienstanhangs, den der Nutzer zum Herstellen einer Private Service-Verbindung verwendet. Notieren Sie sich den URI, da er in einem späteren Schritt verwendet wird.
Details zum Dienst-Anhang:projects/<projectname>/regions/us-central1/serviceAttachments/service-1
8. Einrichtung für Verbraucher
Nutzer-VPC erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
Nutzersubnetze erstellen
GCE-Subnetz in Cloud Shell erstellen
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 Subnetz für den Nutzerendpunkt.
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
Verwenden wir den zuvor generierten URI des Dienstanhangs, um den Endpunkt des Dienstnutzers zu erstellen.
Erstellen Sie in Cloud Shell den Endpunkt des Verbrauchers.
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 – VPC des Nutzers prüfen
Prüfen Sie im VPC des Dienstnutzers, ob eine Private Service-Verbindung erfolgreich hergestellt wurde. Rufen Sie dazu Netzwerkdienste → Private Service Connect → Verbundene Endpunkte auf. Notieren Sie sich die eingerichtete psc-consumer-1-Verbindung und die entsprechende IP-Adresse, die wir zuvor erstellt haben.
Wenn du „psc-consumer-1“ auswählst, werden Details wie der URI des Dienstanhangs angezeigt.
10. Private Service Connect für Nutzer – VPC des Erstellers prüfen
Prüfen Sie im VPC des Diensterstellers, ob die private Dienstverbindung erfolgreich hergestellt wurde. Rufen Sie dazu Netzwerkdienste → Private Service Connect → Veröffentlichter Dienst auf. Die Verbindung „Veröffentlichter Dienst 1“ weist jetzt eine Weiterleitungsregel (Verbindungsendpunkt) auf.
11. Private DNS-Zone und A-Eintrag erstellen
Erstellen Sie die private DNS-Zone, die dem PSC-Verbindungsendpunkt zugeordnet ist, um von jedem Host innerhalb des VPC nahtlos auf den Dienstanbieter zugreifen zu können.
Ü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 mit VM prüfen
Im VPC des Nutzers erstellen wir eine VM, um die Verbindung zum On-Premise-Dienst zu testen. Dazu greifen wir auf den Endpunkt des Nutzers service1.codelabs.net zu.
Erstellen Sie in Cloud Shell die Testinstanz im VPC des Kunden.
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 im VPC des Kunden.
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Melden Sie sich in Cloud Shell mit IAP in der Consumer-VM an, um die Verbindung zum On-Premise-Dienst zu prüfen. Führen Sie dazu einen Curl-Befehl für den DNS-FQDN service1.codelab.net aus. Wiederholen Sie den Vorgang bei einem Zeitüberschreitungsfehler.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
Führen Sie einen Curl-Befehl aus, um die Verbindung zum On-Premise-Dienst zu prüfen. Kehren Sie nach der Bestätigung zur Cloud Shell-Eingabeaufforderung zurück.
Curl in Cloud Shell ausführen
$ 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 eine Beispiel-Aufzeichnung vom On-Premise-Dienst. Beachten Sie, dass die Quell-IP-Adresse 172.16.0.13 aus dem Proxy-Subnetzbereich 172.16.0.0/23 stammt.
13. Producer Clean up
Produzentenkomponenten löschen
Löschen Sie in Cloud Shell die Testinstanzen in der VPC des Produzenten.
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. Verbraucherbereinigung
Nutzerkomponenten löschen
Löschen Sie in Cloud Shell die Testinstanzen im Kunden-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 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 im Nutzer-VPC erstellen, der eine Verbindung zum On-Premise-Dienst ermöglicht.
Was liegt als Nächstes an?
Sehen Sie sich einige dieser Codelabs an:
- Private Dienste zum Veröffentlichen und Nutzen von Diensten mit GKE verwenden
- Private Service Connect zum Veröffentlichen und Nutzen von Diensten verwenden
- Über Private Service Connect und einen internen TCP-Proxy-Load Balancer eine Verbindung zu On-Premise-Diensten über Hybridnetzwerke herstellen
Weitere Lesematerialien und Videos
- Private Service Connect – Übersicht
- Was ist Private Service Connect?
- Unterstützte Load Balancer-Typen