Diese Seite wurde von der Cloud Translation API übersetzt.

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 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	Google Cloud-Systemüberprüfung

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:

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

1. Einführung

Umfang

Aufgaben in diesem Lab

Voraussetzungen

Hybridkonnektivität einrichten

Benutzerdefiniertes Routen-Advertising

2. Hinweis

Projekt für das Codelab aktualisieren

3. Einrichtung des Erstellers

VPC für den Ersteller erstellen

Produzentsubnetze erstellen

IP-Adresse für den internen Load Balancer reservieren

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

Regionale Proxy-Subnetze erstellen

Private Service Connect-NAT-Subnetze erstellen

Firewallregeln für den Produzenten erstellen

Hybridkonnektivitäts-NEG einrichten

Load Balancer konfigurieren

4. Load Balancer überprüfen

5. Erkannte Routen auf On-Premise-Geräten ansehen

6. Verbindung zum On-Premise-Dienst prüfen

7. Private Service Connect-Dienstanhang erstellen

Dienstanhang erstellen

8. Einrichtung für Verbraucher

Nutzer-VPC erstellen

Nutzersubnetze erstellen

Nutzerendpunkt (Weiterleitungsregel) erstellen

9. Private Service Connect für Nutzer – VPC des Nutzers prüfen

10. Private Service Connect für Nutzer – VPC des Erstellers prüfen

11. Private DNS-Zone und A-Eintrag erstellen

12. Nutzerzugriff auf den Dienst des Erstellers mit VM prüfen

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

14. Verbraucherbereinigung

Nutzerkomponenten löschen

15. Glückwunsch

Was liegt als Nächstes an?

Weitere Lesematerialien und Videos

Referenzdokumente