1. Einführung
Mit einem internen regionalen TCP-Proxy-Load-Balancer mit Hybridkonnektivität können Sie Clients in Ihrem VPC-Netzwerk einen in lokalen oder anderen Cloud-Umgebungen gehosteten Dienst zur Verfügung stellen.
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 dem internen regionalen TCP-Proxy-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 TCP-Proxy-Load-Balancer mit Hybridkonnektivität für einen lokalen Dienst mithilfe einer Netzwerk-Endpunktgruppe. Von der Nutzer-VPC aus kann mit dem lokalen Dienst kommunizieren.
Aufgaben in diesem Lab
- TCP-Proxy-ILB mit Hybrid-NEG-Back-End-Dienst erstellen
- Private Service Connect-Producer (Dienstanhang) und Nutzer (Weiterleitungsregel) einrichten
- Kommunikation zwischen Nutzer- und Produzentendiensten testen und validieren
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 | TCP-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
TCP-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 für eingehenden Traffic, die es lokalen Diensten ermöglicht, mit dem Proxy-Subnetz an Port 80 zu kommunizieren
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 tcp on-prem-service-hc \
--region=us-central1 \
--use-serving-port
Erstellen Sie in Cloud Shell den Back-End-Dienst für das lokale Back-End
gcloud compute backend-services create on-premise-service-backend \
--load-balancing-scheme=INTERNAL_MANAGED \
--protocol=TCP \
--region=us-central1 \
--health-checks=on-prem-service-hc \
--health-checks-region=us-central1
Fügen Sie in Cloud Shell dem Back-End-Dienst das hybride NEG-Back-End hinzu. Geben Sie für MAX_CONNECTIONS die maximale Anzahl gleichzeitiger Verbindungen ein, die das Back-End verarbeiten soll.
gcloud compute backend-services add-backend on-premise-service-backend \
--network-endpoint-group=on-prem-service-neg \
--network-endpoint-group-zone=us-central1-a \
--region=us-central1 \
--balancing-mode=CONNECTION \
--max-connections=100
Zielproxy in Cloud Shell erstellen
gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
--backend-service=on-premise-service-backend \
--region=us-central1
Erstellen Sie in Cloud Shell die Weiterleitungsregel (ILB).
Erstellen Sie die Weiterleitungsregel mit dem Befehl gcloud compute forwarding-rules create.
Ersetzen Sie FWD_RULE_PORT durch eine einzelne Portnummer zwischen 1 und 65535. Die Weiterleitungsregel leitet nur Pakete mit einem übereinstimmenden Zielport weiter.
gcloud compute forwarding-rules create tcp-ilb-psc \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=producer-vpc \
--subnet=subnet-201 \
--ports=80 \
--region=us-central1 \
--target-tcp-proxy=on-premise-svc-tcpproxy \
--target-tcp-proxy-region=us-central1
IP-Adresse des internen Load-Balancers abrufen
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2
4. Load-Balancer validieren
Gehen Sie in der Cloud Console zu Netzwerkdienste → Load-Balancing → Load-Balancer. Beachten Sie, dass die 1 NEG 'Green' ist, was auf eine erfolgreiche Systemdiagnose für den lokalen Dienst hinweist.
Die Auswahl von ‘on-premise-service-backend' liefert die Frontend-IP-Adresse
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 als Nächstes zur Konfiguration bereitsteht.
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 den Schritten 3 und 4 ermittelten Ausgabe.
deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
* Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.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, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
<
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=tcp-ilb-psc --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=tcp-ilb-psc --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
8. 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
9. 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
10. 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 zusätzliche Details bereitgestellt, einschließlich des Dienstanhangs-URI
11. 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.
12. 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"
13. 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.2 stammt aus dem TCP-Proxy-Subnetzbereich 172.16.0.0/23.
14. Clean-up durch Producer
Producer-Komponenten löschen
Löschen Sie in Cloud Shell die Producer-Komponenten
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 tcp-ilb-psc --region=us-central1 --quiet
gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --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 networks subnets delete psc-nat-subnet subnet-201 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 on-prem-service-hc --region=us-central1 --quiet
gcloud compute networks delete producer-vpc --quiet
15. Bereinigung durch Nutzer
Nutzerkomponenten löschen
Nutzerkomponenten in Cloud Shell löschen
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
16. Glückwunsch
Sie haben Private Service Connect mit TCP-Proxy erfolgreich 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