הגדרה של מאזן עומסים פנימי אזורי של אפליקציות (ALB) עם קטגוריות של Cloud Storage

במאמר הזה מוסבר איך ליצורregional internal Application Load Balancer כדי להפנות בקשות לתוכן סטטי אל קטגוריות של Cloud Storage.

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

חשוב לוודא שההגדרה עומדת בדרישות המוקדמות הבאות.

התקנת Google Cloud CLI

חלק מההוראות במדריך הזה אפשר לבצע רק באמצעות ה-CLI של gcloud. הוראות להתקנה מפורטות במאמר התקנת Google Cloud CLI.

אפשר למצוא פקודות שקשורות לאיזון עומסים במסמך הפניות ל-API ול-CLI של gcloud.

התפקידים הנדרשים

אם אתם יוצרי הפרויקט, מוקצה לכם התפקיד 'בעלים' (roles/owner). כברירת מחדל, התפקיד 'בעלים' (roles/owner) או התפקיד 'עריכה' (roles/editor) כוללים את ההרשאות שנדרשות כדי לבצע את הפעולות שמתוארות במאמר הזה.

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

כדי לקבל את ההרשאות שדרושות ליצירת קטגוריות של Cloud Storage ומשאבי רשת, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

• יצירת רשתות, רשתות משנה ורכיבים של מאזן עומסים: אדמין של רשת מחשוב (roles/compute.networkAdmin)
• להוסיף ולמחוק כללי חומת אש: אדמין לענייני אבטחה ב-Compute (roles/compute.securityAdmin)
• יצירת קטגוריות של Cloud Storage: אדמין של אובייקטים באחסון (roles/storage.objectAdmin)

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

יכול להיות שאפשר לקבל את ההרשאות הנדרשות גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש.

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

הגדרת משאב של אישור SSL

אם regional internal Application Load Balancer משתמש בפרוטוקול HTTPS כפרוטוקול הבקשות והתשובות, צריך ליצור משאב של אישור SSL באמצעות Certificate Manager, כמו שמתואר באחד מהמסמכים הבאים:

• פריסת אישור אזורי שמנוהל על ידי Google ומונפק על ידי מופע של שירות CA
• פריסת אישור אזורי שמנוהל על ידי Google עם הרשאת DNS
• פריסת אישור אזורי בניהול עצמי

אחרי שיוצרים את האישור, אפשר לצרף אותו לשרת proxy של יעד HTTPS.

מומלץ להשתמש באישור שמנוהל על ידי Google.

מגבלות

המגבלות הבאות חלות על קטגוריות של Cloud Storage כשמשתמשים בהן כבקאנד ל- regional internal Application Load Balancer:

• אין תמיכה בגישה לקטגוריות פרטיות, ולכן צריך שתהיה גישה ציבורית לקטגוריית קצה עורפי דרך האינטרנט.

• אי אפשר להשתמש בכתובות URL חתומות.

• אי אפשר לשלב את Cloud CDN כשיוצרים קטגוריות קצה עורפיות עבורregional internal Application Load Balancer.

• כשמשתמשים ב- regional internal Application Load Balancer כדי לגשת לדליים של קצה עורפי, רק שיטת ה-HTTP GET נתמכת. אפשר להוריד תוכן מהמאגר, אבל אי אפשר להעלות תוכן למאגר דרךregional internal Application Load Balancer .

• ב- regional internal Application Load Balancer, קטגוריות של Cloud Storage נתמכות רק באזור שבו מאזן העומסים מוגדר. אין תמיכה בקטגוריות בשני אזורים או במספר אזורים.

סקירה כללית של ההגדרה

אפשר להגדיר את regional internal Application Load Balancer באזור מסוים כמו שמוצג בדיאגרמת הארכיטקטורה הבאה:

חלוקת התנועה ל-Cloud Storage (לחצו כדי להגדיל).

