In der Google Cloud Platform (GCP) startet jedes neue Projekt mit einem Standard-VPC-Netzwerk, sobald Sie die Compute Engine API aktivieren – es sei denn, Sie deaktivieren dies.
Das vereinfacht die Nutzung von GCP, weil Sie weder eine eigene VPC noch Subnetze anlegen müssen. Der Haken am Standard-Netzwerk: Alle automatisch erzeugten Subnetze nutzen vordefinierte IPv4-Bereiche innerhalb des CIDR-Blocks 10.128.0.0/9.
Eine private interne Kommunikation zwischen Projekten ist wegen der überlappenden Netzwerke nicht möglich. Diese Einschränkung betrifft sowohl VPC Peering als auch Cloud VPN.
In diesem Blogbeitrag zeigen wir Ihnen, wie Sie mit Private Service Connect privat auf Dienste zugreifen, die in VM- oder GKE-Clustern mit überlappenden Netzwerken laufen – egal, ob die Netzwerke zur selben oder zu verschiedenen GCP-Organisationen gehören.
Referenzarchitektur
Ziel-Setup für Private Service Connect
Projekt B ist das Service-Producer-Projekt mit einem beispielhaften nginx-Dienst, der auf einer Instanz in einer Managed Instance Group läuft.
Projekt A ist das Service-Consumer-Projekt und soll privat auf den Dienst in Projekt B zugreifen. Die Instanzen in beiden Projekten haben keine externe IP.
- GCP-Region für die Ressourcen: us-west4
- Die API compute.googleapis.com ist in Projekt A und Projekt B aktiviert
- Cloud NAT für den Internetzugriff privater Instanzen zum Herunterladen von Paketen
Beispieldienst und Testinstanz bereitstellen
Passen Sie die Variablen in den folgenden Befehlen an Ihre Umgebung an.
- Erstellen Sie eine Instanzvorlage in Projekt B.
gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash$'\n'yum\ install\ epel-release$'\n'yum\ -y\ install\ nginx$'\n'systemctl\ start\ nginx \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=nginx-service-instance-template,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--reservation-affinity=any \
--project=$PROJECT_B
- Legen Sie eine Managed Instance Group in Projekt B an.
gcloud beta compute instance-groups managed create nginx-service-instance-group \
--base-instance-name=nginx-service \
--size=1 \
--template=nginx-service-instance-template \
--zone=us-west4-a \
--list-managed-instances-results=PAGELESS \
--no-force-update-on-repair \
--project=$PROJECT_B
Nach erfolgreicher Erstellung startet die Managed Instance Group eine Instanz in der Zielzone.
Verbinden Sie sich per SSH mit der Instanz und prüfen Sie den Status des nginx-Dienstes.
- Legen Sie eine Testinstanz für die Konnektivitätsprüfung in Projekt A an.
gcloud compute instances create instance-1 \
--zone=us-west4-b \
--machine-type=e2-medium \
--network-interface=stack-type=IPV4_ONLY,subnet=default,no-address \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=instance-2,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=projects/project-a-385206/zones/us-west4-b/diskTypes/pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--labels=ec-src=vm_add-gcloud \
--reservation-affinity=any \
--project=$PROJECT_A
Zwischen den Netzwerken von Projekt A und Projekt B besteht keine interne Verbindung. Die Instanz in Projekt A kann den Dienst in Projekt B daher nicht erreichen.
VPC Peering scheidet wegen der überlappenden IP-Bereiche im Standard-Netzwerk aus.
Internen Load Balancer einrichten
Damit Private Service Connect den Dienst über ein Service Attachment bereitstellen kann, brauchen Sie einen internen Load Balancer. Dafür legen wir in Projekt B einen internen TCP-Load-Balancer an.
- Erstellen Sie einen neuen regionalen HTTP-Health-Check, der die HTTP-Konnektivität der VMs auf Port 80 prüft.
gcloud compute health-checks create http nginx-service-health-check \
--region=us-west4 \
--port=80 \
--project=$PROJECT_B
- Legen Sie den Backend-Service für den HTTP-Traffic an.
gcloud compute backend-services create nginx-service-internal-lb-backend \
--load-balancing-scheme=internal \
--protocol=tcp \
--region=us-west4 \
--health-checks=nginx-service-health-check \
--health-checks-region=us-west4 \
--project=$PROJECT_B
- Hängen Sie die nginx-Instanzgruppe an den Backend-Service an.
gcloud compute backend-services add-backend nginx-service-internal-lb-backend \
--region=us-west4 \
--instance-group=nginx-service-instance-group \
--instance-group-zone=us-west4-a \
--project=$PROJECT_B
- Erstellen Sie eine Weiterleitungsregel für den Backend-Service.
gcloud compute forwarding-rules create nginx-service-internal-fr \
--region=us-west4 \
--load-balancing-scheme=internal \
--network=default \
--subnet=default \
--ip-protocol=TCP \
--ports=80 \
--backend-service=nginx-service-internal-lb-backend \
--backend-service-region=us-west4 \
--project=$PROJECT_B
- Richten Sie eine Firewall-Regel ein, die Health Checks des Load Balancers zulässt.
gcloud compute firewall-rules create allow-internal-lb-health-check \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=35.191.0.0/16,130.211.0.0/22
--project=$PROJECT_B
Dienste im Service-Producer-Projekt veröffentlichen
Veröffentlichen Sie den Dienst in Projekt B – dem Service-Producer-Projekt –, damit Consumer in anderen VPC-Netzwerken privat und sicher darauf zugreifen können.
- Reservieren Sie ein Subnetz für Private Service Connect. Der Subnetzbereich darf sich nicht mit dem Standard-Netzwerk überschneiden.
gcloud compute networks subnets create private-service-connect \
--network default \
--region us-west4 \
--range 10.0.1.0/24 \
--purpose=PRIVATE_SERVICE_CONNECT \
--project=$PROJECT_B
- Stellen Sie den nginx-Dienst für Projekt A mit expliziter Projektfreigabe bereit.
gcloud compute service-attachments create nginx-service \
--region=us-west4 \
--producer-forwarding-rule=nginx-service-internal-fr \
--connection-preference=ACCEPT_MANUAL \
--nat-subnets=private-service-connect \
--consumer-accept-list=$PROJECT_A=10 \
--project=$PROJECT_B
Welche Consumer auf die veröffentlichten Dienste zugreifen dürfen, steuern Sie wahlweise per automatischer oder manueller Freigabe. Details dazu finden Sie unter Dienste mit Private Service Connect veröffentlichen.
- Richten Sie eine Firewall-Regel ein, die Private Service Connect den Zugriff auf die Zielinstanzen erlaubt.
gcloud compute firewall-rules create allow-private-service-connect \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=10.0.1.0/24
--project=$PROJECT_B
Endpoint im Service-Consumer-Projekt konfigurieren
Ein Endpoint im Service-Consumer-Projekt verbindet sich über eine Private-Service-Connect-Weiterleitungsregel mit Diensten im VPC-Netzwerk des Producers.
Beim Erstellen wird der Endpoint automatisch im Service Directory registriert – entweder unter einem von Ihnen gewählten Namespace oder unter dem Standard-Namespace goog-psc-default.
Damit der Endpoint aus mehreren Regionen erreichbar ist, aktivieren Sie Global Access. Global Access ist aktuell in der Preview.
- Reservieren Sie eine interne IP-Adresse für den Endpoint.
gcloud compute addresses create private-service-connect-endpoint \
--region=us-west4 \
--subnet=default \
--project=$PROJECT_A
- Erstellen Sie eine Weiterleitungsregel, die den Endpoint mit dem Service Attachment in Projekt B verknüpft.
PSC_SERVICE_ATTACHMENT=$(gcloud compute service-attachments describe nginx-service \
--region=us-west4 \
--project=$PROJECT_B \
--format="value(selfLink.scope(projects))")
gcloud compute forwarding-rules create nginx-service \
--region=us-west4 \
--network=default \
--address=private-service-connect-endpoint \
--target-service-attachment="projects/$PSC_SERVICE_ATTACHMENT" \
--project=$PROJECT_A
Konnektivität aus dem Consumer-Projekt testen
Die Komponenten von Private Service Connect sind nun in Projekt A und Projekt B konfiguriert. Greifen Sie über die Endpoint-IP in Projekt A auf den nginx-Dienst in Projekt B zu.
Der Test bestätigt: Die Instanzen in den überlappenden Netzwerken können über den Private Service Connect Endpoint privat miteinander kommunizieren.
Dieses Beispiel zeigt, wie Sie Dienste in überlappenden Netzwerken mit Private Service Connect sicher veröffentlichen und nutzen.
Der Traffic bleibt vollständig innerhalb von Google Cloud und ermöglicht serviceorientierten Zugriff zwischen Consumern und Producern – mit feingranularer Kontrolle darüber, wie auf die Dienste zugegriffen wird.
Mehr zu Private Service Connect lesen Sie auf der Produktseite.