הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) עם Cloud Run,‏ App Engine או פונקציות Cloud Run

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

• App Engine
• פונקציות Cloud Run
• Cloud Run

קבוצות של נקודות קצה ברשת בלי שרת מאפשרות להשתמש בGoogle Cloud אפליקציות בלי שרת עם מאזני עומסים חיצוניים של אפליקציות. אחרי שמגדירים מאזן עומסים עם קצה עורפי של NEG בלי שרת, בקשות למאזן העומסים מנותבות לקצה העורפי של האפליקציה בלי שרת.

מידע נוסף על NEGs בלי שרת (serverless) זמין במאמר סקירה כללית של NEGs בלי שרת (serverless).

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

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

1. פריסת פונקציות App Engine, פונקציות Cloud Run או שירות Cloud Run.
2. אם עדיין לא עשיתם זאת, מתקינים את Google Cloud CLI.
3. הגדרת ההרשאות
4. הוספת משאב של אישור SSL.

פריסת פונקציות Cloud Run, שירות Cloud Run או אפליקציית App Engine

ההוראות בדף הזה מניחות שכבר יש לכם שירות פעיל של Cloud Run, פונקציות Cloud Run או App Engine.

בדוגמה שבדף הזה, השתמשנו במדריך למתחילים של Cloud Run Python כדי לפרוס שירות Cloud Run באזור us-central1. בהמשך הדף מוסבר איך להגדיר מאזן עומסים חיצוני של אפליקציות (ALB) שמשתמש בקצה עורפי של NEG בלי שרתים כדי לנתב בקשות לשירות הזה.

אם עדיין לא פרסתם אפליקציה בלי שרת (serverless), או אם אתם רוצים לנסות NEG בלי שרת (serverless) עם אפליקציה לדוגמה, תוכלו להשתמש באחד מהמדריכים למתחילים שבהמשך. אפשר ליצור אפליקציה בלי שרת בכל אזור, אבל בהמשך צריך להשתמש באותו אזור כדי ליצור את ה-NEG בלי שרת ואת מאזן העומסים (LB).

Cloud Run

כדי ליצור אפליקציית Hello World פשוטה, לארוז אותה בקובץ אימג' של קונטיינר ואז לפרוס את קובץ האימג' של הקונטיינר ב-Cloud Run, אפשר לעיין במאמר מדריך למתחילים: בנייה ופריסה.

אם כבר העליתם קונטיינר לדוגמה ל-Container Registry, תוכלו לעיין במאמר מדריך למתחילים: פריסת קונטיינר לדוגמה מוכן מראש.

פונקציות Cloud Run

מדריך למתחילים בנושא פונקציות Cloud Run: Python

App Engine

אפשר לעיין במדריכים למתחילים הבאים בנושא App Engine ל-Python 3:

• סביבה רגילה
• סביבה גמישה

התקנת Google Cloud CLI

מתקינים את Google Cloud CLI. במאמר סקירה כללית על gcloud מוסבר על הכלי ואיך מתקינים אותו.

אם לא הפעלתם את ה-CLI של gcloud בעבר, קודם מריצים את הפקודה gcloud init כדי לאתחל את ספריית gcloud.

הגדרת ההרשאות

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

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

אופציונלי: שימוש בכתובות BYOIP

באמצעות העברת כתובות IP משלכם (BYOIP), אתם יכולים לייבא כתובות ציבוריות משלכם אלGoogle Cloud כדי להשתמש בכתובות עם משאבי Google Cloud . לדוגמה, אם מייבאים כתובות IPv4 משלכם, אפשר להקצות אחת מהן לכלל ההעברה כשמגדירים את מאזן העומסים. כשפועלים לפי ההוראות במסמך הזה כדי ליצור את מאזן העומסים, צריך לספק את כתובת ה-BYOIP בתור כתובת ה-IP.

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

שמירת כתובת IP חיצונית

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

הערה: השלב הזה נדרש בדוגמה הזו, ומומלץ באופן כללי, כי כתובת IP חיצונית סטטית מספקת כתובת אחת שאליה אפשר להפנות את האפליקציה ללא שרת. הזמנת כתובת IP חיונית גם אם משתמשים בדומיין בהתאמה אישית לאפליקציה בלי שרת (serverless) (נדרש גם לאישורי SSL בניהול Google). אם יש לכם דומיין מותאם אישית, תצטרכו לעדכן את רשומות ה-DNS כדי שהדומיין יפנה לכתובת ה-IP הזו.

המסוף

1. נכנסים לדף External IP addresses במסוף Google Cloud .

   נכנסים אל External IP addresses

2. לוחצים על שמירת כתובת IP חיצונית סטטית.

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

4. בקטע Network service tier, בוחרים באפשרות Premium.

5. בשביל IP version, בוחרים IPv4.

6. בשדה Type (סוג), בוחרים באפשרות Global (גלובלי).

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

gcloud

gcloud compute addresses create EXAMPLE_IP \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

שימו לב לכתובת ה-IPv4 שהוקצתה:

gcloud compute addresses describe EXAMPLE_IP \
    --format="get(address)" \
    --global

מחליפים את EXAMPLE_IP בשם של כתובת ה-IP.

יצירת משאב של אישור SSL

כדי ליצור מאזן עומסים מסוג HTTPS, צריך להוסיף משאב של אישור SSL לממשק הקצה של מאזן העומסים. יוצרים משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי.

• אישורים שמנוהלים על ידי Google. מומלץ להשתמש באישורים בניהול Google כי Google Cloud מקבלים, מנהלים ומחדשים את האישורים האלה באופן אוטומטי. כדי ליצור אישור שמנוהל על ידי Google, צריך דומיין ורשומות DNS של הדומיין הזה כדי שהאישור יוקצה.

  בנוסף, צריך לעדכן את רשומת ה-A ב-DNS של הדומיין כך שתפנה לכתובת ה-IP של מאזן העומסים שנוצרה בשלב הקודם. אם יש לכם כמה דומיינים באישור שמנוהל על ידי Google, אתם צריכים לעדכן את רשומות ה-DNS של כל הדומיינים ותתי-הדומיינים כך שיפנו לכתובת ה-IP של מאזן העומסים. הוראות מפורטות זמינות במאמר שימוש באישורים שמנוהלים על ידי Google.

• אישורים בחתימה עצמית. אם אתם לא רוצים להגדיר דומיין בשלב הזה, אתם יכולים להשתמש באישור SSL בחתימה עצמית לצורך בדיקה.

