1. Einführung
Cloud Load Balancing unterstützt das Load-Balancing von 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 sich an sich ändernde Marktanforderungen anpassen und Ihre Anwendungen schrittweise modernisieren können. Dabei kann es sich um eine temporäre Hybridbereitstellung handeln, die die Migration zu einer modernen cloudbasierten Lösung ermöglicht oder als fester Bestandteil der IT-Infrastruktur Ihres Unternehmens.
Wenn Sie das Hybrid-Load-Balancing einrichten, können Sie die Vorteile der Netzwerkfunktionen von Cloud Load Balancing auch 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 Clients in anderen VPC-Netzwerken die Hybriddienste erreichen, die in lokalen oder anderen Cloud-Umgebungen ausgeführt werden.
Inhalt
In diesem Codelab erstellen Sie einen internen HTTP(S)-Load-Balancer mit Hybridkonnektivität zu einem lokalen Dienst mithilfe einer Netzwerk-Endpunktgruppe. Die Nutzer-VPC kann über die Ports 80 mit dem lokalen Dienst kommunizieren. Port 443 liegt nicht im Codelab.
Aufgaben in diesem Lab
- Internen HTTP(S)-Load-Balancer mit einem Hybrid-NEG-Back-End erstellen
- Private Service Connect-Producer (Dienstanhang) und Nutzer (Weiterleitungsregel) einrichten
Voraussetzungen
- Aufbau eines Hybridnetzwerks, z. B. HA VPN, Interconnect, SW-WAN
- Google Cloud-Projekt
Hybridkonnektivität einrichten
Ihre Google Cloud-Umgebung sowie Ihre lokalen oder anderen Cloud-Umgebungen müssen über Hybridkonnektivität verbunden sein. Verwenden Sie dazu entweder Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel mit Cloud Router. Wir empfehlen die Verwendung einer Verbindung mit Hochverfügbarkeit.
Ein Cloud Router mit globalem dynamischem Routing lernt den jeweiligen Endpunkt über BGP und programmiert ihn in Ihr Google Cloud-VPC-Netzwerk. Regionales dynamisches Routing wird nicht unterstützt. Statische Routen werden ebenfalls nicht unterstützt.
Das Google Cloud-VPC-Netzwerk, das Sie zum Konfigurieren von Cloud Interconnect oder Cloud VPN verwenden, ist dasselbe Netzwerk, mit dem Sie auch die Bereitstellung des Hybrid-Load-Balancings konfigurieren. Achten Sie darauf, dass die Subnetz-CIDR-Bereiche Ihres VPC-Netzwerks nicht mit Ihren Remote-CIDR-Bereichen in Konflikt stehen. Wenn sich IP-Adressen überschneiden, haben Subnetzrouten Vorrang vor Remoteverbindungen.
Weitere Informationen finden Sie unter:
Benutzerdefiniertes Routen-Advertising
Für die unten angegebenen Subnetze ist benutzerdefiniertes Advertising vom Cloud Router zum lokalen Netzwerk erforderlich. Dadurch wird sichergestellt, dass die lokalen Firewallregeln aktualisiert werden.
Subnetz | Beschreibung |
172.16.0.0/23 | Proxy-Subnetz, das für die direkte Kommunikation mit dem lokalen Dienst verwendet wird |
130.211.0.0/22, 35.191.0.0/16 |
2. Hinweis
Projekt zur Unterstützung des Codelab aktualisieren
In diesem Codelab wird $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. Producer-Einrichtung
Producer-VPC erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
Producer-Subnetze 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. Die Verwendung von SHARED_VIP wird bei 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 names description“, um die zugewiesene IP-Adresse aufzurufen.
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
Regionale Proxy-Subnetze erstellen
Die Proxy-Zuweisung 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 demselben VPC-Netzwerk bereitstellen, nutzen sie für das Load-Balancing dasselbe Nur-Proxy-Subnetz.
- 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 NEG 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 ist. 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 zur Verwendung mit Private Service Connect. Wenn Sie die Google Cloud Console zum Veröffentlichen eines Dienstes verwenden, können Sie die Subnetze dabei 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 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
Producer-Firewallregeln erstellen
Konfigurieren Sie Firewallregeln, um Traffic zwischen den Private Service Connect-Endpunkten und dem Dienstanhang zuzulassen. Sie haben im Codelab 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 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
In Cloud Shell die Regel fw-allow-health-check erstellen, damit die Google Cloud-Systemdiagnosen den lokalen Dienst (Back-End-Dienst) über 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 Back-End-Instanzen über 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 einer anderen 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 zum Erstellen der NEG verwendete ZONE außerdem in derselben Region befinden, in der der Cloud Interconnect-Anhang konfiguriert wurde.
Informationen zu den verfügbaren Regionen und Zonen finden Sie unter 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 der Hybrid-NEG den lokalen IP:Port-Endpunkt 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 mit der Netzwerk-Endpunktgruppe
Erstellen Sie in Cloud Shell die regionale Systemdiagnose, die an den lokalen Dienst übergeben wurde.
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 mithilfe einer 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 in Cloud Shell dem Back-End-Dienst das hybride NEG-Back-End hinzu. Geben Sie unter RATE die maximale RATE ein, die das Back-End 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 Back-End-Dienst weiterzuleiten.
gcloud compute url-maps create on-prem-svc-url-map \
--default-service on-premise-service-backend \
--region=us-central1
HTTP-Zielproxy 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 zum Erstellen der Weiterleitungsregel nicht das Nur-Proxy-Subnetz.
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 validieren
Gehen Sie in der Cloud Console zu Netzwerkdienste → Load-Balancing → Load-Balancer. Beachten Sie, dass die 1 NEG "Grün" ist. die eine erfolgreiche Systemdiagnose für den lokalen Dienst anzeigt.
Durch Auswahl von ‘on-premise-svc-url-map' wird die Frontend-IP-Adresse ermittelt und der Back-End-Dienst identifiziert.
5. Erkannte Routen aus lokaler Umgebung ansehen
Gehen Sie zu VPC-Netzwerk → Routen. Beachten Sie, dass das erkannte lokale Dienstsubnetz 192.168.1.0/27
6. Konnektivität zum lokalen Dienst prüfen
In der Producers-VPC erstellen wir eine VM, um die Konnektivität zum lokalen Dienst zu testen, nachdem der Dienstanhang die nächste Konfiguration ist.
Erstellen Sie in Cloud Shell die Testinstanz im Producer-VPC-Netzwerk.
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, 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.
Erstellen Sie in Cloud Shell die Testinstanz im Producer-VPC-Netzwerk.
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
Melden Sie sich mit IAP in Cloud Shell bei test-box-us-central1 an, um die Konnektivität zum lokalen Dienst zu prüfen. Führen Sie dazu einen curl-Befehl für die Load-Balancing-IP-Adresse aus. Versuche es bei einer Zeitüberschreitung 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 überprüfen. Nach dem validierten Exit der VM, der zur Cloud Shell-Eingabeaufforderung zurückkehrt. Ersetzen Sie die IP-Adresse des internen Load-Balancers anhand der in Schritt 4 ermittelten 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 Nutzerendpunkt gekoppelt ist, wird der Zugriff auf den lokalen Dienst ohne VPC-Peering ermöglicht.
Dienstanhang erstellen
Dienstanhang in Cloud Shell erstellen
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: Gehen Sie zu Netzwerkdienste → Private Service Connect, um den neu erstellten Dienstanhang anzusehen.
Wenn Sie Service-1 auswählen, werden weitere Details bereitgestellt, einschließlich des Dienstanhangs-URI, mit dem der Nutzer eine private Dienstverbindung herstellt. Notieren Sie sich den URI, da er in einem späteren Schritt benötigt wird.
Details zum Dienstanhang:projects/<projectname>/regions/us-central1/serviceAttachments/service-1
8. Nutzereinrichtung
Nutzer-VPC erstellen
Führen Sie in Cloud Shell folgende Schritte aus:
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
Nutzer-Subnetze 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 des Nutzerendpunkts
gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1
Nutzerendpunkt erstellen (Weiterleitungsregel)
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
Verwendet den zuvor generierten Dienstanhang-URI, um den Nutzerendpunkt zu erstellen
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. Consumer Private Service Connect validieren – Nutzer-VPC
Prüfen Sie in der Nutzer-VPC, ob eine private Dienstverbindung erfolgreich war. Gehen Sie dazu zu Netzwerkdienste → Private Service Connect → Verbundene Endpunkte. Notieren Sie sich die bestehende psc-consumer-1-Verbindung und die entsprechende IP-Adresse, die wir zuvor erstellt haben.
Bei Auswahl von „psc-consumer-1“ werden Details einschließlich des Dienstanhangs-URI bereitgestellt
10. Consumer Private Service Connect validieren – Producer-VPC
Überprüfen Sie in der Producer-VPC, dass die private Dienstverbindung erfolgreich war. Gehen Sie dazu zu Netzwerkdienste → Private Service Connect → Veröffentlichter Dienst. Beachten Sie, dass in der veröffentlichten Verbindung „service-1“ jetzt 1 Weiterleitungsregel (Verbindungsendpunkt) angegeben ist.
11. Private DNS-Zone erstellen und A-Eintrag
Erstellen Sie die private DNS-Zone, die dem PSC-Verbindungsendpunkt zugeordnet ist, um von jedem Host innerhalb der VPC aus nahtlosen Zugriff auf Producer zu ermöglichen.
Von 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 Producer-Dienst mit VM validieren
In der Nutzer-VPC erstellen wir eine VM, um die Konnektivität zum lokalen Dienst zu testen, indem wir auf den Nutzerendpunkt service1.codelabs.net zugreifen.
Erstellen Sie in Cloud Shell die Testinstanz im Nutzer-VPN.
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, 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.
Erstellen Sie in Cloud Shell die Testinstanz im Nutzer-VPN.
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 bei der Nutzer-VM an, um die Konnektivität zum lokalen Dienst zu prüfen. Führen Sie dazu einen curl-Befehl für den DNS-FQDN service1.codelab.net aus. Versuche es bei einer Zeitüberschreitung noch einmal.
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 lokalen Dienst zu überprüfen. Nach dem validierten Exit der VM, der zur Cloud Shell-Eingabeaufforderung zurückkehrt
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 eine Beispielaufnahme des lokalen Dienstes. Die Quell-IP-Adresse 172.16.0.13 stammt aus dem Proxy-Subnetzbereich 172.16.0.0/23.
13. Clean-up durch Producer
Producer-Komponenten 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
Nutzerkomponenten 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 konfiguriert und validiert.
Sie haben die Producer-Infrastruktur erstellt und einen Dienstanhang in der Producer-VPC hinzugefügt, der auf einen lokalen Dienst verweist. Sie haben gelernt, wie Sie in der Nutzer-VPC einen Nutzerendpunkt erstellen, der Verbindungen zum lokalen Dienst zulässt.
Was liegt als Nächstes an?
Sehen Sie sich einige dieser Codelabs an...
- Privaten Dienst zum Veröffentlichen und Verwenden von Diensten mit GKE verwenden
- Private Service Connect zum Veröffentlichen und Nutzen von Diensten verwenden
- Mit Private Service Connect und einem internen TCP-Proxy-Load-Balancer über ein Hybridnetzwerk eine Verbindung zu lokalen Diensten herstellen
Weitere Informationen und Videos
- Private Service Connect – Übersicht
- Was ist Private Service Connect?
- Unterstützte Load-Balancer-Typen