התחברות לשירותים מקומיים בארגון באמצעות Networking היברידי באמצעות Private Service Connect ו-Hybrid NEG TCP Proxy

1. מבוא

מאזן עומסים פנימי אזורי של שרת proxy מסוג TCP עם קישוריות היברידית מאפשר לכם להנגיש ללקוחות ברשת ה-VPC שירות שמארח בסביבות מקומיות או בסביבות ענן אחרות.

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

מה תפַתחו

ב-Codelab הזה תיצרו מאזן עומסים (LB) פנימי מסוג TCP Proxy עם קישוריות היברידית לשירות מקומי באמצעות קבוצת נקודות קצה ברשת. מ-VPC של הצרכן תהיה אפשרות לתקשר עם השירות המקומי.

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

מה תלמדו

• איך יוצרים TCP Proxy ILB עם שירות קצה עורפי של Hybrid NEG
• איך יוצרים בעלים של שירות מנוהל (קובץ מצורף עם השירות) וצרכן (כלל העברה) ב-Private Service Connect
• איך בודקים ומאמתים את התקשורת בין צרכן לבעלים של שירות מנוהל

הערה: ה-Codelab הזה מתמקד בהטמעה של TCP Proxy ILB עם 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	רשת משנה של TCP Proxy שמשמשת לתקשורת ישירה עם השירות המקומי
‫130.211.0.0/22, ‏ 35.191.0.0/16	בדיקת תקינות של Google Cloud

‫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. הגדרת 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

יצירת תת-רשתות של שרת proxy ל-TCP

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

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

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

הערה: רשת המשנה של ה-Proxy דורשת פרסום BGP של הלקוח ל-On-premise, ולכן ניתן לניתוב לרשת ה-On-premise שלכם. הגישה לשירות מתאפשרת דרך רשת המשנה של ה-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, יצרתם כלל חומת אש לתעבורת נתונים נכנסת שמאפשר לתת-רשת NAT ‏100.100.10.0/24 גישה ל-Service Attachment של 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

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

בנוסף, אם אתם משתמשים ב-Cloud Interconnect, האזור שבו השתמשתם כדי ליצור את קבוצת ה-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 tcp on-prem-service-hc \
    --region=us-central1 \
    --use-serving-port

ב-Cloud Shell, יוצרים את שירות הלקצה העורפי ל-Backend המקומי.

gcloud compute backend-services create on-premise-service-backend \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=TCP \
   --region=us-central1 \
   --health-checks=on-prem-service-hc \
   --health-checks-region=us-central1

ב-Cloud Shell, מוסיפים את הקצה העורפי של ה-NEG ההיברידי לשירות הקצה העורפי. בשדה MAX_CONNECTIONS, מזינים את המספר המקסימלי של חיבורים בו-זמניים שהקצה העורפי צריך לטפל בהם.

gcloud compute backend-services add-backend on-premise-service-backend \
   --network-endpoint-group=on-prem-service-neg \
   --network-endpoint-group-zone=us-central1-a \
   --region=us-central1 \
   --balancing-mode=CONNECTION \
   --max-connections=100

ב-Cloud Shell, יוצרים את שרת ה-Proxy ליעד.

gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
   --backend-service=on-premise-service-backend \
   --region=us-central1

בתוך Cloud Shell, יוצרים את כלל ההעברה (ILB).

יוצרים את כלל ההעברה באמצעות הפקודה gcloud compute forwarding-rules create.

מחליפים את FWD_RULE_PORT במספר יציאה יחיד בין 1 ל-65535. כלל ההעברה מעביר רק מנות עם יציאת יעד תואמת.

gcloud compute forwarding-rules create tcp-ilb-psc \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network=producer-vpc \
   --subnet=subnet-201 \
   --ports=80 \
   --region=us-central1 \
   --target-tcp-proxy=on-premise-svc-tcpproxy \
   --target-tcp-proxy-region=us-central1

קבלת כתובת ה-IP של מאזן העומסים הפנימי

gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:

Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2

4. אימות מאזן העומסים

במסוף Cloud, עוברים אל Network Services → Load Balancing → Load Balancers. שימו לב, ה-NEG‏ 1 הוא 'ירוק', מה שמצביע על בדיקת תקינות מוצלחת בשירות המקומי

בחירה באפשרות ‘on-premise-service-backend' מציגה את כתובת ה-IP של חזית האתר

5. צפייה במסלולים שנלמדו מתוך השרת המקומי

עוברים אל VPC Network → Routes. שימו לב, תת-הרשת של שירות מקומי שנלמדה היא 192.168.1.0/27

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

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

בתוך 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.
• מאפשר תנועה נכנסת מטווח כתובות ה-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 של מאזן העומסים הפנימי על סמך הפלט שזוהה בשלבים 3 ו-4.

deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
*   Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.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, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
< 
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=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

אופציונלי: אם משתמשים ב-VPC משותף, יוצרים את קובץ השירות בפרויקט השירות

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

אימות של קובץ מצורף לשירות TCP

gcloud compute service-attachments describe service-1 --region us-central1

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

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

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

9. הגדרת צרכן

יצירת 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

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

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

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

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

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

12. יצירת שרת 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"

13. אימות הגישה של הצרכן לשירות של הספק באמצעות מכונת VM

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

14. ניקוי של מפיק

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

ב-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 tcp-ilb-psc --region=us-central1 --quiet

gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --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 networks subnets delete psc-nat-subnet subnet-201 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 on-prem-service-hc --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

15. ניקוי נתונים של צרכנים

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

ב-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 

16. מזל טוב

סיימתם להגדיר ולאמת את Private Service Connect עם TCP Proxy.

יצרתם את התשתית של בעל השירות והוספתם קובץ מצורף של שירות ב-VPC של בעל השירות שמפנה לשירות מקומי. למדתם איך ליצור נקודת קצה של צרכן ב-VPC של הצרכן, שמאפשרת קישור לשירות המקומי.

מה השלב הבא?

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

• שימוש בשירות פרטי לפרסום ולצריכה של שירותים ב-GKE
• שימוש ב-Private Service Connect לפרסום ולצריכה של שירותים

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

• סקירה כללית על Private Service Connect
• מה זה Private Service Connect?

מאמרי עזרה

• שרת proxy פנימי ל-TCP
• סקירה כללית על בדיקות תקינות
• איך מפרסמים שירות