אזהרה: אל תשתמשו באישור בחתימה עצמית למטרות ייצור.

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

אם אתם רוצים לבדוק את התהליך הזה בלי ליצור משאב של אישור SSL (או דומיין, כפי שנדרש באישורים בניהול Google), אתם עדיין יכולים להשתמש בהוראות שבדף הזה כדי להגדיר איזון עומסים של HTTP במקום זאת.

יצירת מאזן העומסים

בתרשים הבא, מאזן העומסים משתמש בקצה עורפי של NEG ללא שרת כדי להפנות בקשות לשירות Cloud Run ללא שרת. בדוגמה הזו השתמשנו במדריך למתחילים של Cloud Run Python כדי לפרוס שירות Cloud Run.

ארכיטקטורה של מאזן עומסים של אפליקציות (ALB) חיצוני לאפליקציה ב-Cloud Run (לחצו כדי להגדיל).

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

המסוף

בחירת סוג מאזן העומסים

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף איזון עומסים

2. לוחצים על Create load balancer (יצירת מאזן עומסים).
3. בקטע Type of load balancer, בוחרים באפשרות Application Load Balancer (HTTP/HTTPS) ולוחצים על Next.
4. בקטע Public facing or internal (פנימי או חיצוני), בוחרים באפשרות Public facing (external) (חיצוני) ולוחצים על Next (הבא).
5. לפריסה גלובלית או פריסה באזור יחיד, בוחרים באפשרות הכי מתאים לעומסי עבודה גלובליים ולוחצים על הבא.
6. בקטע Load balancer generation (דור מאזן העומסים), בוחרים באפשרות Global external Application Load Balancer (מאזן עומסים גלובלי חיצוני של אפליקציות) ולוחצים על Next (הבא).
7. לוחצים על Configure (הגדרה).

הגדרה בסיסית

1. בשדה של שם מאזן העומסים, מזינים serverless-lb.
2. כדי להמשיך, צריך להשאיר את החלון פתוח.

הגדרות הקצה הקדמי

1. לוחצים על Frontend configuration.
2. בשדה Name (שם), מזינים שם.
3. כדי ליצור מאזן עומסים ב-HTTPS, צריך שיהיה לכם אישור SSL (gcloud compute ssl-certificates list).

   מומלץ להשתמש באישור שמנוהל על ידי Google, כפי שמתואר קודם.

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

מוודאים שהאפשרויות הבאות מוגדרות עם הערכים האלה:

מאפיין (property)	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
פרוטוקול	HTTPS
Network Service Tier	‫Premium
גרסת IP	IPv4
כתובת IP	example-ip
יציאה	443
אופציונלי: פסק זמן של HTTP keepalive	מזינים ערך של זמן קצוב לתפוגה בין 5 ל-1,200 שניות. ערך ברירת המחדל הוא 610 שניות.
אישור	בוחרים אישור SSL קיים או יוצרים אישור חדש. כדי ליצור מאזן עומסים ב-HTTPS, צריך שיהיה לכם משאב של אישור SSL לשימוש בשרת ה-proxy של HTTPS. אפשר ליצור משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי. כדי ליצור אישור שמנוהל על ידי Google, צריך דומיין. רשומת הכתובת הקבועה של הדומיין צריכה להפנות לכתובת ה-IP של איזון העומסים שיצרתם קודם בתהליך הזה. מומלץ להשתמש באישורים שמנוהלים על ידי Google כי Google Cloud היא מקבלת, מנהלת ומחדשת את האישורים האלה באופן אוטומטי. אם אין לכם דומיין, אתם יכולים להשתמש באישור SSL בחתימה עצמית לבדיקה.
אופציונלי: הפעלת הפניה אוטומטית מ-HTTP ל-HTTPS	משתמשים בתיבת הסימון הזו כדי להפעיל הפניות אוטומטיות מ-HTTP ל-HTTPS. אם מסמנים את תיבת הסימון הזו, נוצר מאזן עומסים חלקי נוסף של HTTP שמשתמש באותה כתובת IP כמו מאזן העומסים של HTTPS, ומפנה בקשות HTTP לחלק הקדמי של מאזן העומסים של HTTPS. אפשר לסמן את התיבה הזו רק אם בוחרים בפרוטוקול HTTPS ומשתמשים בכתובת IP שמורה.

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

כדי ליצור מאזן עומסים ב-HTTP, מוודאים שהאפשרויות הבאות מוגדרות עם הערכים האלה:

מאפיין (property)	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
פרוטוקול	HTTP
Network Service Tier	פרימיום
גרסת IP	IPv4
כתובת IP	example-ip
יציאה	80
אופציונלי: פסק זמן של HTTP keepalive	מזינים ערך של זמן קצוב לתפוגה בין 5 ל-1,200 שניות. ערך ברירת המחדל הוא 610 שניות.

4. לוחצים על סיום.

הגדרת הקצה העורפי

1. לוחצים על Backend configuration.
2. ברשימה Backend services & backend buckets לוחצים על יצירת שירות לקצה העורפי.
3. בשדה Name (שם), מזינים שם.
4. בקטע Backend type (סוג קצה עורפי), בוחרים באפשרות Serverless network endpoint group (קבוצה של נקודות קצה ברשת ללא שרת).
5. משאירים את Protocol ללא שינוי. המערכת מתעלמת מהפרמטר הזה.
6. בקטע Backends, באפשרות New backend, בוחרים באפשרות Create Serverless network endpoint group.
7. בשדה Name (שם), מזינים שם.
8. בקטע Region, בוחרים באפשרות us-central1 ואז באפשרות Cloud Run.
9. לוחצים על בחירת שם השירות.
10. ברשימה Service, בוחרים את שירות Cloud Run שרוצים ליצור עבורו מאזן עומסים.
11. לוחצים על יצירה.
12. בקטע New backend (קצה עורפי חדש), לוחצים על Done (סיום).
13. לוחצים על יצירה.

כללי ניתוב

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

1. לוחצים על כללי ניתוב.

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

בדיקת ההגדרות

1. לוחצים על Review and finalize.
2. בודקים את כל ההגדרות.
3. אופציונלי: לוחצים על Equivalent Code (קוד מקביל) כדי לראות את בקשת ה-API בארכיטקטורת REST שתשמש ליצירת מאזן העומסים.
4. לוחצים על יצירה.
5. מחכים שמאזן העומסים ייווצר.
6. לוחצים על השם של מאזן העומסים (serverless-lb).
7. שימו לב לכתובת ה-IP של מאזן העומסים לקראת המשימה הבאה. היא נקראת IP_ADDRESS.