כפי שמוצג בדיאגרמת הארכיטקטורה, בדוגמה הזו נוצרregional internal Application Load Balancer ברשת VPC עם שתי קטגוריות קצה עורפי, כאשר כל קטגוריית קצה עורפי מפנה לקטגוריה של Cloud Storage. הקטגוריות של Cloud Storage ממוקמות באזור us-east1, ואפשר לאזן את עומס התנועה בין כל הקטגוריות.

הגדרת הרשת ורשתות המשנה

ברשת ה-VPC, מגדירים רשת משנה באזור us-east1 שבו יוגדר כלל ההעברה של מאזני העומסים. בנוסף, צריך להגדיר תת-רשת של שרת proxy בלבד באזור us-east1 שבו רוצים להגדיר את מאזן העומסים.

בדוגמה הזו נעשה שימוש ברשת ה-VPC, באזור ובתת-רשתות הבאים:

• רשת. הרשת היא רשת VPC במצב מותאם אישית בשם lb-network.

• תת-רשת למאזן העומסים. רשת משנה בשם subnet-us באזור us-east1 משתמשת ב-10.1.2.0/24 כטווח ה-IP הראשי שלה.

• תת-רשת ל-Envoy proxy. רשת משנה בשם proxy-only-subnet-us באזור us-east1 שמשתמשת ב-10.129.0.0/23 כטווח ה-IP הראשי שלה.

הגדרת רשתות המשנה לכלל ההעברה של מאזן העומסים

יוצרים רשת משנה באותו אזור שבו רוצים להגדיר את כלל ההעברה של מאזני העומסים.

המסוף

1. נכנסים לדף VPC networks במסוף Google Cloud .

   מעבר לרשתות VPC

2. לוחצים על יצירת רשת VPC.

3. בשדה Name (שם), מזינים lb-network.

4. בקטע רשתות משנה, מגדירים את מצב יצירת רשתות משנה למותאם אישית.

5. בקטע New subnet, מזינים את הפרטים הבאים:

   1. Name (שם): subnet-us
   2. בוחרים אזור: us-east1
   3. טווח כתובות IP: 10.1.2.0/24
   4. לוחצים על סיום.

6. לוחצים על יצירה.

gcloud

1. יוצרים רשת VPC מותאמת אישית בשם lb-network באמצעות הפקודה gcloud compute networks create.

   gcloud compute networks create lb-network --subnet-mode=custom
   

2. יוצרים תת-רשת ברשת ה-VPC‏ lb-network באזור us-east1 באמצעות הפקודה gcloud compute networks subnets create.

   gcloud compute networks subnets create subnet-us \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-east1
   

הגדרת רשתות משנה ל-proxy בלבד

תת-רשת של פרוקסי בלבד מספקת קבוצה של כתובות IP ש- Google Cloud משתמש בהן כדי להפעיל פרוקסי של Envoy בשמכם. הפרוקסיים מסיימים את החיבורים מהלקוח ויוצרים חיבורים לשרתי הקצה.

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

חשוב: אל תנסו להקצות כתובות מרשת המשנה של ה-proxy בלבד לכלל ההעברה או לעורפי של איזון העומסים. הקציתם את כתובת ה-IP של כלל ההעברה ואת כתובות ה-IP של מופעי ה-Backend מטווח (או טווחים) אחר של רשתות משנה, ולא מטווח הרשתות הזה.Google Cloud טווח הרשתות הזה שמור לפרוקסי שמנוהל על ידי Google Cloud.

המסוף

1. נכנסים לדף VPC networks במסוף Google Cloud .

   מעבר לרשתות VPC

2. לוחצים על השם של רשת ה-VPC שיצרתם.

3. בכרטיסייה Subnet, לוחצים על Add subnet.

