פריסת רשת מסוג Hub-and-Spoke באמצעות מאזן עומסים כקפיצה הבאה

במדריך הזה מוסבר איך להשתמש בקישור בין רשתות VPC שכנות (peering) כדי לפרוס ארכיטקטורת רכזת ונקודות הסתעפות.

המדריך הזה מיועד למהנדסי רשתות בענן ולמומחי תפעול שרוצים להטמיע ארכיטקטורת רכזת וגלגלים בסביבתCloud de Confiance by S3NS שלהם באמצעות מכשירים מרכזיים שמורכבים ממכונות וירטואליות של Compute Engine. במדריך הזה, תפרסו את המכונות הווירטואליות האלה כשערי NAT, אבל תוכלו להשתמש באותו גישה גם לפונקציות אחרות, כמו חומות אש מהדור הבא. במדריך הזה אנחנו מניחים שאתם מכירים רשתות VPC ו-Compute Engine.

ארכיטקטורה

באופן הזה, קבוצה של רשתות VPC מסוג Spoke מתקשרת עם העולם החיצוני דרך רשת VPC מסוג Hub, שבה תעבורת הנתונים מנותבת דרך מאגר מרכזי של מכשירים, ובמקרה הזה, שערים של תרגום כתובות רשת (NAT). הנתיבים הרלוונטיים מיוצאים מרשת ה-VPC המרכזית לרשתות ה-VPC המשניות. שערי NAT מוגדרים כבק-אנד של מאזן עומסים פנימי עם נתיב ברירת מחדל חדש, שמוגדר בו מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי מ-Cloud Load Balancing כנקודת הקפיצה הבאה.

אפשר להשיג את אותו סוג של חלוקת עומסים וזמינות גבוהה באמצעות שימוש בכמה נתיבים עם ניתוב רב-נתיבי בעלות שווה (ECMP). עם זאת, לשימוש במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי יש את היתרונות הבאים:

  • התנועה מועברת רק למופעים תקינים כשמסתמכים על בדיקות תקינות. עם ECMP, תעבורת נתונים מועברת לכל המכונות הפעילות שהמסלול מצביע עליהן. שימוש במאזן עומסי רשת פנימי מבטל את האפשרות של מסלולים לא בשימוש. בנוסף, אין צורך לנקות מסלולים כשמפסיקים או מפעילים מחדש מופעים.
  • המעבר לגיבוי (failover) עשוי להיות מהיר יותר כי אפשר לכוונן את טיימרים של בדיקת תקינות. אם אתם משתמשים בקבוצות מנוהלות של מופעים ובתיקון אוטומטי, עדיין תוכלו להתאים אישית את טיימרים של בדיקות תקינות, אבל הם ישמשו ליצירה מחדש של המופע ולא לניתוב תנועה.

‫Google מציעה גם את Cloud NAT כשירות מנוהל, שמספק זמינות גבוהה ללא ניהול משתמשים והתערבות שלהם. עם זאת, Cloud NAT לא נתמך בתרחיש השימוש הזה כי הגדרת ה-NAT לא מיובאת לרשת עם שותפות.

התרשים הבא מציג את הטופולוגיה שתיצרו במדריך הזה.

ארכיטקטורה של רשת VPC מרכזית עם שתי רשתות VPC מסוג Spoke.

הטופולוגיה מורכבת מרשת VPC מרכזית ושתי רשתות VPC מסוג Spoke שמקושרות לרשת ה-VPC המרכזית באמצעות קישור בין רשתות VPC שכנות (peering). ברשת ה-VPC של הרכזת יש שני מופעים של שער NAT מאחורי מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי. מסלול ברירת מחדל סטטי (0/0 NAT-GW-ILB) מצביע על מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי כעל הצעד הבא. נתיב ברירת המחדל הסטטי הזה מיוצא באמצעות נתיבים מותאמים אישית דרך שיוך רשתות VPC.