כשמשתמשים במסוף Google Cloud כדי ליצור מאזן עומסים מסוג HTTP(S) עם קצה עורפי של NEG בלי שרת (serverless), הרישום ביומן מופעל כברירת מחדל. אפשר להשתמש בפקודה gcloud compute backend-services update כדי להשבית את הרישום ביומן, אם צריך.

gcloud

1. יוצרים NEG ללא שרת (serverless) בשביל האפליקציה ללא שרת.

   כדי ליצור NEG ללא שרת עם שירות Cloud Run:

      gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
          --region=us-central1 \
          --network-endpoint-type=serverless  \
          --cloud-run-service=CLOUD_RUN_SERVICE_NAME
      

   אפשרויות נוספות זמינות במדריך העזר של gcloud בנושא gcloud compute network-endpoint-groups create.
2. יוצרים שירות לקצה העורפי.

      gcloud compute backend-services create BACKEND_SERVICE_NAME \
          --load-balancing-scheme=EXTERNAL_MANAGED \
          --global
      

3. מוסיפים את ה-NEG בלי שרת (serverless) כקצה עורפי לשירות לקצה העורפי:

      gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
          --global \
          --network-endpoint-group=SERVERLESS_NEG_NAME \
          --network-endpoint-group-region=us-central1
      

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

      gcloud compute url-maps create URL_MAP_NAME \
          --default-service BACKEND_SERVICE_NAME
      

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

5. מבצעים את השלב הזה רק אם רוצים ליצור מאזן עומסים ב-HTTPS. הדרישה הזו לא חלה על מאזני עומסים מסוג HTTP.
   כדי ליצור מאזן עומסים ב-HTTPS, צריך שיהיה לכם משאב של אישור SSL לשימוש בשרת ה-proxy של יעד HTTPS. אפשר ליצור משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי. מומלץ להשתמש באישורים שמנוהלים על ידי Google כי Google Cloud היא משיגה, מנהלת ומחדשת את האישורים האלה באופן אוטומטי.
   
   כדי ליצור אישור שמנוהל על ידי Google, צריך דומיין. אם אין לכם דומיין, אתם יכולים להשתמש באישור SSL בחתימה עצמית לצורך בדיקה.
   
   כדי ליצור משאב של אישור SSL בניהול Google:

      gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
          --domains DOMAIN
      

   כדי ליצור משאב של אישור SSL בניהול עצמי:

      gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
          --certificate CRT_FILE_PATH \
          --private-key KEY_FILE_PATH
      

6. יוצרים שרת proxy של HTTP(S) ליעד כדי להפנות בקשות למפת URL.

   כדי ליצור מאזן עומסים מסוג HTTP, צריך ליצור proxy ליעד HTTP:

      gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
         --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
         --url-map=URL_MAP_NAME
      

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

      gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --ssl-certificates=SSL_CERTIFICATE_NAME \
          --url-map=URL_MAP_NAME
      

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

   • ‫TARGET_HTTP_PROXY_NAME: השם של ה-proxy ל-HTTP של היעד.
   • ‫TARGET_HTTPS_PROXY_NAME: השם של שרת ה-proxy ל-HTTPS של היעד.
   • ‫HTTP_KEEP_ALIVE_TIMEOUT_SEC: שדה אופציונלי שמשמש לציון זמן הקצוב לתפוגה של HTTP keepalive של הלקוח. ערך הזמן הקצוב לתפוגה צריך להיות בין 5 ל-1,200 שניות. ערך ברירת המחדל הוא 610 שניות.
   • ‫SSL_CERTIFICATE_NAME: השם של אישור ה-SSL.
   • ‫URL_MAP_NAME: השם של מפת URL.
7. יוצרים כלל העברה כדי להפנות בקשות נכנסות לשרת ה-proxy.
   
   

   למאזן עומסים מסוג HTTP:

      gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
      --load-balancing-scheme=EXTERNAL_MANAGED \
      --network-tier=PREMIUM \
      --address=EXAMPLE_IP \
      --target-http-proxy=TARGET_HTTP_PROXY_NAME \
      --global \
      --ports=80
      

   במאזן עומסים ב-HTTPS:

      gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
          --load-balancing-scheme=EXTERNAL_MANAGED \
          --network-tier=PREMIUM \
          --address=EXAMPLE_IP \
          --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
          --global \
          --ports=443
      

חיבור הדומיין למאזן העומסים

אחרי שיוצרים את מאזן העומסים, רושמים את כתובת ה-IP שמשויכת למאזן העומסים – לדוגמה, 30.90.80.100. כדי להפנות את הדומיין למאזן העומסים, צריך ליצור רשומת A באמצעות שירות הרישום של הדומיין. אם הוספתם מספר דומיינים לאישור ה-SSL, צריך להוסיף רשומת A לכל אחד מהם, כשכולם מפנים לכתובת ה-IP של מאזן העומסים. לדוגמה, כדי ליצור רשומות A בשביל www.example.com ובשביל example.com, משתמשים בפקודה הבאה:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

אם אתם משתמשים ב-Cloud DNS כספק ה-DNS, תוכלו לעיין במאמר בנושא הוספה, שינוי ומחיקה של רשומות.

בדיקת מאזן העומסים

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

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף איזון עומסים

2. לוחצים על מאזן העומסים שיצרתם.

3. שימו לב לכתובת ה-IP של מאזן העומסים.

4. במקרה של מאזן עומסים מסוג HTTP, אפשר לבדוק את מאזן העומסים באמצעות דפדפן אינטרנט. לשם כך, עוברים אל http://IP_ADDRESS. מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים. המערכת אמורה להפנות אתכם לדף הבית של שירות helloworld.
   

5. במקרה של מאזן עומסים ב-HTTPS, אפשר לבדוק את מאזן העומסים באמצעות דפדפן אינטרנט על ידי מעבר אל https://IP_ADDRESS. מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים. המערכת אמורה להפנות אתכם לדף הבית של שירות helloworld.
   אם זה לא עובד ואתם משתמשים באישור שמנוהל על ידי Google, צריך לוודא שהסטטוס של משאב האישור הוא ACTIVE. מידע נוסף זמין במאמר בנושא סטטוס של משאב אישור SSL בניהול Google.
   אם השתמשתם באישור בחתימה עצמית לצורך בדיקה, תוצג בדפדפן אזהרה. צריך להנחות את הדפדפן באופן מפורש לקבל אישור בחתימה עצמית. לוחצים על האזהרה כדי לראות את הדף בפועל.

