Hub-and-Spoke-Netzwerk mit einem Load-Balancer als nächsten Hop bereitstellen

In dieser Anleitung wird beschrieben, wie Sie mit VPC-Netzwerk-Peering eine Hub-and-Spoke-Architektur bereitstellen.

Diese Anleitung richtet sich an Cloud-Netzwerkentwickler und Spezialisten für Betriebsvorgänge, die eine Hub-and-Spoke-Architektur in ihrer Google Cloud-Umgebung mithilfe von zentralisierten Appliances implementieren möchten, die aus virtuellen Compute Engine-Maschinen bestehen. Diese virtuellen Maschinen stellen Sie in der vorliegenden Anleitung als NAT-Gateways bereit. Sie können jedoch denselben Ansatz auch für andere Funktionen wie Firewalls der nächsten Generation verwenden. In dieser Anleitung wird davon ausgegangen, dass Sie mit VPC-Netzwerken und Compute Engine vertraut sind.

Architektur

In dieser Architektur kommunizieren mehrere Spoke-VPC-Netzwerke über ein Hub-VPC-Netzwerk mit dem öffentlichen Internet. Im Hub-VPC-Netzwerk wird Traffic über einen zentralisierten Pool von Appliances, in diesem Fall NAT-Gateways (Network Address Translation), weitergeleitet. Die relevanten Routen werden aus dem Hub-VPC-Netzwerk in die Spoke-VPC-Netzwerke exportiert. Die NAT-Gateways werden als Back-Ends eines internen Load-Balancers mit einer neuen Standardroute konfiguriert, die einen internen Passthrough-Netzwerk-Load-Balancer von Cloud Load Balancing als nächsten Hop hat.

Sie können die gleiche Art der Lastverteilung und Hochverfügbarkeit erreichen, indem Sie mehrere Routen mit Equal Cost Multi-Path-Routing (ECMP) verwenden. Die Verwendung des internen Passthrough-Netzwerk-Load-Balancers hat jedoch folgende Vorteile:

• Der Traffic wird nur an fehlerfreie Instanzen weitergeleitet, wenn Sie sich auf Systemdiagnosen verlassen. Mit ECMP wird der Traffic an alle aktiven Instanzen weitergeleitet, auf die die Route verweist. Durch den Einsatz eines internen Passthrough-Netzwerk-Load-Balancers werden nicht verwendete Routen ausgeschlossen. Außerdem müssen Sie keine Routen bereinigen, wenn Instanzen beendet oder neu gestartet werden.
• Der Failover ist potenziell schneller, da Sie die Systemdiagnose-Timer optimieren können. Wenn Sie verwaltete Instanzgruppen und die automatische Reparatur verwenden, können Sie die Systemdiagnose-Timer anpassen. Allerdings werden sie verwendet, um die Instanz neu zu erstellen und nicht den Traffic weiterzuleiten.

Google bietet auch Cloud NAT als verwalteten Dienst, mit dem sich Hochverfügbarkeit ohne Nutzerverwaltung und -interaktion realisieren lässt. Cloud NAT wird in diesem Anwendungsfall jedoch nicht unterstützt, da die NAT-Konfiguration nicht in ein Peering-Netzwerk importiert wird.

Das folgende Diagramm zeigt die Topologie, die Sie in dieser Anleitung erstellen.

Die Topologie besteht aus einem Hub-VPC- und zwei Spoke-VPC-Netzwerken, die über VPC-Netzwerk-Peering mit dem Hub-VPC-Netzwerk verbunden sind. Das Hub-VPC-Netzwerk hat zwei NAT-Gateway-Instanzen hinter einem internen Passthrough-Network-Load-Balancer. Eine statische Standardroute (0/0 NAT-GW-ILB) verweist auf den internen Passthrough-Network-Load-Balancer als nächsten Hop. Diese statische Standardroute wird über VPC-Netzwerk-Peering mithilfe von benutzerdefinierten Routen exportiert.

Ziele