מטרות

  • יצירת כמה רשתות VPC וביצוע פעולת Peering ביניהן באמצעות ארכיטקטורת Hub and Spoke.
  • יוצרים ומגדירים שערי NAT ברשת ה-VPC של הרכזת.
  • מגדירים ומגדירים את מאזן עומסי הרשת הפנימי להעברת סיגנל ללא שינוי כנקודת הקפיצה הבאה.
  • בודקים את הקישוריות מרשתות ה-VPC מסוג Spoke לאינטרנט הציבורי.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Cloud de Confiance by S3NS, והשימוש בהם כרוך בתשלום:

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

לפני שמתחילים

  1. In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Cloud de Confiance project.

  3. Enable the Compute Engine API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  4. במסוף Cloud de Confiance , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

    בחלק התחתון של Cloud de Confiance המסוף יתחיל סשן של Cloud Shell ותופיע הודעה של שורת הפקודה. Cloud Shell היא סביבת מעטפת שבה ה-CLI של Google Cloud מותקן ומוגדרים ערכים לפרויקט הקיים. הסשן יופעל תוך כמה שניות.

    5. במדריך הזה, כל הפקודות מורצות מ-Cloud Shell.

הגדרת הסביבה

  1. ב-Cloud Shell, מוודאים שאתם עובדים בפרויקטCloud de Confiance שיצרתם או בחרתם. מחליפים את project-id בפרויקט ב- Cloud de Confiance .

    gcloud config set project project-id

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

  2. מגדירים את אזור החישוב ואת התחום (zone) שמוגדרים כברירת מחדל.

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

    במדריך הזה, האזור הוא us-central1 והתחום הוא us-central1-c.

יצירת רשתות VPC ורשתות משנה

  1. יוצרים ב-Cloud Shell את רשת ה-VPC של הרכזת ואת תת-הרשת:

    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. יוצרים את רשתות ה-VPC מסוג Spoke, שנקראות spoke1-vpc ו-spoke2-vpc, עם תת-רשת אחת בכל אחת מהן:

    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. יוצרים כללי חומת אש ברשת ה-VPC של הרכזת וברשתות ה-VPC של החישורים. הכללים האלה מאפשרים תעבורה פנימית (TCP/80 ו-443,‏ UDP/53 ו-ICMP) מהטווחים שצוינו ב-RFC 1918:

    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. יוצרים כללי חומת אש ברשת ה-VPC המרכזית וברשתות ה-VPC המשניות כדי לאפשר ל-IAP for SSH לגשת לכל המכונות הווירטואליות:

    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

    במדריך הזה נעשה שימוש בשרת proxy לאימות זהויות (IAP) עבור SSH. מידע נוסף מופיע במאמר בנושא חיבור למכונות שאין להן כתובות IP חיצוניות.

  5. יוצרים כלל של חומת אש שמאפשר בדיקות תקינות עבור קבוצות של מכונות עם תיקון אוטומטי ברשת ה-VPC של הרכזת:

    gcloud compute firewall-rules create hub-vpc-health-checks \
    --network hub-vpc --allow tcp:443 --target-tags nat-gw \
    --source-ranges 177.222.80.0/23