הגבלת תעבורת נתונים נכנסת (ingress) בנקודת קצה (endpoint) שמוגדרת כברירת מחדל

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

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

• הגדרת תעבורת נתונים נכנסת (ingress) לרשת לערך Internal and Cloud Load Balancing (איזון עומסים פנימי ובענן) ב-App Engine
• הגדרת כניסה לרשת לערך 'Internal and Cloud Load Balancing' (פנימי ואיזון עומסים ב-Cloud) עבור פונקציות Cloud Run
• הגדרת תעבורת נתונים נכנסת (ingress) לרשת לערך 'פנימי ו-Cloud Load Balancing' ב-Cloud Run

בנוסף, אפשר להשבית את כתובת ה-URL שמוגדרת כברירת מחדל ב-Cloud Run.

אפשרויות הגדרה נוספות

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

הגדרת איזון עומסים במספר אזורים

הערה: כשמדובר ב-NEGs בלי שרת (serverless), איזון עומסים במספר אזורים נתמך רק אם ה-NEG בלי שרת (serverless) מצביע על שירות Cloud Run או על פונקציות Cloud Run. איזון עומסים במספר אזורים עם זיהוי חריגים לא נתמך ב-App Engine, כי אי אפשר לפרוס פרויקט של App Engine במספר אזורים.

בדוגמה שמתוארת בהמשך הדף הזה, יש רק שירות Cloud Run אחד שמשמש כקצה העורפי באזור us-central1. מכיוון שקבוצת נקודות קצה בלי שרת יכולה להפנות רק לנקודת קצה אחת בכל פעם, לא מתבצע איזון עומסים בין כמה אזורים. מאזן העומסים החיצוני של אפליקציות משמש רק כקצה קדמי, והוא מעביר תעבורה לנקודת הקצה של אפליקציית helloworld שצוינה. עם זאת, יכול להיות שתרצו להציג את אפליקציית Cloud Run מכמה אזורים כדי לשפר את זמן האחזור של משתמשי הקצה.

אם שירות קצה עורפי כולל כמה קבוצות NEGs בלי שרת שמצורפות אליו, מאזן העומסים מאזן את התעבורה על ידי העברת בקשות לקבוצת ה-NEG בלי שרת באזור הזמין הקרוב ביותר. עם זאת, שירותי בק-אנד יכולים להכיל רק NEG אחד ללא שרתים לכל אזור. כדי להפוך את שירות Cloud Run לזמין מכמה אזורים, צריך להגדיר ניתוב בין אזורים. צריך להיות אפשר להשתמש בסכימת URL אחת שפועלת בכל מקום בעולם, אבל משרתת בקשות משתמשים מהאזור הקרוב ביותר למשתמש.

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

כדי להגדיר מאזן עומסים במספר אזורים:

1. מגדירים שני שירותי Cloud Run באזורים שונים. נניח שפרסתם שני שירותים של Cloud Run: אחד באזור בארה"ב ואחד באזור באירופה.
2. יוצרים מאזן עומסים חיצוני של אפליקציות (ALB) עם ההגדרה הבאה:
   1. מגדירים שירות לקצה העורפי גלובלי עם שני NEGs ללא שרת:
      1. יוצרים את ה-NEG הראשון באותו אזור שבו שירות Cloud Run נפרס בארה"ב.
      2. יוצרים את ה-NEG השני באותו אזור שבו פועל שירות Cloud Run שנפרס באירופה.
   2. מגדירים את ההגדרות של הקצה הקדמי עם מסלול שירות הרשת Premium.

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

ניתוב במספר אזורים לאפליקציות בלי שרת (serverless)

הקטע הזה מבוסס על הגדרת איזון העומסים שמתוארת בהמשך הדף, שבה יצרתם NEG בלי שרת באזור us-central1 שמפנה לשירות Cloud Run באותו אזור. בנוסף, מניחים שאתם יוצרים שירות שני ב-Cloud Run באזור europe-west1. ה-NEG השני ללא שרת שתיצרו יצביע על שירות Cloud Run הזה באזור europe-west1.

בדוגמה הזו, תבצעו את השלבים הבאים:

1. יוצרים קבוצת NEG שנייה ללא שרתים באזור europe-west1.
2. מצרפים את ה-NEG השני בלי שרת (serverless) לשירות לקצה העורפי.

כדי להוסיף NEG שני בלי שרת (serverless) לשירות קיים לקצה העורפי, פועלים לפי השלבים הבאים.

המסוף

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף איזון עומסים

2. לוחצים על השם של מאזן העומסים שרוצים לערוך את שירות הקצה העורפי שלו.

3. בדף Load balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה).

4. בדף Edit global external Application Load Balancer, לוחצים על Backend configuration.

5. בדף Backend configuration (הגדרות ה-Backend), לוחצים על Edit (עריכה) בשירות לקצה העורפי שרוצים לשנות.

6. בקטע Backends (שרתי קצה עורפי), לוחצים על Add a backend (הוספת שרת קצה עורפי).

7. ברשימה Serverless network endpoint groups (קבוצות של נקודות קצה ברשת ללא שרתים), בוחרים באפשרות Create Serverless network endpoint group (יצירת קבוצה של נקודות קצה ברשת ללא שרתים).

8. מזינים שם ל-NEG ללא שרת.

9. בשדה אזור, בוחרים באפשרות europe-west1.

10. בקטע סוג קבוצה של נקודות קצה ברשת ללא שרת, בוחרים באפשרות Cloud Run, ואז מבצעים את הפעולות הבאות:

    1. בוחרים באפשרות בחירת שירות.
    2. ברשימה Service, בוחרים את שירות Cloud Run שרוצים ליצור עבורו מאזן עומסים.

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

12. בדף New backend (מערכת עורפית חדשה), לוחצים על Done (סיום).

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

14. כדי לעדכן את שירות לקצה העורפי, לוחצים על עדכון.

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

gcloud

1. יוצרים עוד NEG ללא שרת באותו אזור שבו נפרס שירות Cloud Run.

   gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
     --region=europe-west1 \
     --network-endpoint-type=SERVERLESS \
     --cloud-run-service=CLOUD_RUN_SERVICE_2
   

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

   • ‫SERVERLESS_NEG_NAME_2: השם של ה-NEG השני ללא שרת
   • ‫CLOUD_RUN_SERVICE_2: השם של שירות Cloud Run