• Mehrere VPC-Netzwerke erstellen und mithilfe einer Hub-and-Spoke-Architektur eine Peering-Verbindung zwischen diesen herstellen
• NAT-Gateways im Hub-VPC-Netzwerk erstellen und konfigurieren
• Internen Passthrough-Network-Load-Balancer als nächsten Hop einrichten und konfigurieren
• Verbindungen von den Spoke-VPC-Netzwerken zum öffentlichen Internet prüfen

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• Compute Engine

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. Enable the Compute Engine API.

   Enable the API

5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

6. Make sure that billing is enabled for your Google Cloud project.

7. Enable the Compute Engine API.

   Enable the API

8. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

In dieser Anleitung führen Sie alle Befehle über Cloud Shell aus.

Umgebung einrichten

1. Achten Sie darauf, dass Sie in Cloud Shell in dem Google Cloud-Projekt arbeiten, das Sie erstellt oder ausgewählt haben. Ersetzen Sie project-id durch Ihr Google Cloud-Projekt.

   gcloud config set project project-id
   
   export PROJECT_ID=`gcloud config list --format="value(core.project)"`
   

2. Legen Sie eine standardmäßige Compute Engine-Region und -Zone fest.

   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-c
   export REGION=us-central1
   export ZONE=us-central1-c
   

   In dieser Anleitung ist die Region us-central1 und die Zone us-central1-c.

VPC-Netzwerke und -Subnetze erstellen

1. Erstellen Sie in Cloud Shell das Hub-VPC-Netzwerk und -Subnetz:

   gcloud compute networks create hub-vpc --subnet-mode custom
   
   gcloud compute networks subnets create hub-subnet1 \
       --network hub-vpc --range 10.0.0.0/24
   

2. Erstellen Sie die Spoke-VPC-Netzwerke spoke1-vpc und spoke2-vpc mit jeweils einem Subnetz:

   gcloud compute networks create spoke1-vpc --subnet-mode custom
   
   gcloud compute networks create spoke2-vpc --subnet-mode custom
   
   gcloud compute networks subnets create spoke1-subnet1 \
       --network spoke1-vpc --range 192.168.1.0/24
   
   gcloud compute networks subnets create spoke2-subnet1 \
       --network spoke2-vpc --range 192.168.2.0/24
   

3. Erstellen Sie Firewallregeln im Hub-VPC-Netzwerk und den Spoke-VPC-Netzwerken. Diese Regeln lassen internen Traffic (TCP/80 und 443, UDP/53 und ICMP) aus den angegebenen RFC 1918-Bereichen zu:

   gcloud compute firewall-rules create hub-vpc-web-ping-dns \
       --network hub-vpc --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,192.168.1.0/24,192.168.2.0/24
   
   gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \
       --network spoke1-vpc --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,192.168.1.0/24
   
   gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \
       --network spoke2-vpc --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,192.168.2.0/24
   

4. Erstellen Sie Firewallregeln im Hub-VPC-Netzwerk und in den Spoke-VPC-Netzwerken, damit IAP for SSH auf alle virtuellen Maschinen zugreifen kann:

   gcloud compute firewall-rules create hub-vpc-iap \
       --network hub-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   
   gcloud compute firewall-rules create spoke1-vpc-iap \
       --network spoke1-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   
   gcloud compute firewall-rules create spoke2-vpc-iap \
       --network spoke2-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   

   In dieser Anleitung wird Identity-Aware Proxy (IAP) for SSH verwendet. Weitere Informationen finden Sie unter Verbindung zu Instanzen herstellen, die keine externe IP-Adresse haben.

5. Erstellen Sie eine Firewallregel, um Systemdiagnosen für Instanzgruppen mit automatischer Reparatur im Hub-VPC-Netzwerk zuzulassen:

   gcloud compute firewall-rules create hub-vpc-health-checks \
       --network hub-vpc --allow tcp:443 --target-tags nat-gw \
       --source-ranges 130.211.0.0/22,35.191.0.0/16
   

Instanzen und erforderliche Routen erstellen

