התחברות לשירותים מקומיים בארגון באמצעות Networking היברידי באמצעות Private Service Connect ו-Hybrid NEG עם מאזן עומסים פנימי של HTTP(s)

1. מבוא

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

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

הגדרת איזון עומסים היברידי מאפשרת לכם גם ליהנות מהיתרונות של יכולות הרשת של Cloud Load Balancing בשירותים שפועלים בתשתית הקיימת שלכם מחוץ ל-Google Cloud.

אם רוצים להפוך את השירות ההיברידי לזמין ברשתות VPC אחרות, אפשר להשתמש ב-Private Service Connect כדי לפרסם את השירות. אם מציבים שירות מצורף לפני מאזן העומסים הפנימי האזורי HTTP(s),לקוחות ברשתות VPC אחרות יכולים לגשת ל שירותים היברידיים שפועלים בסביבות מקומיות או בסביבות ענן אחרות.

מה תפַתחו

ב-codelab הזה תבנו מאזן עומסים פנימי של HTTP(S) עם קישוריות היברידית לשירות מקומי באמצעות Network Endpoint Group (קבוצת נקודות קצה ברשת). רשת ה-VPC של הצרכן תוכל לתקשר עם השירות המקומי באמצעות יציאה 80. יציאה 443 לא נכללת בהיקף ה-codelab הזה.

הערה: ב-Codelab מוצעים שלבי הגדרה ואימות שמבוססים על הטופולוגיה שמוצגת באיור. אפשר לשנות את התהליך לפי הצורך כדי להתאים אותו לדרישות של הארגון. הרשאות IAM לא נכללות בהיקף של ה-codelab.

מה תלמדו

• איך יוצרים מאזן עומסים פנימי מסוג HTTP(S) עם קצה עורפי של NEG היברידי
• איך יוצרים בעלים של שירות מנוהל (קובץ מצורף עם השירות) וצרכן (כלל העברה) ב-Private Service Connect

הערה: ה-Codelab הזה מתמקד בהטמעה של מאזן עומסים פנימי מסוג HTTP(S) עם PSC. אין תיעוד של הגדרת רשת היברידית, אבל אנחנו מספקים מסמכי תמיכה וצילומי מסך.

מה תצטרכו

• רישות היברידי מבוסס, למשל HA VPN,‏ Interconnect,‏ SW-WAN
• פרויקט ב-Google Cloud

יצירת קישוריות היברידית

סביבות Google Cloud והסביבות המקומיות או סביבות ענן אחרות צריכות להיות מחוברות באמצעות קישוריות היברידית, באמצעות צירופי VLAN של Cloud Interconnect או מנהרות Cloud VPN עם Cloud Router. מומלץ להשתמש בחיבור עם זמינות גבוהה.

‫Cloud Router שמופעל בו ניתוב דינמי גלובלי לומד על נקודת הקצה הספציפית באמצעות BGP ומתכנת אותה ברשת ה-VPC של Google Cloud. ניתוב דינמי אזורי אינו נתמך. אין תמיכה גם בניתוב סטטי.

רשת ה-VPC ב-Google Cloud שבה אתם משתמשים כדי להגדיר את Cloud Interconnect או את Cloud VPN היא אותה רשת שבה אתם משתמשים כדי להגדיר את פריסת איזון העומסים ההיברידי. מוודאים שטווח ה-CIDR של רשתות המשנה של רשת ה-VPC לא מתנגש עם טווחי ה-CIDR המרוחקים. כשכתובות IP חופפות, נתיבי רשת משנה מקבלים עדיפות על פני קישוריות מרחוק.

הוראות מפורטות במאמרים הבאים:

• מסמכי תיעוד של Cloud VPN
• מסמכי תיעוד של Cloud Interconnect

פרסום של מסלולים בהתאמה אישית

תת-רשתות שמופיעות מתחת ל- require custom advertisements מ-Cloud Router לרשת המקומית, כדי לוודא שכללי חומת האש המקומית מתעדכנים.

תת-רשת	תיאור
172.16.0.0/23	רשת משנה של שרת proxy שמשמשת לתקשורת ישירה עם השירות המקומי
‫130.211.0.0/22, ‏ 35.191.0.0/16	בדיקת תקינות של Google Cloud

‫2. לפני שמתחילים