2. מוסיפים את ה-NEG השני ללא שרת כקצה עורפי לשירות הקצה העורפי.

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --global \
     --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
     --network-endpoint-group-region=europe-west1
   

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

   • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
   • ‫SERVERLESS_NEG_NAME_2: השם של ה-NEG השני ללא שרת

שימוש במינוי דחיפה מאומת ל-Pub/Sub עם פריסה של Cloud Run במספר אזורים

כברירת מחדל, בבקשות push מאומתות, Cloud Run מצפה לשדה קהל ספציפי לאזור. במקרה של פריסת Cloud Run בכמה אזורים, אם בקשת הדחיפה מנותבת לשירות Cloud Run באזור אחר, האימות של אסימון ה-JWT נכשל בגלל חוסר התאמה של קהל היעד.

כדי לעקוף את ההגבלה הספציפית לאזור הזה:

1. הגדרת קהל בהתאמה אישית שזהה לפריסות של שירותים באזורים שונים.
2. מגדירים את הודעות ה-push ב-Pub/Sub כך שישתמשו בקהל בהתאמה אישית כקהל באסימון JWT.

הגדרת ניתוב אזורי

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

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

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

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

1. מגדירים שני שירותי Cloud Run באזורים שונים. נניח שפרסתם שני שירותי Cloud Run: ‏hello-world-eu באזור באירופה ו-hello-world-us באזור בארה"ב.
2. יוצרים מאזן עומסים חיצוני של אפליקציות (ALB) עם ההגדרה הבאה:
   1. הגדרת שירות לקצה העורפי עם NEG ללא שרת באירופה. צריך ליצור את ה-NEG בלי שרת באותו אזור שבו נפרס שירות Cloud Run באירופה.
   2. מגדירים שירות קצה עורפי שני עם NEG אחר בלי שרתים בארה"ב. צריך ליצור את ה-NEG ללא שרת באותו אזור שבו נפרס שירות Cloud Run בארה"ב.
   3. מגדירים את מפת ה-URL עם כללי המארח והנתיב המתאימים, כך שקבוצה אחת של כתובות URL תנותב לשירות לקצה העורפי באירופה, וכל הבקשות ינותבו לשירות לקצה העורפי בארה"ב.
   4. מגדירים את הקצה הקדמי עם מסלול שירות רשת מסוג פרימיום.

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

ניתוב אזורי לאפליקציות בלי שרת (serverless) ללא יתירות כשל

שימוש במסכת כתובת URL

כשיוצרים NEG ללא שרת, במקום לבחור שירות ספציפי של Cloud Run, אפשר להשתמש במסכת כתובות URL כדי להפנות לכמה שירותים שפועלים באותו דומיין. מסכת כתובת URL היא תבנית של סכמת כתובות ה-URL. ה-NEG בלי שרת (serverless) ישתמש בתבנית הזו כדי לחלץ את שם השירות מכתובת ה-URL של הבקשה הנכנסת ולמפות את הבקשה לשירות המתאים.

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

אם עדיין לא עשיתם את זה, מומלץ לקרוא את המאמר סקירה כללית על קבוצות של נקודות קצה בלי שרת (serverless): מסכות של כתובות URL.

יצירת מסכת כתובת URL

כדי ליצור מסכת כתובת URL למאזן העומסים, מתחילים עם כתובת ה-URL של השירות. בדוגמה הזו נשתמש באפליקציה לדוגמה בלי שרת (serverless) שפועלת בכתובת https://example.com/login. זו כתובת ה-URL שבה loginהשירות של האפליקציה יוצג.

1. מסירים את http או https מכתובת ה-URL. נותרו לך example.com/login.
2. מחליפים את שם השירות בפלייסלודר למסיכת כתובת ה-URL.
   1. ‫Cloud Run: מחליפים את שם השירות של Cloud Run במחזיק המקום <service>. אם שירות Cloud Run משויך לתג, מחליפים את שם התג במחזיק המקום <tag>. בדוגמה הזו, מסכת כתובת ה-URL שנותרה היא example.com/<service>.
   2. פונקציות Cloud Run: מחליפים את שם הפונקציה במחזיק המקום <function>. בדוגמה הזו, מסכת כתובת ה-URL שנותרה היא example.com/<function>.
   3. ‫App Engine: מחליפים את שם השירות ב-placeholder‏ <service>. אם לשירות יש גרסה שמשויכת אליו, מחליפים את הגרסה ב-placeholder <version>. בדוגמה הזו, מסכת כתובת ה-URL שנותרה היא example.com/<service>.
   4. API Gateway: מחליפים את שם השער במחזיק המקום <gateway>. בדוגמה הזו, מסכת כתובת ה-URL שנותרה היא example.com/<gateway>.

3. (אופציונלי) אם אפשר לחלץ את שם השירות (או הפונקציה, הגרסה או התג) מחלק הנתיב של כתובת ה-URL, אפשר להשמיט את הדומיין. החלק של הנתיב במסכת כתובת ה-URL מזוהה לפי התו הראשון /. אם התו / לא מופיע במסכת כתובת ה-URL, המסכה מייצגת רק את המארח. לכן, בדוגמה הזו, אפשר לצמצם את מסכת כתובת ה-URL ל-/<service>,‏ /<gateway> או /<function>.

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

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

הנה עוד כמה דוגמאות שממחישות את הכללים האלה:

Cloud Run

בטבלה הזו מניחים שיש לכם דומיין מותאם אישית בשם example.com וכל שירותי Cloud Run ממופים לדומיין הזה באמצעות מאזן עומסים של אפליקציות חיצוני (ALB).

שירות, שם התג	כתובת ה-URL של הדומיין המותאם אישית	מסיכת כתובת URL
service: login	https://login-home.example.com/web	<service>-home.example.com
service: login	https://example.com/login/web	example.com/<service> או /<service>
service: login, tag: test	https://test.login.example.com/web	‫<tag>.<service>.example.com
service: login, tag: test	https://example.com/home/login/test	example.com/home/<service>/<tag> or /home/<service>/<tag>
service: login, tag: test	https://test.example.com/home/login/web	‪<tag>.example.com/home/<service>

פונקציות Cloud Run

בטבלה הזו מניחים שיש לכם דומיין מותאם אישית בשם example.com וכל שירותי פונקציות Cloud Run ממופים לדומיין הזה.