1. Erstellen Sie in Cloud Shell die Instanzvorlage für das NAT-Gateway mit einem Startskript, mit dem das NAT-Gateway eingerichtet wird:

   gcloud compute instance-templates create \
     hub-nat-gw-ilbnhop-template \
     --network hub-vpc \
     --subnet hub-subnet1 \
     --machine-type n1-standard-2 --can-ip-forward \
     --tags nat-gw --scopes default,compute-rw \
     --metadata startup-script='#! /bin/bash
   apt-get update
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
   # Read VM network configuration:
   md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
   md_net="$md_vm/network-interfaces"
   nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google")"
   nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
   nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
   nic0_id="$(ip addr show | grep $nic0_addr | tail -c 5)"
   # Use a web server to pass the health check for this example.
   # In production, use a more complete test.
   sudo apt-get update
   sudo apt-get install apache2 -y
   sudo a2ensite default-ssl
   sudo a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html
   sudo systemctl restart apache2
   # Enable IP masquerading
   iptables -t nat -A POSTROUTING -o $nic0_id -j MASQUERADE'
   

   In dieser Anleitung wird n1-standard-2 als Instanztyp verwendet. Sie können aber eine beliebige Anzahl von Gateways in beliebiger Größe verwenden. Berücksichtigen Sie Faktoren wie die maximale Bandbreite für ausgehenden Traffic pro VM.

2. Erstellen Sie eine HTTP-Systemdiagnose:

   gcloud compute health-checks create http nat-gw-ilbnhop-health-check \
       --region us-central1 \
       --port 80
   

3. Erstellen Sie eine regionale Instanzgruppe mit zwei Instanzen, die über eine einzelne Region verteilt sind:

   gcloud compute instance-groups managed create \
       hub-nat-gw-ilbnhop-mig \
       --region us-central1 --size=2 \
       --template=hub-nat-gw-ilbnhop-template \
       --health-check nat-gw-ilbnhop-health-check \
       --initial-delay 15
   

   In dieser Anleitung ist die anfängliche Verzögerung auf 15 Sekunden festgelegt. Passen Sie diese Einstellung in einer Produktionsbereitstellung an Ihre Anforderungen an. Autoscaling-Richtlinien werden in dieser Anleitung nicht verwendet.

4. Erstellen Sie einen Back-End-Dienst und fügen Sie die Instanzgruppe hinzu:

   gcloud compute backend-services create hub-nat-gw-ilbnhop-backend \
       --load-balancing-scheme=internal \
       --protocol=tcp \
       --health-checks=nat-gw-ilbnhop-health-check
   
   gcloud compute backend-services add-backend \
       hub-nat-gw-ilbnhop-backend \
       --instance-group=hub-nat-gw-ilbnhop-mig \
       --instance-group-region=us-central1
   

5. Erstellen Sie eine Weiterleitungsregel:

   gcloud compute forwarding-rules create \
       hub-nat-gw-ilbnhop \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet1 \
       --address=10.0.0.10 \
       --ip-protocol=TCP \
       --ports=all \
       --backend-service=hub-nat-gw-ilbnhop-backend \
       --backend-service-region=us-central1 \
       --service-label=hub-nat-gw-ilbnhop
   

   Auch wenn die Weiterleitungsregel nur mit TCP definiert ist, leitet die Weiterleitungsregel bei Verwendung des internen Passthrough-Network-Load-Balancers als nächsten Hop den gesamten Traffic an alle Ports auf den Back-End-VMs weiter. Der interne Passthrough-Network-Load-Balancer ist ein regionaler Load-Balancer.

6. Erstellen Sie eine neue Route mit der Weiterleitungsregel als nächsten Hop:

   gcloud compute routes create hub-nat-gw-ilbnhop \
       --network=hub-vpc \
       --destination-range=0.0.0.0/0 \
       --next-hop-ilb=hub-nat-gw-ilbnhop \
       --next-hop-ilb-region=us-central1 \
       --priority=800
   

   Sie können Netzwerk-Tags festlegen, sodass die Route für den nächsten Hop nur für Clientinstanzen gilt, die mit dem Tag konfiguriert wurden. Die Tags werden jedoch nicht über VPC-Netzwerk-Peering exportiert oder importiert.