4. הזן את פריטי המידע הבאים:

   1. בשדה Name (שם), מזינים proxy-only-subnet-us.
   2. בשדה Region (אזור), מזינים us-east1.
   3. בשדה מטרה, בוחרים באפשרות Regional Managed Proxy.
   4. בשדה טווח כתובות IP, מזינים 10.129.0.0/23.

5. לוחצים על הוספה.

gcloud

• יוצרים תת-רשת לשרת proxy בלבד באזור us-east1 באמצעות הפקודה gcloud compute networks subnets create.

  gcloud compute networks subnets create proxy-only-subnet-us \
      --purpose=REGIONAL_MANAGED_PROXY \
      --role=ACTIVE \
      --region=us-east1 \
      --network=lb-network \
      --range=10.129.0.0/23
  

הגדרת כלל לחומת האש

בדוגמה הזו נעשה שימוש בכלל חומת אש לתעבורה נכנסת, fw-allow-ssh, שמאפשר גישת SSH ביציאה 22 למכונה הווירטואלית של הלקוח.

המסוף

1. נכנסים לדף Firewall policies במסוף Google Cloud .

   לדף Firewall policies

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

3. בדף Create a firewall rule (יצירת כלל לחומת האש), מזינים את הפרטים הבאים:

   1. Name (שם): fw-allow-ssh
   2. רשת: lb-network
   3. כיוון התנועה: כניסה
   4. פעולה במקרה של התאמה: אישור
   5. יעדים: תגי יעד שצוינו
   6. תגי טירגוט: allow-ssh
   7. מסנן מקור: טווחים של כתובות IPv4
   8. טווחי IPv4 של המקור: 0.0.0.0/0
   9. פרוטוקולים ויציאות:
      1. בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
      2. מסמנים את תיבת הסימון TCP ומזינים 22 כמספר היציאה.

4. לוחצים על יצירה.

gcloud

• יוצרים את כלל חומת האש fw-allow-ssh כדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשת allow-ssh. אם לא מציינים את --source-ranges, Google Cloud הכלל יפורש כאילו הוא מתייחס לכל מקור.

  gcloud compute firewall-rules create fw-allow-ssh \
      --network=lb-network \
      --action=allow \
      --direction=ingress \
      --target-tags=allow-ssh \
      --rules=tcp:22
  

הגדרת קטגוריות של Cloud Storage

תהליך ההגדרה של קטגוריות Cloud Storage הוא כדלקמן:

1. יוצרים את הקטגוריות.
2. מעתיקים את התוכן לקטגוריות.
3. הגדרת הקטגוריות כקריאות באופן ציבורי.

יצירת קטגוריות ב-Cloud Storage

בדוגמה הזו, יוצרים שתי קטגוריות של Cloud Storage באזור us-east1.

המסוף

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. לוחצים על יצירה.

3. בקטע Get started (תחילת העבודה), מזינים שם ייחודי גלובלית שעומד בהנחיות למתן שמות.

4. לוחצים על Choose where to store your data (בחירת המיקום לאחסון הנתונים).

5. מגדירים את סוג המיקום לאזור.

6. ברשימת האזורים, בוחרים באפשרות us-east1.

7. לוחצים על יצירה.

8. לוחצים על Buckets כדי לחזור לדף Cloud Storage Buckets. פועלים לפי ההוראות הקודמות כדי ליצור קטגוריה שנייה באותו אזור, us-east1.

gcloud

• יוצרים את הקטגוריות באזור us-east1 באמצעות הפקודה gcloud storage buckets create.

  gcloud storage buckets create gs://BUCKET1_NAME \
      --default-storage-class=standard \
      --location=us-east1 \
      --uniform-bucket-level-access
  

  gcloud storage buckets create gs://BUCKET2_NAME \
      --default-storage-class=standard \
      --location=us-east1 \
      --uniform-bucket-level-access
  

  מחליפים את BUCKET1_NAME ואת BUCKET2_NAME בשמות של הקטגוריות שלכם ב-Cloud Storage.

העתקת קובצי גרפיקה לקטגוריות של Cloud Storage