שם הפונקציה	כתובת ה-URL של הדומיין המותאם אישית	אנונימיזציה של כתובת URL
login	https://example.com/login	/<function>
login	https://example.com/home/login	‎/home/<function>
login	https://login.example.com	<function>.example.com
login	https://login.home.example.com	<function>.home.example.com

App Engine

בטבלה הזו מניחים שיש לכם דומיין מותאם אישית בשם example.com וכל שירותי App Engine ממופים לדומיין הזה.

שם השירות, גרסה	כתובת ה-URL של הדומיין המותאם אישית	מסיכת כתובת URL
service: login	https://login.example.com/web	<service>.example.com
service: login	https://example.com/home/login/web	example.com/home/<service>‎ או ‎ /home/<service>‎
service: login, version: test	https://test.example.com/login/web	<version>.example.com/<service>
service: login, version: test	https://example.com/login/test	example.com/<service>/<version>

API Gateway

בטבלה הזו מניחים שיש לכם דומיין בהתאמה אישית בשם example.com וכל השירותים שלכם ב-API Gateway ממופים לדומיין הזה.

שם השער	כתובת URL של דומיין מותאם אישית ב-API Gateway(גרסת Preview)	מסיכת כתובת URL
login	https://example.com/login	/<gateway>
login	https://example.com/home/login	‎/home/<gateway>‎
login	https://login.example.com	<gateway>.example.com
login	https://login.home.example.com	<gateway>.home.example.com

יצירת NEG ללא שרת עם מסכת כתובות URL

המסוף

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

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

כדי להוסיף NEG ללא שרת שמבוסס על מסכת כתובות URL לשירות קצה עורפי קיים:

1. עוברים לדף איזון עומסים במסוף Google Cloud .
   לדף איזון עומסים
2. לוחצים על השם של מאזן העומסים שרוצים לערוך את שירות הקצה העורפי שלו.
3. בדף Load balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה) .
4. בדף Edit global external Application Load Balancer, לוחצים על Backend configuration.
5. בדף Backend configuration (הגדרת קצה עורפי), לוחצים על Edit (עריכה) בשירות הקצה העורפי שרוצים לשנות.
6. לוחצים על הוספת קצה עורפי.
7. בוחרים באפשרות יצירת קבוצה של נקודות קצה ברשת ללא שרת.
   1. בשדה Name (שם), מזינים helloworld-serverless-neg.
   2. בקטע Region, בוחרים באפשרות us-central1.
   3. בקטע סוג קבוצת נקודות קצה ברשת בלי שרת (serverless), בוחרים את הפלטפורמה שבה נוצרו האפליקציות (או השירותים או הפונקציות) בלי שרת (serverless).
      1. בוחרים באפשרות שימוש בהסתרת כתובת URL.
      2. מזינים מסכת כתובות URL. הוראות ליצירת מסכת כתובת URL מפורטות במאמר יצירת מסכת כתובת URL.
      3. לוחצים על יצירה.
8. בקטע New backend (קצה עורפי חדש), לוחצים על Done (סיום).
9. לוחצים על עדכון.

‫gcloud: Cloud Run

כדי ליצור Serverless NEG עם מסכת כתובת URL לדוגמה של example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-url-mask="example.com/<service>"

‫gcloud: פונקציות Cloud Run

כדי ליצור Serverless NEG עם מסכת כתובת URL לדוגמה של example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

‫gcloud: App Engine

כדי ליצור Serverless NEG עם מסכת כתובות URL לדוגמה של example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
    --region=us-central1 \
    --network-endpoint-type=serverless \
    --app-engine-url-mask="example.com/<service>"

‫gcloud: API Gateway

כדי ליצור Serverless NEG עם מסכת כתובות URL לדוגמה של example.com/<gateway>:

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

כדי להבין איך מאזן העומסים מטפל בבעיות שקשורות לחוסר התאמה של מסכות כתובות URL, אפשר לעיין במאמר פתרון בעיות שקשורות ל-NEGs ללא שרתים.

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

אם אפליקציות ה-Serverless שלכם ממופות לדומיינים מותאמים אישית, יכול להיות שתרצו לעדכן את רשומות ה-DNS כך שהתנועה שנשלחת לכתובות ה-URL הקיימות של Cloud Run, פונקציות Cloud Run,‏ API Gateway או דומיין מותאם אישית של App Engine תנותב דרך איזון העומסים.

לדוגמה, אם יש לכם דומיין מותאם אישית בשם example.com וכל השירותים של Cloud Run ממופים לדומיין הזה, צריך לעדכן את רשומת ה-DNS של example.com כך שתפנה לכתובת ה-IP של מאזן העומסים.

לפני שמעדכנים את רשומות ה-DNS, אפשר לבדוק את ההגדרה באופן מקומי על ידי אילוץ פענוח DNS מקומי של הדומיין המותאם אישית לכתובת ה-IP של מאזן העומסים. כדי לבצע בדיקה מקומית, אפשר לשנות את הקובץ /etc/hosts/ במחשב המקומי כך שיפנה אל example.com לכתובת ה-IP של מאזן העומסים, או להשתמש בדגל curl --resolve כדי לאלץ את curl להשתמש בכתובת ה-IP של מאזן העומסים עבור הבקשה.

כשרשומת ה-DNS של example.com מפוענחת לכתובת ה-IP של מאזן העומסים HTTP(S), הבקשות שנשלחות אל example.com מתחילות להיות מנותבות דרך מאזן העומסים. מאזן העומסים משגר אותם לשירות הרלוונטי לקצה העורפי בהתאם למפת ה-URL שלו. בנוסף, אם שירות לקצה העורפי מוגדר עם מסכת כתובת URL, ה-NEG ללא שרת משתמש במסכה כדי לנתב את הבקשה לשירות המתאים ב-Cloud Run, בפונקציות Cloud Run, ב-API Gateway או ב-App Engine.

הערה: אם אתם משתמשים באישורים שמנוהלים על ידי Google, יכול להיות שתהיה השבתה זמנית של השירות הקיים במהלך ההעברה למאזן עומסים חיצוני של אפליקציות (ALB). בדרך כלל ההשבתה הזמנית נמשכת פחות משעה. הסיבה לכך היא שאישור ה-SSL של מאזן העומסים החיצוני של האפליקציה לא יוקצה עד שתעדכנו את רשומות ה-DNS כך שיפנו לכתובת ה-IP של מאזן העומסים.

הפעלת Cloud CDN

