1. מבוא
Cloud Load Balancing תומך במאזן עומסים של תעבורת נתונים לנקודות קצה (endpoints) שפועלות מחוץ ל-Google Cloud, כמו מרכזי נתונים בארגון ועננים ציבוריים אחרים שאפשר להשתמש בהם בקישוריות היברידית כדי להגיע אליהם.
אסטרטגיה היברידית היא פתרון פרגמטי שיעזור לכם להתאים את האפליקציות שלכם לדרישות השוק המשתנות ולשדרג אותן בהדרגה. יכול להיות שמדובר בפריסה היברידית זמנית שמאפשרת העברה לפתרון מודרני מבוסס-ענן, או ברכיב קבוע בתשתית ה-IT של הארגון.
הגדרת איזון עומסים היברידי מאפשרת גם ליהנות מהיתרונות של יכולות הרשת של Cloud Load Balancing בשירותים שפועלים בתשתית הקיימת שלכם מחוץ ל-Google Cloud.
אם רוצים שהשירות ההיברידי יהיה זמין ברשתות VPC אחרות, אפשר להשתמש ב-Private Service Connect כדי לפרסם את השירות. מיקום קובץ מצורף של שירות לפני מאזן העומסים הפנימי של HTTP(s) מאפשר ללקוחות ברשתות VPC אחרות להגיע ל שירותים היברידיים שפועלים בסביבות ענן מקומיות או אחרות.
מה תפַתחו
בקודלאב הזה תלמדו ליצור מאזן עומסים פנימי מסוג HTTP(S) עם קישוריות היברידית לשירות מקומי באמצעות קבוצת נקודות קצה ברשת. רשת ה-VPC של הצרכן תוכל לתקשר עם השירות המקומי באמצעות יציאות 80. יציאה 443 לא נכללת בהיקף הקודלאב.
מה תלמדו
- איך יוצרים מאזן עומסים פנימי מסוג HTTP(S) עם קצה עורפי של NEG היברידי
- איך ליצור מפיק שירות פרטי (Private Service Connect) (קובץ מצורף לשירות) וצרכן (כלל העברה)
מה צריך להכין
- רשתות היברידיות מבוססות, למשל HA VPN, Interconnect, SW-WAN
- פרויקט ב-Google Cloud
יצירת קישוריות היברידית
צריך לחבר את Google Cloud לסביבות מקומיות או לסביבות ענן אחרות באמצעות קישוריות היברידית, באמצעות צירופי VLAN של Cloud Interconnect או מנהרות Cloud VPN עם Cloud Router. מומלץ להשתמש בחיבור עם זמינות גבוהה.
נתב Cloud Router שמופעל באמצעות ניתוב דינמי גלובלי לומד על נקודת הקצה הספציפית באמצעות BGP ומתכנת אותה ברשת Google Cloud VPC. אין תמיכה בניווט דינמי אזורי. אין גם תמיכה בנתיבים סטטיים.
רשת Google Cloud VPC שבה אתם משתמשים כדי להגדיר את Cloud Interconnect או Cloud VPN היא אותה רשת שבה אתם משתמשים כדי להגדיר את הפריסה של איזון העומסים ההיברידית. יש לוודא שטווחי ה-CIDR של רשת ה-VPC לא מתנגשים עם טווחי ה-CIDR המרוחקים שלכם. כשיש חפיפה בין כתובות IP, נתיבי תת-רשת מקבלים עדיפות על פני קישוריות מרחוק.
להוראות, אפשר לעיין במאמרים הבאים:
מודעות נתיב בהתאמה אישית
רשתות המשנה שבהמשך מחייבות מודעות מותאמות אישית מ-Cloud Router לרשת המקומית, שמבטיחות שכללי חומת האש בארגון מתעדכנים.
רשת משנה | תיאור |
172.16.0.0/23 | תת-רשת של שרת Proxy שמשמש לתקשורת ישירה עם השירות המקומי |
22.130.211.0.0/22, 35.191.0.0/16 |
2. לפני שמתחילים
עדכון הפרויקט כך שיתמוך ב-codelab
ב-Codelab הזה נעשה שימוש במשתני $ כדי לעזור בהטמעת הגדרות gcloud ב-Cloud Shell.
ב-Cloud Shell, מבצעים את הפעולות הבאות:
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab
3. הגדרת המפיק
יצירת VPC של הבעלים של התוכן הדיגיטלי
בתוך Inside Cloud Shell מבצעים את הפעולות הבאות
gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom
יצירת רשתות המשנה של הכלי להפקת חדשות
בתוך Inside Cloud Shell מבצעים את הפעולות הבאות
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 למאזן העומסים הפנימי
Inside Cloud Shell מבצעים את הפעולות הבאות, באמצעות SHARED_VIP אין תמיכה ב-Private Service Connect, צריך להשתמש ב-GCE_ENDPOINT במקום זאת
gcloud compute addresses create lb-ip \
--region=us-central1 \
--subnet=subnet-202 \
--purpose=GCE_ENDPOINT
משתמשים בפקודה לתיאור כתובות המחשוב כדי להציג את כתובת ה-IP שהוקצתה
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
יצירת רשתות המשנה של שרתי proxy אזוריים
הקצאת שרת proxy מתבצעת ברמת ה-VPC ולא ברמת מאזן העומסים. צריך ליצור רשת משנה אחת לשרת proxy בלבד בכל אזור של רשת וירטואלית (VPC) שבה משתמשים במאזני עומסים מבוססי Envoy. אם פורסים כמה מאזני עומסים באותו אזור ובאותה רשת VPC, הם חולקים את אותה רשת משנה של שרת proxy בלבד לאיזון עומסים.
- לקוח יוצר חיבור לכתובת ה-IP וליציאה של כלל ההעברה של מאזן העומסים.
- כל שרת proxy מאזין לכתובת ה-IP וליציאה שצוינו על ידי כלל ההעברה המתאים של מאזן העומסים. אחד מהשרתים הווירטואליים מקבל את החיבור של הלקוח לרשת ומפסיק אותו.
- שרת ה-proxy יוצר חיבור למכונה הווירטואלית או לנקודת הקצה (endpoint) המתאימה בקצה העורפי ב-NEG, כפי שנקבע על ידי מפת ה-URL והשירותים לקצה העורפי של מאזן העומסים.
עליך ליצור רשתות משנה לשרת proxy בלבד, גם אם הרשת שלך היא במצב אוטומטי וגם אם היא מותאמת אישית. תת-רשת של שרת proxy בלבד חייבת לספק 64 כתובות IP או יותר. היא מתאימה לקידומת שמכילה עד 26 תווים. הגודל המומלץ של רשת המשנה הוא /23 (512 כתובות לשרת proxy בלבד).
בתוך Inside Cloud Shell מבצעים את הפעולות הבאות
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
יצירת תת-הרשתות של NAT ב-Private Service Connect
יוצרים רשת משנה ייעודית אחת או יותר לשימוש עם Private Service Connect. אם אתם משתמשים במסוף Google Cloud כדי לפרסם שירות, תוכלו ליצור את תת-הרשתות במהלך התהליך הזה. יוצרים את רשת המשנה באותו אזור שבו נמצא מאזן העומסים של השירות. אי אפשר להמיר תת-רשת רגילה לתת-רשת של Private Service Connect.
ב-Cloud Shell, מבצעים את הפעולות הבאות:
gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect
יצירת כללי חומת האש של הכלי להפקת חדשות
מגדירים כללי חומת אש כדי לאפשר תעבורת נתונים בין נקודות הקצה של Private Service Connect לבין הקובץ המצורף לשירות. ב-Codelab, יצר כלל חומת אש של תעבורת נתונים נכנסת (ingress) שמאפשר לרשת המשנה של NAT 100.100.10.0/24 לגשת לקובץ המצורף לשירות Private Service Connect (מאזן עומסים פנימי).
ב-Cloud Shell, מבצעים את הפעולות הבאות:
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
ב-Cloud Shell, יוצרים את הכלל fw-allow-health-check כדי לאפשר לבדיקות התקינות של Google Cloud להגיע לשירות המקומי (שירות לקצה העורפי) ביציאת ה-TCP 80.
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
יצירת כלל של תעבורת נתונים נכנסת (ingress) שמאפשר לחומת אש עבור רשת המשנה לשרת proxy בלבד, כדי לאפשר למאזן העומסים לתקשר עם מכונות לקצה העורפי ביציאת TCP 80
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
הגדרת ה-NEG של הקישוריות ההיברידית
כשיוצרים את ה-NEG,צריך להשתמש בתחום שמצמצם את המרחק הגיאוגרפי בין Google Cloud לבין סביבת הענן המקומית או סביבת ענן אחרת. לדוגמה, אם אתם מארחים שירות בסביבה מקומית בפרנקפורט שבגרמניה, תוכלו לציין את התחום europe-west3-a במהלך יצירת ה-NEG.
בנוסף, אם אתם משתמשים ב-Cloud Interconnect, ה-ZONE ששימש ליצירת ה-NEG צריך להיות באותו אזור שבו הוגדר הקובץ המצורף Cloud Interconnect.
כדי לראות אילו אזורים ותחומים זמינים, אפשר לעיין במאמרי העזרה של Compute Engine: אזורים ותחומים זמינים.
Inside Cloud Shell יוצרים קישוריות היברידית NEG באמצעות הפקודה gcloud compute network-endpoint-groups create
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
ב-Cloud Shell, מוסיפים את נקודת הקצה IP:Port המקומית ל-NEG ההיברידי.
gcloud compute network-endpoint-groups update on-prem-service-neg \
--zone=us-central1-a \
--add-endpoint="ip=192.168.1.5,port=80"
הגדרת מאזן העומסים
בשלבים הבאים צריך להגדיר את מאזן העומסים (כלל ההעברה) שיוך לקבוצת נקודות הקצה ברשת
יוצרים ב-Cloud Shell את בדיקת התקינות האזורית שמועברת לשירות המקומי
gcloud compute health-checks create http http-health-check \
--region=us-central1 \
--use-serving-port
יוצרים ב-Cloud Shell את השירות לקצה העורפי של קצה העורפי המקומי שמשתמש ב-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
Inside Cloud Shell מוסיפים את הקצה העורפי NEG ההיברידי לשירות לקצה העורפי. בשדה RATE, מזינים את הערך המקסימלי של RATE שמערכת הקצה העורפי צריכה לטפל בו.
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
יוצרים את מפת כתובות ה-URL ב-Cloud Shell כדי לנתב בקשות נכנסות לשירות הקצה העורפי
gcloud compute url-maps create on-prem-svc-url-map \
--default-service on-premise-service-backend \
--region=us-central1
יצירת שרת ה-proxy היעד של HTTP
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
אפשר ליצור כלל העברה כדי לנתב בקשות נכנסות לשרת ה-proxy. אל תשתמשו ברשת המשנה לשרת proxy בלבד כדי ליצור את כלל ההעברה.
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. אימות מאזן העומסים
במסוף Cloud, עוברים אל Network Services → Load Balancing → Load Balancers. שימו לב, ה-NEG 1 הוא 'ירוק' ציון של בדיקת תקינות של השירות במקום
בחירה באפשרות ‘on-premise-svc-url-map' יוצרת את כתובת ה-IP של ממשק הקצה ומזהה את השירות לקצה העורפי
5. הצגת המסלולים שנלמדו מהארגון
עוברים אל VPC Network → Routes. הערה: רשת המשנה של השירות המקומי שנלמדה 192.168.1.0/27
6. אימות הקישוריות לשירות המקומי
מה-VPC של Producers אנחנו ניצור מכונה וירטואלית כדי לבדוק את הקישוריות לשירות המקומי. בסיום ההגדרה הבאה, ה-Service Attachment (קובץ מצורף) יהיה זמין.
יוצרים ב-Cloud Shell את מכונה לבדיקה ב-VPC של הבעלים
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
כדי לאפשר ל-IAP להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש שמאפשר:
- רלוונטי לכל מכונות ה-VM שרוצים לגשת אליהן באמצעות IAP.
- הכלל מאפשר תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP 35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות להעברת TCP באמצעות IAP.
יוצרים את מכונה לבדיקה ב-VPC של הבעלים ב-Cloud Shell
gcloud compute firewall-rules create ssh-iap \
--network producer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
התחברות לתיבת הבדיקה-us-central1 באמצעות IAP ב-Cloud Shell כדי לאמת את הקישוריות לשירות המקומי על ידי ביצוע curl על כתובת ה-IP של מאזן העומסים. אם חלף זמן קצוב לתפוגה, צריך לנסות שוב.
gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap
מבצעים בדיקת קישוריות באמצעות curl לשירות המקומי. אחרי האימות, יוצאים מהמכונה הווירטואלית וחוזרים להנחיה של Cloud Shell. מחליפים את כתובת ה-IP של מאזן העומסים הפנימי על סמך הפלט שזוהה בשלב 4.
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
בשלבים הבאים ניצור את Service Attachment. לאחר ההתאמה עם נקודת קצה של צרכן, תהיה גישה לשירות המקומי בלי צורך בקישור VPC.
יצירת צירוף השירות
יוצרים את הקובץ המצורף לשירות ב-Cloud Shell
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
אופציונלי: אם משתמשים ב-VPC משותף, יוצרים את הצירוף לשירות בפרויקט השירות.
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
gcloud compute service-attachments describe service-1 --region us-central1
אופציונלי: עוברים אל שירותי רשת ← Private Service Connect כדי להציג את הקובץ המצורף לשירות החדש שיצרתם.
אם בוחרים באפשרות Service-1, מקבלים פרטים נוספים, כולל ה-URI של קובץ מצורף לשירות שבו הצרכן משתמש כדי ליצור חיבור לשירות פרטי. חשוב לשים לב למזהה ה-URI כי תצטרכו להשתמש בו בשלב מאוחר יותר.
פרטי הצירוף לשירות: projects/<projectname>/regions/us-central1/serviceAttachments/service-1
8. הגדרת הצרכן
יצירת ה-VPC לצרכנים
בתוך Inside Cloud Shell מבצעים את הפעולות הבאות
gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom
יצירת רשתות המשנה לצרכנים
יצירת רשת משנה של GCE באמצעות Inside Cloud Shell
gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1
יצירת רשת משנה של נקודת קצה (endpoint) לצרכנים באמצעות Inside Cloud Shell
gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1
יצירת נקודת הקצה לצרכנים (כלל העברה)
יוצרים ב-Inside Cloud Shell את כתובת ה-IP הסטטית שתשמש כנקודת קצה (endpoint) של צרכנים
gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10
נשתמש במזהה ה-URI של Service Attachment שנוצר קודם כדי ליצור את נקודת הקצה של הצרכן.
יוצרים את נקודת הקצה של הצרכן ב-Cloud Shell
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. אימות הקישור לשירות הפרטי של הצרכן – VPC של הצרכן
מה-VPC של הצרכן מאמתים חיבורים מוצלחים לשירות Private Service על ידי מעבר אל שירותי רשת ← Private Service Connect ← נקודות קצה מחוברות. יש לשים לב לחיבור psc-consumer-1 ולכתובת ה-IP המתאימה שיצרנו קודם.
כשבוחרים ב-psc-consumer-1, מוצגים פרטים כולל ה-URI של צירוף השירות
10. אימות Private Service Connect של צרכן – VPC של הבעלים
ב-VPC של הבעלים, מוודאים שהחיבור ל-Private Service Connect הצליח. עוברים אל Network Services → Private Service Connect → Published Service. לתשומת ליבכם, חיבור service-1 שפורסם מציין עכשיו כלל העברה אחד (נקודת קצה של חיבור).
11. יצירת אזור DNS פרטי רשומת A
יוצרים את תחום ה-DNS הפרטי שממופה לנקודת הקצה של חיבור ה-PSC, ומאפשר גישה חלקה ל-Producer מכל מארח ב-VPC.
מ-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. אימות הגישה של צרכנים לשירות המפיקים באמצעות VM
מה-VPC של הצרכנים ניצור מכונה וירטואלית כדי לבדוק את הקישוריות לשירות המקומי באמצעות גישה לנקודת הקצה לצרכנים service1.codelabs.net
Inside Cloud Shell יוצרים את מכונת הבדיקה ב-vpc לצרכנים
gcloud compute instances create consumer-vm \
--zone=us-central1-a \
--image-family=debian-10 \
--image-project=debian-cloud \
--subnet=subnet-101 \
--no-address
כדי לאפשר ל-IAP להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש שמאפשר:
- רלוונטי לכל מכונות ה-VM שרוצים לגשת אליהן באמצעות IAP.
- תעבורת נתונים נכנסת (ingress) מטווח ה-IP 35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות להעברת TCP באמצעות IAP.
Inside Cloud Shell יוצרים את מכונת הבדיקה ב-vpc לצרכנים
gcloud compute firewall-rules create ssh-iap-consumer \
--network consumer-vpc \
--allow tcp:22 \
--source-ranges=35.235.240.0/20
מתחברים למכונה הווירטואלית של הצרכן באמצעות IAP ב-Cloud Shell כדי לאמת את החיבור לשירות המקומי. לשם כך, מבצעים קריאה ל-curl נגד כתובת ה-FQDN של ה-DNS service1.codelab.net. אם חל תוקף זמן קצוב, מנסים שוב.
gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap
מבצעים אימות curl לאימות קישוריות לשירות המקומי. לאחר האימות, היציאה מה-VM וחזרה להנחיה של Cloud Shell
ביצוע הפקודה curl ב-Cloud Shell
$ 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!!
למטה מוצגת דוגמה לתיעוד של השירות המקומי. שימו לב שכתובת ה-IP של המקור 172.16.0.13 היא מטווח רשת המשנה של שרת ה-proxy 172.16.0.0/23
13. ניקוי נתונים מהמפיק
מחיקת רכיבים של יוצרים
מחיקת המכונות לבדיקה ב-Producer VPC בעזרת Inside Cloud Shell נמחקת
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. ניקוי נתונים לצרכנים
מחיקת רכיבי צרכן
מחיקת המכונות לבדיקה ב-VPC של הצרכן בעזרת Inside Cloud Shell
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. מזל טוב
סיימתם להגדיר ולאמת את Private Service Connect עם מאזן עומסים פנימי מסוג HTTP(S).
יצרתם את התשתית של היצרן, והוספתם קובץ מצורף של שירות ב-VPC של היצרן שמפנה לשירות מקומי. למדתם איך ליצור נקודת קצה לצרכנים ב-VPC לצרכן שאפשרה קישוריות לשירות בארגון.
מה השלב הבא?
כדאי לעיין בחלק מהקורסים האלה ב-Codelab…
- שימוש ב-Private Service לפרסום ולצריכה של שירותים באמצעות GKE
- שימוש ב-Private Service Connect כדי לפרסם ולצרוך שירותים
- התחברות לשירותים מקומיים באמצעות Networking היברידי באמצעות Private Service Connect ומאזן עומסים פנימי של TCP Proxy