7. Löschen Sie die Standardroute aus der Hub-VPC:

   export hub_default_route=$(gcloud compute routes list \
       --format="value(name)" --filter="network:hub-vpc AND \
       nextHopGateway:default-internet-gateway" | head -n 1)
   gcloud compute routes delete $hub_default_route -q
   

8. Erstellen Sie eine neue getaggte Route, um nur Traffic aus den NAT-Gateways zuzulassen:

   gcloud compute routes create hub-default-tagged \
       --network hub-vpc --destination-range 0.0.0.0/0 \
       --next-hop-gateway default-internet-gateway \
       --priority 700 --tags nat-gw
   

9. Löschen Sie die Standardrouten zum Internet aus der VPC aller Spokes:

   export spoke1_default_route=$(gcloud compute routes list \
       --format="value(name)" --filter="network:spoke1-vpc AND \
       nextHopGateway:default-internet-gateway")
   
   gcloud compute routes delete $spoke1_default_route -q
   
   export spoke2_default_route=$(gcloud compute routes list \
       --format="value(name)" \
       --filter="network:spoke2-vpc AND nextHopGateway:default-internet-gateway")
   
   gcloud compute routes delete $spoke2_default_route -q
   

   Bei Konflikten zwischen lokalen und importierten Routen haben die lokalen Routen immer Vorrang. Weitere Informationen finden Sie unter Routingreihenfolge.

10. Erstellen Sie Client-VMs:

    gcloud compute instances create spoke1-client \
        --subnet=spoke1-subnet1 --no-address \
        --metadata startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'
    
    gcloud compute instances create spoke2-client \
        --subnet=spoke2-subnet1 --no-address \
        --metadata startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'
    

VPC-Netzwerk-Peering-Verbindungen erstellen

Das VPC-Netzwerk-Peering ist bidirektional und muss daher an beiden Enden definiert werden. Für ein VPC-Netzwerk kann Peering mit mehreren anderen VPC-Netzwerken eingerichtet werden. Allerdings gibt es hierfür Limits. Damit Sie die Standardroute über VPC-Netzwerk-Peering erreichen, verwenden Sie das Feature zum Importieren und Exportieren von benutzerdefinierten Routen über VPC-Netzwerk-Peering.

Für diese Anleitung erstellen Sie alle VPC-Netzwerke im selben Google Cloud-Projekt.

1. Erstellen Sie in Cloud Shell die VPC-Verbindungen vom Hub-VPC-Netzwerk zu den Spoke-VPC-Netzwerken mit aktiviertem Routenexport-Flag:

   gcloud compute networks peerings create hub-to-spoke1 \
       --network hub-vpc --peer-network spoke1-vpc \
       --peer-project $PROJECT_ID \
       --export-custom-routes
   
   gcloud compute networks peerings create hub-to-spoke2 \
       --network hub-vpc --peer-network spoke2-vpc \
       --peer-project $PROJECT_ID \
       --export-custom-routes
   

2. Erstellen Sie eine VPC-Netzwerk-Peering-Verbindung vom VPC-Netzwerk spoke1 zum Hub-VPC-Netzwerk mit aktiviertem Routenimport-Flag:

   gcloud compute networks peerings create spoke1-to-hub \
       --network spoke1-vpc --peer-network hub-vpc \
       --peer-project $PROJECT_ID \
       --import-custom-routes
   

3. Erstellen Sie eine VPC-Netzwerk-Peering-Verbindung vom VPC-Netzwerk spoke2 zum Hub-VPC-Netzwerk mit aktiviertem Routenimport-Flag:

   gcloud compute networks peerings create spoke2-to-hub \
       --network spoke2-vpc --peer-network hub-vpc \
       --peer-project $PROJECT_ID \
       --import-custom-routes
   

Routenverteilung und -verbindung prüfen