הפעלת Cloud CDN בשירות Cloud Run מאפשרת לכם לבצע אופטימיזציה של העברת התוכן על ידי שמירת התוכן במטמון קרוב למשתמשים.

אפשר להפעיל את Cloud CDN בשירותי קצה עורפי שמשמשים מאזני עומסים חיצוניים גלובליים של אפליקציות באמצעות הפקודה gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

‫Cloud CDN נתמך בשירותי קצה עורפיים עם Cloud Run, פונקציות Cloud Run,‏ API Gateway וקצה עורפי של App Engine.

הפעלת IAP במאזן עומסים חיצוני של אפליקציות (ALB)

הערה: אי אפשר להשתמש ב-IAP עם Cloud CDN.

אפשר להגדיר את IAP כך שיהיה מופעל או מושבת (ברירת מחדל). אם האפשרות הזו מופעלת, צריך לספק ערכים למאפיינים oauth2-client-id ו-oauth2-client-secret.

כדי להפעיל את IAP, מעדכנים את שירות לקצה העורפי כך שיכלול את הדגל --iap=enabled עם הערכים oauth2-client-id ו-oauth2-client-secret.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

אפשר גם להפעיל את IAP למשאב Compute Engine באמצעות Google Cloud המסוף, ה-CLI של gcloud או API.

הפעלת Google Cloud Armor

‫Cloud Armor הוא מוצר אבטחה שמספק הגנה מפני התקפות מניעת שירות מבוזרות (DDoS) לכל מאזני העומסים של פרוקסי GCLB. בנוסף, Cloud Armor מספק מדיניות אבטחה שניתנת להגדרה לשירותים שאליהם ניגשים דרך מאזן עומסים חיצוני של אפליקציות (ALB). מידע על כללי מדיניות האבטחה של Cloud Armor למאזני עומסים חיצוניים באפליקציות זמין במאמר סקירה כללית על כללי מדיניות האבטחה של Cloud Armor.

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

1. כדי לבטל את ההצטרפות למדיניות האבטחה שמוגדרת כברירת מחדל ב-Cloud Armor, בוחרים באפשרות None ברשימה Cloud Armor backend security policy.
2. כדי להגדיר את מדיניות האבטחה שמוגדרת כברירת מחדל ב-Cloud Armor, בוחרים באפשרות Default security policy (מדיניות האבטחה שמוגדרת כברירת מחדל) ברשימה Cloud Armor backend security policy (מדיניות האבטחה של העורף האחורי ב-Cloud Armor).
3. בשדה Policy name, מאשרים את השם שנוצר באופן אוטומטי או מזינים שם למדיניות האבטחה.
4. בשדה Request count (מספר הבקשות), מאשרים את מספר הבקשות שמוגדר כברירת מחדל או מזינים מספר שלם בין 1 ל-10,000.
5. בשדה Interval, בוחרים מרווח.
6. בשדה Enforce on key (החלת האכיפה על מפתח), בוחרים באחד מהערכים הבאים: All (הכול), IP address (כתובת IP) או X-Forwarded-For IP address (כתובת ה-IP של X-Forwarded-For). מידע נוסף על האפשרויות האלה זמין במאמר בנושא זיהוי לקוחות להגבלת קצב.

הפעלת רישום ביומן ומעקב

אתם יכולים להפעיל, להשבית ולצפות ביומנים של שירות לקצה העורפי של מאזן עומסים חיצוני של אפליקציות (ALB). כשמשתמשים במסוף Google Cloud , רישום ביומן מופעל כברירת מחדל לשירותי קצה עורפי עם קצה עורפי של NEG ללא שרת. אפשר להשתמש ב-gcloud כדי להשבית את הרישום ביומן לכל שירות קצה עורפי לפי הצורך. הוראות מפורטות מופיעות במאמר בנושא רישום ביומן.

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

עדכון הזמן הקצוב לתפוגה של חיבור HTTP פעיל

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

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

המסוף

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף איזון עומסים

2. לוחצים על השם של מאזן העומסים שרוצים לשנות.
3. לוחצים על עריכה.
4. לוחצים על Frontend configuration.
5. מרחיבים את תכונות מתקדמות. בשדה HTTP keepalive timeout, מזינים ערך של זמן קצוב לתפוגה.
6. לוחצים על עדכון.
7. כדי לבדוק את השינויים, לוחצים על בדיקה וסיום ואז על עדכון.

gcloud

כדי לעדכן את שרת ה-proxy של HTTP היעד במאזן עומסים מסוג HTTP, משתמשים בפקודה gcloud compute target-http-proxies update:

      gcloud compute target-http-proxies update TARGET_HTTP_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    

במאזן עומסים ב-HTTPS, מעדכנים את שרת ה-proxy של HTTPS באמצעות הפקודה gcloud compute target-https-proxies update:

      gcloud compute target-https-proxies update TARGET_HTTPS_PROXY_NAME \
          --http-keep-alive-timeout-sec=HTTP_KEEP_ALIVE_TIMEOUT_SEC \
          --global
    

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

• ‫TARGET_HTTP_PROXY_NAME: השם של ה-proxy ל-HTTP של היעד.
• ‫TARGET_HTTPS_PROXY_NAME: השם של שרת ה-proxy ל-HTTPS של היעד.
• ‫HTTP_KEEP_ALIVE_TIMEOUT_SEC: ערך הזמן הקצוב לתפוגה של HTTP keepalive, מ-5 עד 600 שניות.

הפעלת זיהוי חריגות

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

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

• שיטת consecutiveErrors (outlierDetection.consecutiveErrors), שבה קוד סטטוס של HTTP מסדרה 5xx נחשב לשגיאה.
• השיטה consecutiveGatewayFailure (outlierDetection.consecutiveGatewayFailure), שבה רק קודי הסטטוס 502,‏ 503 ו-504 של HTTP נחשבים לשגיאה.

כדי להפעיל זיהוי חריגות בשירות לקצה העורפי קיים, פועלים לפי השלבים הבאים. שימו לב: גם אחרי שמפעילים את זיהוי החריגים, יכול להיות שחלק מהבקשות יישלחו לשירות הלא תקין ויחזירו ללקוחות את קוד הסטטוס 5xx. כדי להפחית עוד יותר את שיעור השגיאות, אפשר להגדיר ערכים אגרסיביים יותר לפרמטרים של זיהוי חריגות. מידע נוסף זמין בקטע בנושא השדה outlierDetection.

המסוף

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף איזון עומסים