יצירת המופעים והמסלולים הנדרשים

  1. ב-Cloud Shell, יוצרים את תבנית של הגדרות מכונה לשער NAT עם סקריפט לטעינה בזמן ההפעלה שמגדיר את שער NAT:

    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'

    במדריך הזה נעשה שימוש ב-n1-standard-2 כסוג המופע, אבל אתם יכולים להשתמש בכל מספר או גודל אחר של שער שתרצו. חשוב להביא בחשבון גורמים כמו רוחב הפס המקסימלי של תעבורת הנתונים היוצאת (egress) לכל מכונה וירטואלית.

  2. יוצרים בדיקת תקינות HTTP:

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

  3. יוצרים קבוצת מופעי מכונה אזורית עם שני מופעים שמפוזרים באזור אחד:

    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

    במדריך הזה, ההשהיה הראשונית מוגדרת ל-15 שניות. בפריסה בסביבת ייצור, צריך להתאים אישית את ההגדרה הזו בהתאם לדרישות. במדריך הזה לא נעשה שימוש במדיניות של שינוי גודל אוטומטי.

  4. יוצרים שירות לקצה העורפי ומוסיפים את קבוצת המכונות:

    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. כדי ליצור כלל העברה:

    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

    למרות שכלל ההעברה מוגדר רק עם TCP, כשמשתמשים במאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי כצעד הבא, כלל ההעברה מעביר את כל התעבורה לכל היציאות במכונות ה-VM של העורף. מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי הוא מאזן עומסים אזורי.

  6. יוצרים מסלול חדש עם כלל ההעברה כנקודת הקפיצה הבאה:

    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

    אתם יכולים לציין תגים לרשת כדי שהנתיב של ה-next-hop יחול רק על מופעי לקוח שהוגדרו עם התג, אבל התגים לא מיוצאים או מיובאים דרך VPC Network Peering.

  7. מוחקים את מסלול ברירת המחדל מרשת ה-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. יוצרים מסלול חדש עם תג כדי לאפשר תעבורת נתונים רק משערי ה-NAT:

    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. מוחקים את מסלולי ברירת המחדל לאינטרנט מרשת ה-VPC של כל רשת משנית:

    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

    אם יש התנגשות בין מסלולים מקומיים למסלולים מיובאים, תמיד תינתן עדיפות למסלולים המקומיים. מידע נוסף זמין במאמר בנושא סדר הניתוב.

  10. יוצרים מכונות וירטואליות של לקוחות:

    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 שכנות (peering)

קישור בין רשתות VPC שכנות (peering) הוא דו-כיווני, ולכן צריך להגדיר אותו בשני הצדדים. רשת VPC יכולה להיות מקושרת לכמה רשתות VPC, אבל יש מגבלות. כדי להגיע לנתיב ברירת המחדל באמצעות קישור בין רשתות VPC שכנות (peering), צריך להשתמש בתכונה ייבוא וייצוא של נתיבים מותאמים אישית באמצעות קישור בין רשתות VPC שכנות (peering).

במדריך הזה, יוצרים את כל רשתות ה-VPC באותוCloud de Confiance פרויקט.

  1. ב-Cloud Shell, יוצרים את חיבורי ה-VPC מרשת ה-VPC המרכזית לרשתות ה-VPC המשניות עם הדגל של ייצוא המסלול מופעל:

    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. יוצרים קישור בין רשתות VPC שכנות (peering) מרשת ה-VPC spoke1 לרשת ה-VPC המרכזית, עם הדגל של ייבוא מסלולים מופעל:

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

  3. יוצרים קישור בין רשתות VPC שכנות (peering) מרשת ה-VPC spoke2 לרשת ה-VPC המרכזית, עם הדגל של ייבוא מסלולים מופעל:

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