1. Prüfen Sie in Cloud Shell, ob die statischen Routen korrekt im Rahmen des Startskripts erstellt wurden:

   gcloud compute routes list --filter="network:hub-vpc"
   

   Achten Sie darauf, dass die Routen hub-default-tagged und hub-nat-gw-ilbanhop in der Ausgabe vorhanden sind:

   NAME                            NETWORK  DEST_RANGE      NEXT_HOP                  PRIORITY
   default-route-13a4b635b5eab48c  hub-vpc  10.0.0.0/24     hub-vpc                   1000
   hub-default-tagged              hub-vpc  0.0.0.0/0       default-internet-gateway  700
   hub-nat-gw-ilbanhop             hub-vpc  0.0.0.0/0       10.0.0.10                 800
   peering-route-3274f1257a9842a0  hub-vpc  192.168.2.0/24  hub-to-spoke2             1000
   peering-route-798c5777f13094bc  hub-vpc  192.168.1.0/24  hub-to-spoke1             1000
   

2. Prüfen Sie anhand der Routingtabelle spoke1-vpc, ob die Standardroute korrekt importiert wurde:

   gcloud compute routes list --filter="network:spoke1-vpc"
   

   Achten Sie darauf, dass eine Route, die mit peering-route beginnt und 0.0.0.0/0 als Wert für DEST_RANGE hat, in der Ausgabe vorhanden ist:

   NAME                            NETWORK     DEST_RANGE      NEXT_HOP       PRIORITY
   default-route-75f6ea8f5fc54813  spoke1-vpc  192.168.1.0/24  spoke1-vpc     1000
   peering-route-6c7f130b860bfd39  spoke1-vpc  10.0.0.0/24     spoke1-to-hub  1000
   peering-route-9d44d362f98afbd8  spoke1-vpc  0.0.0.0/0       spoke1-to-hub  800
   

3. Stellen Sie eine SSH-Verbindung über IAP zu einem der Clients her:

   gcloud compute ssh spoke1-client --tunnel-through-iap
   

4. Überprüfen Sie die Verbindung, indem Sie das öffentliche Google-DNS über das NAT-Gateway testen:

   sudo hping3 -S -p 80 -c 3 dns.google
   

   Da der interne Passthrough-Netzwerk-Load-Balancer TCP und UDP unterstützt, können Sie die Internetverbindung nicht mit einem ICMP-basierten Ping überprüfen. Daher müssen Sie ein Tool wie hping3 verwenden.

   Die Ausgabe sieht in etwa so aus:

   HPING dns.google (eth0 8.8.4.4): S set, 40 headers + 0 data bytes
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=4.6 ms
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=4.4 ms
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=4.3 ms
   
   --- dns.google hping statistic ---
   3 packets transmitted, 3 packets received, 0% packet loss
   round-trip min/avg/max = 4.3/4.4/4.6 ms
   

5. Prüfen Sie die öffentliche IP-Adresse, die Sie für die Kommunikation mit dem Internet verwenden:

   curl ifconfig.co
   

   In der Ausgabe wird eine öffentliche IP-Adresse von einer der NAT-Gateway-Instanzen angezeigt. Wenn Sie den Befehl noch einmal ausführen, wird in der Ausgabe unter Umständen eine andere öffentliche IP-Adresse angezeigt, da die Verbindungen über die konfigurierte Sitzungsaffinität des internen Load-Balancings verteilt werden (standardmäßig Client-IP, Protokoll und Port).

   Das VPC-Netzwerk-Peering ist nicht transitiv, sodass es keine Verbindung zwischen den Spoke-VPC-Netzwerken über VPC-Netzwerk-Peering gibt.

Überlegungen zur Produktionsumgebung

In der Konfiguration, die Sie in dieser Anleitung erstellen, werden zwei NAT-Gateways in einer einzelnen Region bereitgestellt. Das ECMP-Load-Balancing ist jedoch nicht perfekt und ein einzelner Ablauf wird nicht auf mehrere Verknüpfungen verteilt. Das möchten Sie jedoch, wenn Sie zustandsorientierte Geräte wie Firewalls der nächsten Generation verwenden.

Achten Sie beim Bereitstellen dieser Konfiguration in der Produktionsumgebung auf die folgenden Punkte:

• Diese Konfiguration eignet sich am besten für kurzlebige oder nicht zustandsorientierte externe Verknüpfungen. Wenn sich die Größe des NAT-Gateway-Pools ändert, werden TCP-Verbindungen unter Umständen neu ausgeglichen. Das kann dazu führen, dass eine hergestellte Verbindung zurückgesetzt wird.
• Die Knoten werden nicht automatisch aktualisiert. Wenn eine Debian-Standardinstallation eine Sicherheitslücke aufweist, müssen Sie das Image manuell aktualisieren.
• Wenn Sie VMs in mehreren Regionen haben, müssen Sie NAT-Gateways in jeder Region einrichten.
• Die Bandbreite pro Gateway kann je nach Hardwaretyp variieren. Berücksichtigen Sie Faktoren wie die maximale Bandbreite für ausgehenden Traffic pro VM. Bei einem Gatewayausfall wird der Traffic auf die verbleibenden Gateways verteilt. Da aktive Abläufe jedoch nicht neu programmiert werden, wird der Traffic nicht sofort wiederhergestellt, wenn das Gateway wieder online ist. Achten Sie deshalb darauf, dass bei der Größenanpassung ausreichend Puffer vorhanden ist.
• Wenn Sie über unerwartete Ergebnisse informiert werden möchten, verwenden Sie Cloud Monitoring, um die verwalteten Instanzgruppen und den Netzwerktraffic zu beobachten.

Bereinigen

Am einfachsten können Sie die Abrechnung deaktivieren, wenn Sie das Google Cloud-Projekt löschen, das Sie für die Anleitung erstellt haben. Alternativ haben Sie die Möglichkeit, die einzelnen Ressourcen zu löschen.

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:
• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Einzelne Ressourcen löschen

Wenn Sie das Google Cloud-Projekt beibehalten möchten, können Sie die Ressourcen löschen, die Sie für diese Anleitung erstellt haben.

1. Löschen Sie die VPC-Netzwerk-Peering-Verbindungen:

   gcloud compute networks peerings delete spoke2-to-hub \
       --network spoke2-vpc -q
   
   gcloud compute networks peerings delete spoke1-to-hub \
       --network spoke1-vpc -q
   
   gcloud compute networks peerings delete hub-to-spoke1 \
       --network hub-vpc -q
   
   gcloud compute networks peerings delete hub-to-spoke2 \
       --network hub-vpc -q
   

2. Löschen Sie die Instanzen, Load-Balancer-Ressourcen, Vorlagen und Routen:

   gcloud compute instances delete spoke1-client \
     --zone=us-central1-c -q
   
   gcloud compute instances delete spoke2-client \
     --zone=us-central1-c -q
   
   gcloud compute routes delete hub-nat-gw-ilbnhop -q
   
   gcloud compute forwarding-rules delete hub-nat-gw-ilbnhop -q
   
   gcloud compute backend-services delete -q hub-nat-gw-ilbnhop-backend -q
   
   gcloud compute instance-groups managed delete hub-nat-gw-ilbnhop-mig \
     --region us-central1 -q
   
   gcloud compute health-checks delete nat-gw-ilbnhop-health-check -q
   
   gcloud compute instance-templates delete hub-nat-gw-ilbnhop-template -q
   
   gcloud compute routes delete hub-default-tagged -q
   

3. Löschen Sie die Firewallregeln, Subnetze und VPC-Netzwerke:

   gcloud compute firewall-rules delete spoke2-vpc-iap -q
   
   gcloud compute firewall-rules delete spoke2-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete spoke1-vpc-iap -q
   
   gcloud compute firewall-rules delete spoke1-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete hub-vpc-iap -q
   
   gcloud compute firewall-rules delete hub-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete hub-vpc-health-checks -q
   
   gcloud compute networks subnets delete spoke1-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks subnets delete spoke2-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks subnets delete hub-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks delete spoke1-vpc -q
   
   gcloud compute networks delete spoke2-vpc -q
   
   gcloud compute networks delete hub-vpc -q
   

Nächste Schritte

• Mehr über Best Practices und Referenzarchitekturen für das VPC-Design erfahren
• Lesen Sie die Dokumentation zu VPC-Netzwerk-Peering und dem internen Passthrough-Netzwerk-Load-Balancer als nächstem Hop.
• Lesen Sie mehr über spezielle Konfigurationen für VM-Instanzen.