2. לוחצים על השם של מאזן העומסים שרוצים לערוך את שירות הקצה העורפי שלו.

3. בדף Load balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה).

4. בדף Edit global external Application Load Balancer, לוחצים על Backend configuration.

5. בדף Backend configuration (הגדרות ה-Backend), לוחצים על Edit (עריכה) בשירות לקצה העורפי שרוצים לשנות.

6. גוללים למטה ומרחיבים את הקטע הגדרות מתקדמות.

7. בקטע Outlier detection, מסמנים את תיבת הסימון Enable.

8. לוחצים על עריכה כדי להגדיר זיהוי של חריגים.

   מוודאים שהאפשרויות הבאות מוגדרות עם הערכים האלה:

   מאפיין (property)	ערך
   שגיאות עוקבות	5
   מרווח	1000
   זמן בסיסי להוצאת כרטיס	30000
   אחוז ההדחה המקסימלי	50
   אכיפה של רצף שגיאות	100

   בדוגמה הזו, ניתוח זיהוי החריגים מופעל כל שנייה. אם מספר קודי הסטטוס 5xx‏ HTTP הרצופים שמתקבלים על ידי שרת proxy של Envoy הוא חמישה או יותר, נקודת הקצה של השרת העורפי מוצאת ממאגר איזון העומסים של אותו שרת proxy של Envoy למשך 30 שניות. כשמגדירים את אחוז האכיפה ל-100%, שירות לקצה העורפי אוכף את ההוצאה של נקודות קצה לא תקינות ממאגרי איזון העומסים של אותם שרתי proxy ספציפיים של Envoy בכל פעם שהניתוח של זיהוי החריגים מופעל. אם התנאים להוצאה מתקיימים, אפשר להוציא עד 50% מנקודות הקצה בעורף השרת ממאגר איזון העומסים.

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

10. כדי לעדכן את שירות לקצה העורפי, לוחצים על עדכון.

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

gcloud

1. מייצאים את שירות ה-Backend לקובץ YAML.

   gcloud compute backend-services export BACKEND_SERVICE_NAME \
     --destination=BACKEND_SERVICE_NAME.yaml --global
   

   מחליפים את BACKEND_SERVICE_NAME בשם של שירות ה-Backend.

2. עורכים את הגדרת ה-YAML של שירות לקצה העורפי כדי להוסיף את השדות של זיהוי חריגות, כמו שמודגש בהגדרת ה-YAML הבאה, בקטע outlierDetection:

   בדוגמה הזו, ניתוח זיהוי החריגים מופעל כל שנייה. אם מספר קודי הסטטוס 5xx‏ HTTP הרצופים שמתקבלים על ידי שרת proxy של Envoy הוא חמישה או יותר, נקודת הקצה של השרת העורפי מוצאת ממאגר איזון העומסים של אותו שרת proxy של Envoy למשך 30 שניות. כשמגדירים את אחוז האכיפה ל-100%, שירות לקצה העורפי אוכף את ההוצאה של נקודות קצה לא תקינות ממאגרי איזון העומסים של אותם שרתי proxy ספציפיים של Envoy בכל פעם שהניתוח של זיהוי החריגים מופעל. אם התנאים להוצאה מתקיימים, אפשר להוציא עד 50% מנקודות הקצה בעורף השרת ממאגר איזון העומסים.

   name: BACKEND_SERVICE_NAME
   backends:
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/networkEndpointGroups/SERVERLESS_NEG_NAME
   - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/networkEndpointGroups/SERVERLESS_NEG_NAME_2
   outlierDetection:
     baseEjectionTime:
       nanos: 0
       seconds: 30
     consecutiveErrors: 5
     enforcingConsecutiveErrors: 100
     interval:
       nanos: 0
       seconds: 1
     maxEjectionPercent: 50
   port: 80
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
   sessionAffinity: NONE
   timeoutSec: 30
   ...
   

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

   • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
   • ‫PROJECT_ID: מזהה הפרויקט
   • ‫REGION_A ו-REGION_B: האזורים שבהם הוגדר מאזן העומסים.
   • ‫SERVERLESS_NEG_NAME: השם של ה-NEG הראשון ללא שרת
   • ‫SERVERLESS_NEG_NAME_2: השם של ה-NEG השני ללא שרת

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

   gcloud compute backend-services import BACKEND_SERVICE_NAME \
     --source=BACKEND_SERVICE_NAME.yaml --global
   

   התכונה 'זיהוי חריגות' מופעלת עכשיו בשירות לקצה העורפי.

מחיקה של NEG ללא שרת

אי אפשר למחוק קבוצת נקודות קצה ברשת אם היא מצורפת לשירות קצה עורפי. לפני שמוחקים NEG, מוודאים שהוא מנותק משירות לקצה העורפי.

המסוף

1. כדי לוודא ש-NEG בלי שרת (serverless) שרוצים למחוק לא נמצא כרגע בשימוש על ידי שירות לקצה העורפי כלשהו, עוברים לכרטיסייה Backend services בתפריט Load balancing advanced menu.
   עוברים לכרטיסייה Backend services
2. אם קבוצת ה-NEG ללא שרת נמצאת כרגע בשימוש:
   1. לוחצים על השם של שירות הקצה העורפי באמצעות ה-NEG ללא שרת.
   2. לוחצים על Edit ‏.
   3. ברשימה Backends, לוחצים על כדי להסיר את ה-backend של ה-NEG בלי שרת (serverless) משירות לקצה העורפי.
   4. לוחצים על Save.
3. נכנסים לדף Network endpoint group במסוף Google Cloud .
   לדף Network Endpoint Group
4. מסמנים את התיבה שלצד קבוצת ה-NEG בלי שרת (serverless) שרוצים למחוק.
5. לוחצים על Delete.
6. לוחצים שוב על מחיקה כדי לאשר את הפעולה.

gcloud

כדי להסיר NEG בלי שרת (serverless) משירות לקצה העורפי, צריך לציין את האזור שבו נוצר ה-NEG. חובה לציין גם את הדגל --global כי helloworld-backend-service הוא משאב גלובלי.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

כדי למחוק את ה-NEG בלי שרת (serverless):

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

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

• שימוש ברישום ביומן ובמעקב
• פתרון בעיות ב-NEGs ללא שרת
• ניקוי ההגדרות של מאזן העומסים
• שימוש במודול Terraform למאזן עומסים חיצוני מסוג HTTPS עם קצה עורפי של Cloud Run