עדכון הפרויקט כדי לתמוך ב-codelab

ב-Codelab הזה נעשה שימוש במשתנים (‎ $variables) כדי להקל על הטמעת ההגדרה של gcloud ב-Cloud Shell.

בתוך Cloud Shell, מבצעים את הפעולות הבאות:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. הגדרת Producer

יצירת VPC של Producer

בתוך Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

יצירת רשתות המשנה של Producer

בתוך 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 למאזן עומסים פנימי

ב-Cloud Shell, מבצעים את הפעולות הבאות. אי אפשר להשתמש ב-SHARED_VIP עם Private Service Connect, לכן צריך להשתמש ב-GCE_ENDPOINT במקום.

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

משתמשים בפקודה compute addresses describe כדי לראות את כתובת ה-IP שהוקצתה.

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

יצירת תת-רשתות של שרת proxy אזורי

הקצאת שרת proxy היא ברמת ה-VPC, ולא ברמת מאזן העומסים. צריך ליצור תת-רשת לשרתי proxy בלבד בכל אזור של רשת וירטואלית (VPC) שבה משתמשים במאזני עומסים מבוססי Envoy. אם פורסים כמה מאזני עומסים באותו אזור ובאותה רשת VPC, הם חולקים את אותה רשת משנה של פרוקסי בלבד לאיזון עומסים.

1. לקוח יוצר חיבור לכתובת ה-IP ולפורט של כלל ההעברה של מאזן העומסים.
2. כל שרת proxy מאזין לכתובת ה-IP ולפורט שצוינו בכלל ההעברה של מאזן העומסים המתאים. אחד משרתי ה-proxy מקבל את חיבור הרשת של הלקוח ומסיים אותו.
3. ה-proxy יוצר חיבור למכונה וירטואלית או לנקודת קצה (endpoint) מתאימה ב-NEG, כפי שנקבע על ידי מפת ה-URL ושירותי הקצה העורפי של מאזן העומסים (LB).

אתם חייבים ליצור רשתות משנה לשרתי proxy בלבד, בלי קשר למצב הרשת (אוטומטי או מותאם אישית). תת-רשת של שרת proxy בלבד צריכה לספק 64 כתובות IP או יותר. המשמעות היא שאורך הקידומת הוא ‎ /26 או קצר יותר. גודל רשת המשנה המומלץ הוא ‎ /23 (512 כתובות של שרת proxy בלבד).

הערה: רשת המשנה של ה-proxy בלבד דורשת פרסום BGP של הלקוח למיקום המקומי, ולכן ניתן לנתב אותה לרשת המקומית. הגישה לשירות מתאפשרת באמצעות רשת המשנה של ה-proxy שסופקה.

בתוך 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 בלבד, כדי לאפשר למאזן העומסים לתקשר עם שרתים עורפיים (backend instance) ביציאה 80 ב-TCP

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 לבין הסביבה המקומית או סביבת ענן אחרת. לדוגמה, אם אתם מארחים שירות בסביבה מקומית בפרנקפורט, גרמניה, אתם יכולים לציין את אזור Google Cloud‏ europe-west3-a כשאתם יוצרים את ה-NEG.

בנוסף, אם אתם משתמשים ב-Cloud Interconnect, התחום (zone) שבו השתמשתם כדי ליצור את קבוצת ה-NEG צריך להיות באותו אזור שבו הגדרתם את צירוף ה-Cloud Interconnect.

רשימה של האזורים והתחומים הזמינים מופיעה במאמר בנושא אזורים ותחומים ב-Compute Engine.

ב-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:יציאה המקומית ל-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, יוצרים את שירות הקצה העורפי עבור הקצה העורפי המקומי באמצעות Hybrid 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

ב-Cloud Shell, מוסיפים את הקצה העורפי של ה-NEG ההיברידי לשירות הקצה העורפי. בשדה 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

ב-Cloud Shell, יוצרים את מפת ה-URL כדי לנתב בקשות נכנסות לשירות הקצה העורפי

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 (רשת VPC → מסלולים). שימו לב, תת-הרשת של השירות המקומי שנלמדה היא 192.168.1.0/27

6. אימות הקישוריות לשירות המקומי

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

בתוך Cloud Shell, יוצרים את מכונת הבדיקה ב-VPC של היצרן

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

מתחברים אל test-box-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