אימות של הפצת המסלול והקישוריות

  1. ב-Cloud Shell, מוודאים שהמסלולים הסטטיים נוצרו בצורה נכונה כחלק מסקריפטים להפעלה.

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

    מוודאים שהנתיבים hub-default-tagged ו-hub-nat-gw-ilbanhop מופיעים בפלט:

    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. בודקים את spoke1-vpc טבלת הניתוב כדי לוודא שנתיב ברירת המחדל יובא בצורה נכונה:

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

    מוודאים שיש נתיב שמתחיל ב-peering-route עם 0.0.0.0/0 כערך של DEST_RANGE בפלט:

    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. מתחברים לאחד הלקוחות באמצעות SSH דרך IAP:

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

  4. כדי לוודא שיש קישוריות, בודקים את ה-DNS הציבורי של Google דרך שער ה-NAT:

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

    מאחר שמאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי תומך ב-TCP וב-UDP, אי אפשר לאמת את הקישוריות לאינטרנט באמצעות פינג מבוסס ICMP, ולכן צריך להשתמש בכלי כמו hping3.

    הפלט אמור להיראות כך:

    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. בודקים את כתובת ה-IP הציבורית שבה אתם משתמשים כדי לתקשר עם האינטרנט:

    curl ifconfig.co

    בפלט מוצגת כתובת IP ציבורית של אחת מהמופעים של שער ה-NAT. אם מריצים את הפקודה שוב, יכול להיות שהפלט יציג כתובת IP ציבורית שונה כי החיבורים מופצים באמצעות זיקה לסשן (session affinity) של איזון העומסים הפנימי שהוגדר (כברירת מחדל, כתובת ה-IP של הלקוח, הפרוטוקול והיציאה).

    קישור בין רשתות VPC שכנות (peering) הוא לא טרנזיטיבי, ולכן אין קישוריות בין רשתות ה-VPC המקושרות באמצעות קישור בין רשתות VPC שכנות.

שיקולים לגבי סביבת ייצור

ההגדרה שתיצרו במדריך הזה מספקת שני שערי NAT באזור אחד. עם זאת, איזון העומסים ב-ECMP הוא לא מושלם, וזרימה בודדת לא מתפזרת על פני כמה קישורים. זה מה שרוצים כשמשתמשים במכשירים עם שמירת מצב כמו חומות אש מהדור הבא.

כדי לפרוס את ההגדרה הזו בסביבת הייצור, צריך לשים לב לנקודות הבאות:

  • ההגדרה הזו מתאימה ביותר לקישורים יוצאים זמניים או לקישורים יוצאים שלא שומרים את מצב המשתמש. אם הגודל של מאגר שער ה-NAT משתנה, יכול להיות שחיבורי ה-TCP יאזנו את עצמם מחדש, וזה עלול לגרום לאיפוס של חיבור קיים.
  • הצמתים לא מתעדכנים אוטומטית, ולכן אם בהתקנת ברירת מחדל של Debian יש פגיעות אבטחה, צריך לעדכן את התמונה באופן ידני.
  • אם יש לכם מכונות וירטואליות בכמה אזורים, אתם צריכים להגדיר שערים של NAT בכל אזור.
  • רוחב הפס לכל שער יכול להשתנות בהתאם לסוג החומרה. חשוב להביא בחשבון גורמים כמו רוחב הפס המקסימלי של תעבורת הנתונים היוצאת לכל מכונה וירטואלית. במהלך כשל בשער, התנועה מופצת לשערים הנותרים. מכיוון שהזרימות הפעילות לא מתוכנתות מחדש, התנועה לא מתאזנת מחדש באופן מיידי כשהשער חוזר למצב אונליין. לכן, חשוב להקצות מספיק תקורה כשקובעים את הגודל.
  • כדי לקבל התראה על תוצאות לא צפויות, כדאי להשתמש ב-Cloud Monitoring כדי לעקוב אחרי קבוצות המופעים המנוהלות ותנועת הרשת.

הסרת המשאבים

הדרך הקלה ביותר לבטל את החיוב היא למחוק את Cloud de Confiance הפרויקט שיצרתם בשביל המדריך. אפשר גם למחוק את המשאבים בנפרד.

מחיקת הפרויקט

  1. במסוף Cloud de Confiance , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

מחיקת המשאבים הבודדים

אם רוצים לשמור את הפרויקט, אפשר למחוק את המשאבים שיצרתם בשביל המדריך הזה. Cloud de Confiance

  1. מחיקת הקישורים בין רשתות VPC שכנות (peering):

    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. מוחקים את המופעים, את משאבי מאזן העומסים, את התבניות ואת המסלולים:

    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. מוחקים את הכללים של חומת האש, את תת-הרשתות ואת רשתות ה-VPC:

    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

המאמרים הבאים