כדי שתוכלו לבדוק את ההגדרה, צריך להעתיק קובץ גרפי מקטגוריה ציבורית של Cloud Storage לקטגוריות שלכם ב-Cloud Storage.

gcloud storage cp gs://gcp-external-http-lb-with-bucket/three-cats.jpg gs://BUCKET1_NAME/love-to-purr/

gcloud storage cp gs://gcp-external-http-lb-with-bucket/two-dogs.jpg gs://BUCKET2_NAME/love-to-fetch/

הגדרת קטגוריות של Cloud Storage כקריאות באופן ציבורי

כדי שכל האובייקטים בקטגוריה יהיו קריאים לכולם באינטרנט הציבורי, צריך להעניק לחשבון הראשי allUsers את התפקיד 'צפייה באובייקט אחסון' (roles/storage.objectViewer).

המסוף

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

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.
   

   כניסה לדף Buckets

2. ברשימת הקטגוריות, מסמנים את התיבה לצד כל קטגוריה שרוצים להגדיר כציבורית.

3. לוחצים על הלחצן Permissions (הרשאות). מופיעה תיבת הדו-שיח Permissions.

4. בתיבת הדו-שיח Permissions, לוחצים על הלחצן Add principal. מופיעה תיבת הדו-שיח Grant access.

5. בשדה New principals, מזינים allUsers.

6. בשדה Select a role, מזינים Storage Object Viewer בתיבת הסינון ובוחרים Storage Object Viewer מהתוצאות המסוננות.

7. לוחצים על Save.

8. לוחצים על Allow public access.

gcloud

כדי להעניק לכל המשתמשים גישה לצפייה באובייקטים בקטגוריות, מריצים את הפקודה buckets add-iam-policy-binding.

gcloud storage buckets add-iam-policy-binding gs://BUCKET1_NAME \
    --member=allUsers \
    --role=roles/storage.objectViewer

gcloud storage buckets add-iam-policy-binding gs://BUCKET2_NAME \
    --member=allUsers \
    --role=roles/storage.objectViewer

שמירת כתובת IP פנימית סטטית

שמירת כתובת IPv4 פנימית סטטית לכלל ההעברה של מאזן העומסים. מידע נוסף זמין במאמר בנושא שמירת כתובת IP פנימית סטטית.

המסוף

1. נכנסים לדף Reserve internal static IP address במסוף Google Cloud .

   איך שומרים כתובת IP סטטית פנימית

2. בשדה שם, מזינים שם לכתובת החדשה.

3. ברשימה IP version בוחרים באפשרות IPv4.

4. ברשימה Network בוחרים באפשרות lb-network.

5. ברשימה Subnetwork בוחרים באפשרות subnet-us.

6. בשדה Region, בוחרים us-east1.

7. ברשימה Static IP address בוחרים באפשרות Assign automatically. אחרי שיוצרים את מאזן העומסים, כתובת ה-IP הזו מצורפת לכלל ההעברה של מאזן העומסים.

8. לוחצים על שמירה כדי לשמור את כתובת ה-IP.

gcloud

1. כדי לשמור כתובת IP חיצונית סטטית, משתמשים בפקודה gcloud compute addresses create.

    gcloud compute addresses create ADDRESS_NAME \
        --region=us-east1 \
        --subnet=subnet-us
   

   מחליפים את ADDRESS_NAME בשם של הכתובת החדשה.

2. כדי לראות את המידע על הכתובת, משתמשים בפקודה gcloud compute addresses describe.

   gcloud compute addresses describe ADDRESS_NAME
   

   מעתיקים את כתובת ה-IP שמוחזרת כדי להשתמש בה כ-RESERVED_IP_ADDRESS בקטע הבא.

הגדרת מאזן העומסים עם קטגוריות קצה עורפי

בקטע הזה מוסבר איך ליצור את המשאבים הבאים עבורregional internal Application Load Balancer:

• שתי קטגוריות קצה עורפי. קטגוריות הקצה העורפי משמשות כעטיפה לקטגוריות של Cloud Storage שיצרתם קודם.
• מפת URL
• שרת proxy יעד
• כלל העברה עם כתובות IP אזוריות. לכלל ההעברה מוקצית כתובת IP מרשת המשנה שנוצרה עבור כללי ההעברה של מאזן העומסים. אם מנסים להקצות כתובת IP לכלל ההעברה מתת-הרשת של שרת proxy בלבד, יצירת כלל ההעברה נכשלת.

בדוגמה הזו, אפשר להשתמש ב-HTTP או ב-HTTPS כפרוטוקול של הבקשה והתשובה בין הלקוח לבין מאזן העומסים. כדי ליצור מאזן עומסים ב-HTTPS, צריך להוסיף משאב של אישור SSL לקצה הקדמי של מאזן העומסים.

הערה: אפשר להשתמש ב-CLI של gcloud רק כדי להגדירregional internal Application Load Balancer עם קטגוריות backend.

כדי ליצור את רכיבי איזון העומסים שצוינו קודם באמצעות ה-CLI של gcloud, פועלים לפי השלבים הבאים:

1. יוצרים שתי קטגוריות עורפיות באזור us-east1 באמצעות הפקודה gcloud compute backend-buckets create. לקטגוריות הקצה העורפי יש סכמת איזון עומסים של INTERNAL_MANAGED.

   gcloud compute backend-buckets create backend-bucket-cats \
       --gcs-bucket-name=BUCKET1_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --region=us-east1
   

   gcloud compute backend-buckets create backend-bucket-dogs \
       --gcs-bucket-name=BUCKET2_NAME \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --region=us-east1
   

   הערה: כשיוצרים קטגוריית קצה עורפי עבורregional internal Application Load Balancer, אי אפשר להפעיל את Cloud CDN.

2. יוצרים מפת URL כדי לנתב בקשות נכנסות לקטגוריית קצה עורפי באמצעות הפקודה gcloud compute url-maps create.

   gcloud compute url-maps create lb-map \
       --default-backend-bucket=backend-bucket-cats \
       --region=us-east1
   