בשלבים הבאים ניצור את קובץ השירות המצורף. אחרי הקישור לנקודת הקצה של הצרכן, תהיה גישה לשירות המקומי בלי צורך בקישור בין רשתות שכנות (peering) של 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 משותף, צריך ליצור את קובץ ה-Service Attachment בפרויקט השירות

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

אופציונלי: עוברים אל Network Services → Private Service Connect כדי לראות את קובץ מצורף עם השירות החדש שנוצר.

אם בוחרים באפשרות Service-1, מוצגים פרטים נוספים, כולל ה-URI של קובץ מצורף עם השירות שבו השתמש הצרכן כדי ליצור חיבור פרטי לשירות. חשוב לשים לב ל-URI כי תצטרכו להשתמש בו בשלב מאוחר יותר.

פרטים של קובץ השירות: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. הגדרת צרכן

יצירת VPC של צרכן

בתוך Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

יצירת רשתות המשנה של הצרכנים

בתוך Cloud Shell, יוצרים את רשת המשנה של GCE.

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

בתוך Cloud Shell, יוצרים את תת-הרשת של נקודת הקצה של הצרכן

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

יצירת נקודת קצה לצרכן (כלל העברה)

ב-Cloud Shell, יוצרים את כתובת ה-IP הסטטית שתשמש כנקודת קצה של צרכן.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

נשתמש במזהה ה-URI של קובץ השירות שנוצר קודם כדי ליצור את נקודת הקצה לצרכן

בתוך 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. אימות של Private Service Connect לצרכן – VPC של הצרכן

ברשת ה-VPC של הצרכן, עוברים אל Network Services → Private Service Connect→ Connected Endpoints כדי לוודא שנוצר חיבור פרטי. שימו לב לחיבור psc-consumer-1 שנוצר ולכתובת ה-IP התואמת שיצרנו קודם.

כשבוחרים את psc-consumer-1, מוצגים פרטים כולל ה-URI של Service Attachment.

10. אימות של Private Service Connect לצרכן – VPC של יצרן

ברשת ה-VPC של ספק השירות, עוברים אל Network Services → Private Service Connect→Published Service כדי לוודא שנוצר חיבור פרטי לשירות. שימו לב שהחיבור שפורסם service-1 מציין עכשיו כלל העברה אחד (נקודת קצה של חיבור).

11. יצירת שרת DNS פרטי ורשומת A

יוצרים את אזור ה-DNS הפרטי שממופה לנקודת הקצה של חיבור ה-PSC, כדי לאפשר גישה חלקה לבעלים של השירות המנוהל מכל מארח ב-VPC.

הערה: אין תמיכה בגישה לנקודת קצה של צרכן באמצעות VPC peering

מ-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 של הצרכנים ניצור VM כדי לבדוק את הקישוריות לשירות המקומי על ידי גישה לנקודת הקצה של הצרכן service1.codelabs.net

ב-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 שמשמשות את IAP להעברת TCP.

ב-Cloud Shell, יוצרים את מכונת הבדיקה ב-VPC של הלקוח

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

מתחברים אל consumer-vm באמצעות 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

מחיקת רכיבים של Producer

ב-Cloud Shell, מוחקים את מכונות הבדיקה ב-VPC של ה-Producer

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. ניקוי נתונים של צרכנים

מחיקת רכיבים של Consumer

ב-Cloud Shell, מוחקים את מכונות הבדיקה ב-VPC של הצרכן

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 של הצרכן, שמאפשרת קישוריות לשירות המקומי.

מה השלב הבא?

כדאי לעיין ב-Codelabs הבאים…

• שימוש בשירות פרטי לפרסום ולצריכה של שירותים ב-GKE
• שימוש ב-Private Service Connect לפרסום ולצריכה של שירותים
• התחברות לשירותים מקומיים דרך רשת היברידית באמצעות Private Service Connect ומאזן עומסים פנימי של TCP Proxy

קריאה נוספת וסרטונים

• סקירה כללית על Private Service Connect
• מה זה Private Service Connect?
• סוגים נתמכים של מאזני עומסים

מאמרי עזרה

• סקירה כללית של מאזן עומסים פנימי מסוג HTTP(S)
• סקירה כללית על בדיקות תקינות
• איך מפרסמים שירות באמצעות Private Service Connect