3. מגדירים את כללי המארח והנתיב של מפת URL באמצעות הפקודה gcloud compute url-maps add-path-matcher.

   בדוגמה הזו, קטגוריית הקצה העורפי שמוגדרת כברירת מחדל היא backend-bucket-cats, שמטפלת בכל הנתיבים שקיימים בה. עם זאת, כל בקשה שמכוונת אל http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg משתמשת בבק-אנד backend-bucket-dogs. לדוגמה, אם התיקייה /love-to-fetch/ קיימת גם בקצה העורפי שמוגדר כברירת מחדל (backend-bucket-cats), מאזן העומסים נותן עדיפות לקצה העורפי backend-bucket-dogs כי יש כלל נתיב ספציפי ל-/love-to-fetch/*.

   gcloud compute url-maps add-path-matcher lb-map \
       --path-matcher-name=path-matcher-pets \
       --new-hosts=* \
       --backend-bucket-path-rules="/love-to-fetch/*=backend-bucket-dogs" \
       --default-backend-bucket=backend-bucket-cats \
       --region=us-east1
   

4. יוצרים שרת proxy ליעד באמצעות הפקודה gcloud compute target-http-proxies create.

   לתעבורת נתונים של HTTP, יוצרים Proxy יעד ל-HTTP כדי להפנות בקשות למפת URL:

   gcloud compute target-http-proxies create http-proxy \
       --url-map=lb-map \
       --region=us-east1
   

   לתנועה מסוג HTTPS, יוצרים שרת proxy יעד מסוג HTTPS כדי להפנות בקשות למפת URL. ה-proxy הוא החלק במאזן העומסים שמכיל את אישור ה-SSL של מאזן עומסים ב-HTTPS. אחרי יצירת האישור, אפשר לצרף אותו לשרת proxy של יעד HTTPS.

   gcloud compute target-https-proxies create https-proxy \
       --url-map=lb-map \
       --certificate-manager-certificates=CERTIFICATE_NAME \
       --region=us-east1
   

   מחליפים את CERTIFICATE_NAME בשם של אישור ה-SSL שיצרתם באמצעות Certificate Manager.

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

   הזמנת כתובת IP היא אופציונלית לכלל העברה של HTTP, אבל היא נדרשת לכלל העברה של HTTPS.

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

   לתנועת HTTP, יוצרים את כללי ההעברה כדי לנתב בקשות נכנסות אל שרת ה-Proxy של יעד HTTP:

   gcloud compute forwarding-rules create http-fw-rule-1 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-us \
       --subnet-region=us-east1 \
       --ports=80 \
       --target-http-proxy=http-proxy \
       --target-http-proxy-region=us-east1 \
       --region=us-east1
   

   לתנועת HTTPS, יוצרים את כללי ההעברה הגלובליים כדי לנתב בקשות נכנסות אל ה-Proxy של יעד HTTPS:

   gcloud compute forwarding-rules create https-fw-rule-1 \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=subnet-us \
       --subnet-region=us-east1 \
       --address=RESERVED_IP_ADDRESS \
       --ports=443 \
       --target-https-proxy=https-proxy \
       --target-http-proxy-region=us-east1 \
       --region=us-east1
   

   מחליפים את RESERVED_IP_ADDRESS בשם של הכתובת שהעתקתם בקטע שמירת כתובת IP פנימית סטטית.

שליחת בקשת HTTP למאזן העומסים

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

איך מוצאים את כתובת ה-IP של כלל ההעברה של מאזן העומסים

כדי לשלוח בקשת HTTP לכתובת ה-IP הווירטואלית (VIP) באזור באמצעות curl, צריך לקבל את כתובת ה-IP של כלל ההעברה של מאזן העומסים (http-fw-rule-1) באזור us-east1.

 gcloud compute forwarding-rules describe http-fw-rule-1 \
     --region=us-east1

מעתיקים את כתובת ה-IP שמוחזרת כדי להשתמש בה כ-FORWARDING_RULE_IP_ADDRESS בשלב הבא.

יצירת מכונת VM של לקוח לבדיקת הקישוריות

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

1. יוצרים מכונה וירטואלית (VM) של לקוח באזור us-east1.

   gcloud compute instances create client-a \
       --image-family=debian-12 \
       --image-project=debian-cloud \
       --network=lb-network \
       --subnet=subnet-us \
       --zone=us-east1-c \
       --tags=allow-ssh
   

2. יוצרים חיבור SSH למכונה הווירטואלית של הלקוח.

   gcloud compute ssh client-a --zone=us-east1-c
   

3. בדוגמה הזו, ל- regional internal Application Load Balancer יש כתובת VIP של קצה קדמי באזור us-east1 ברשת ה-VPC. שולחים בקשת HTTP ל-VIP באזור הזה באמצעות curl.

   curl http://FORWARDING_RULE_IP_ADDRESS/love-to-purr/three-cats.jpg --output three-cats.jpg
   

   curl http://FORWARDING_RULE_IP_ADDRESS/love-to-fetch/two-dogs.jpg --output two-dogs.jpg
   

   מחליפים את FORWARDING_RULE_IP_ADDRESS בכתובת ה-IP שהעתקתם בקטע איך מקבלים את כתובת ה-IP של כלל ההעברה של איזון העומסים.

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

• סקירה כללית על מאזן עומסים פנימי של אפליקציות (ALB)
• תת-רשתות של שרת proxy בלבד למאזני עומסים מבוססי Envoy
• ניהול אישורים
• ניקוי הגדרות של איזון עומסים