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

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

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

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

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

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

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

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

הגדרה ובדיקה של ניהול תנועת הגולשים

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

כדי לקבל עזרה בכתיבת קובצי ה-YAML האלה, אפשר להשתמש בדוגמאות שבדף הזה ובמאמרי העזרה של ה-API של Cloud Load Balancing.

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

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

שימוש בדוגמאות של YAML במסוף Google Cloud

כדי להשתמש בדוגמאות של YAML במסוף Google Cloud :

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

   כניסה לדף Load balancing

2. לוחצים על Create load balancer (יצירת מאזן עומסים).
3. כדי ליצור global external Application Load Balancer, צריך לבצע את השלבים באשף.
4. בהגדרות כללי הניתוב, בוחרים באפשרות כלל מתקדם של מארח ונתיב.
5. לוחצים על הוספת כלל מארח ונתיב.
6. מבצעים אחת מהפעולות הבאות:
• בתיבה Path matcher (התאמת נתיבים), מדביקים את דוגמאות ה-YAML מהמסמך הזה.
• לוחצים על הקישור הנחיות לגבי קוד.
יופיע הדף Path matcher YAML examples. אפשר להדביק דוגמאות מתוך הדף דוגמאות ל-YAML של כלי ההתאמה לנתיבים בתיבה כלי ההתאמה לנתיבים.
7. לוחצים על סיום.

מיפוי תנועה לשירות יחיד

שליחת כל תעבורת הנתונים לשירות יחיד. חשוב להקפיד להחליף את הפלייסהולדרים.

    defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: /PREFIX
        priority: PRIORITY  # 0 is highest
        routeAction:
          weightedBackendServices:
          - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
            weight: 100

פיצול התנועה בין שני שירותים

פיצול התנועה בין שני שירותים או יותר. חשוב להקפיד להחליף את הפלייסהולדרים.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
           weight: 5

הגדרת הפניה אוטומטית לכתובת URL

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

כדי ליצור הפניה אוטומטית לקטגוריית קצה עורפי, משתמשים ב-projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET בשדה defaultService.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: <var>URL_MAP_NAME</var>
   hostRules:
   - hosts:
     - "HOST TO REDIRECT FROM" # Use * for all hosts
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     defaultUrlRedirect:
       hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
       pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
       redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
       stripQuery: True

תנועה משוכפלת

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

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

הערה: התאמה לפי קידומת (pathMatchers[].routeRules[].matchRules[].prefixMatch) משתמשת ב-* כתווים מילוליים ולא כתווים כלליים. אם רוצים להשתמש ב-* כתו כללי לחיפוש, אפשר להשתמש בתבניות נתיבים לכללי ניתוב (pathMatchers[].routeRules[].matchRules[].pathTemplateMatch).

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
             mirrorPercent: 50.0

אם יש לכם כמה שירותי קצה עורפיים משוקללים ואתם רוצים לתעד באיזה שירות קצה עורפי נעשה שימוש כדי למלא את הבקשה המקורית, אתם יכולים להוסיף כותרת בהתאמה אישית שכוללת את המידע הזה לכל הבקשות. בדוגמה הבאה רואים הוספה של כותרת מותאמת אישית בשם x-weighted-picked-backend לכל הבקשות של הלקוח. לערך הכותרת, משתמשים בשם של שירות ה-Backend שטיפל בבקשה המקורית.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
              weight: 95
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_1
                  replace: True
            - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
              weight: 5
              headerAction:
                requestHeadersToAdd:
                - headerName: x-weighted-picked-backend
                  headerValue: BACKEND_SERVICE_2
                  replace: True
           requestMirrorPolicy:
             backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_3

כשמשתמשים בסנכרון תעבורה, חשוב לשים לב למגבלות הבאות:

• שיקוף תנועה נתמך אם לשני שירותי הקצה העורפי יש קצה עורפי של קבוצות מנוהלות של מופעים, של NEGs אזוריים או של NEGs היברידיים. אין תמיכה ב-NEGs לאינטרנט, ב-NEGs ל-serverless ובקצה עורפי של Private Service Connect.
• בקשות לשירות הקצה העורפי המשוכפל לא יוצרות יומנים או מדדים עבור Cloud Logging ו-Cloud Monitoring.

לשכתב את כתובת ה-URL המבוקשת

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

הערה: הפעולה pathPrefixRewrite route מתאימה במיוחד לשימוש עם כללי prefixMatch, כי היא יכולה לשנות ביעילות רק את הקידומת התואמת. לא מומלץ להשתמש בכללי fullPathMatch עם pathPrefixRewrite.

ניסיון חוזר לשליחת בקשה

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

ציון הזמן הקצוב לתפוגה של המסלול

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 0

הגדרת הזרקת תקלות

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 0
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

הגדרת מדיניות מטמון של Cloud CDN

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

אפשר להגדיר מדיניות אחת או יותר של מטמון בכל מקום שבו יש תמיכה ב-routeAction או ב-defaultRouteAction במפת URL. הערך כולל את ארבע הרמות הבאות של מפת URL:

רמה של מפת URL	API	מתי מדיניות המטמון חלה?
שורש	urlMap.defaultRouteAction.cachePolicy	הכלל הזה חל כששם המארח של בקשה לא תואם לאף כלל מארח קיים.
דפוסי נתיבים	urlMap.pathMatchers[].defaultRouteAction.cachePolicy	הכלל הזה מופעל כששם המארח של הבקשה תואם לכלל מארח, אבל אף אחד מכללי הנתיב או כללי המסלול שלו לא תואם.
כללי הנתיבים	urlMap.pathMatchers[].pathRules[].routeAction.cachePolicy	הכלל מופעל כשנתיב הבקשה תואם לכלל נתיב.
כללי ניתוב	urlMap.pathMatchers[].routeRules[].routeAction.cachePolicy	הכלל מופעל כשהנתיב של בקשה תואם לתנאים של נתיב, כותרת או פרמטר של שאילתה בכלל של נתיב.

כשמגדירים מדיניות בנושא מטמון במפת כתובות URL, חשוב לשים לב לנקודות הבאות:

• מדיניות מטמון שמוגדרת בכל רמה של מפת URL מקבלת עדיפות על פני cdnPolicy של ה-Backend עבור מסלול נתון.

• מדיניות המטמון לא חוזרת למדיניות מטמון שמוגדרת ברמה גבוהה יותר של מפת URL. לדוגמה, אם בקשה תואמת ל-routeRule ספציפי שלא מוגדרת בו מדיניות מטמון, מאזן העומסים לא יחזור למדיניות מטמון שהוגדרה ברמה הגבוהה יותר pathMatcher או ברמת השורש urlMap. במקום זאת, המערכת משתמשת בהגדרות של שמירת נתונים במטמון שמוגדרות ב-cdnPolicy, שמוגדרות בשירות הקצה העורפי או בקטגוריית הקצה העורפי.

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

בהגדרת ה-YAML הבאה של מפת URL, מדיניות מטמון מוגדרת ברמה urlMap, ברמה pathMatchers וברמה routeRules.

רמה של מפת URL	התנהגות שמירה במטמון
routeRules	אם בקשה תואמת ל-www.example.com ונתיב הבקשה תואם לתבנית /users/{username=*}/carts/{cartid=**}, הבקשה מנותבת אל BACKEND_SERVICE_2. בבקשות האלה, מדיניות המטמון מוגדרת ל-CACHE_ALL_STATIC, כלומר תוכן סטטי כמו תמונות, CSS ו-JavaScript נשמר אוטומטית במטמון למשך שעה אחת (3, 600 שניות). היא גם מגדירה באופן מפורש שמירה במטמון של תשובות שליליות כדי לשמור במטמון שגיאות 404 Not Found למשך 5 דקות (300 שניות).
pathMatchers	אם בקשה תואמת ל-www.example.com אבל הנתיב לא תואם לתבנית /users/{username=*}/carts/{cartid=**}, הבקשה מנותבת ל-BACKEND_SERVICE_1. במקרה הזה, מדיניות המטמון מוגדרת ל-USE_ORIGIN_HEADERS, כלומר Cloud CDN מסתמך על כותרות Cache-Control של שרת המקור כדי לקבוע מה לשמור במטמון. התג cacheKeyPolicy מוודא שייווצרו רשומות נפרדות במטמון בהתאם לפרוטוקול (HTTP לעומת HTTPS) ולשם המארח הספציפי.
urlMap	אם מגיעה בקשה עם שם מארח שלא תואם לאף כלל, הבקשה מנותבת לשירות לקצה העורפי שמוגדר כברירת מחדל במפת URL, שהוא BACKEND_SERVICE_DEFAULT. מדיניות המטמון מוגדרת ל-CACHE_ALL_STATIC, מה שאומר שתוכן סטטי נשמר במטמון למשך שעה אחת (3,600 שניות).

defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_DEFAULT
# This cache policy is applied if the request hostname does not match
# any hosts specified in the hostRules
defaultRouteAction:
  cachePolicy:
    cacheMode: CACHE_ALL_STATIC
    defaultTtl:
      seconds: 3600
    negativeCaching: true
hostRules:
- hosts:
  - www.example.com
  pathMatcher: cart-matcher
pathMatchers:
- name: cart-matcher
  defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
  # This cache policy is applied if there is a host match but no specific route rule match.
  defaultRouteAction:
    cachePolicy:
      cacheMode: USE_ORIGIN_HEADERS
      cacheKeyPolicy:
        includeProtocol: true
        includeHost: true
  routeRules:
  - description: CartService
    matchRules:
      - pathTemplateMatch: '/users/{username=*}/carts/{cartid=**}'
    service: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_2
    priority: PRIORITY  # 0 is highest
    # This cache policy is applied if there is a route rule match.
    routeAction:
      cachePolicy:
        cacheMode: CACHE_ALL_STATIC
        defaultTtl:
          seconds: 3600
        negativeCaching: true
        negativeCachingPolicy:
          - code: 404
            ttl:
             seconds: 300

כדי להגדיר ולנהל מדיניות מטמון ברמות שונות של מפת URL, אפשר לעיין במאמר הגדרת מדיניות מטמון של Cloud CDN.

הגדרת CORS

הגדרת מדיניות שיתוף משאבים בין מקורות (CORS) כדי לקבוע איך איזון העומסים מטפל בבקשות ממקורות שונים.

מדיניות CORS שחלה ברמה של התאמת נתיבים

בהגדרה הזו, מדיניות ה-CORS מוגדרת ב-defaultRouteAction של התאמת הנתיבים (pathMatchers[].defaultRouteAction.corsPolicy). המשמעות היא שהמדיניות חלה על כל הבקשות שמופנות דרך התאמת הנתיבים שמוגדרת כברירת מחדל, ללא קשר לנתיב או למסלול הספציפיים.

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

defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
name: global-lb-map
hostRules:
- hosts:
  - '*'
  pathMatcher: path-matcher-1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
  name: path-matcher-1
- defaultRouteAction:
    corsPolicy:
      allowCredentials: true
      allowOrigins: [ "http://example.com" ]
      allowMethods: [ "GET", "POST" ]
      allowHeaders: [ "Authorization", "Content-Type" ]

איך זה עובד

• מאזן העומסים אוכף את מדיניות ה-CORS לכל הבקשות שמטופלות על ידי הכלי להתאמת נתיבים.
• מותרות רק בקשות מהמארח example.com באמצעות שיטות GET או POST, ועם הכותרות המותרות (Authorization,‏ Content-Type).
• מותר להשתמש בפרטי כניסה (כמו קובצי Cookie או כותרות הרשאות) בבקשות חוצות מקורות.
• השירות לקצה העורפי מקבל רק בקשות שעומדות בדרישות של מדיניות ה-CORS הזו.

מדיניות CORS מוחלת ברמת כלל המסלול

בהגדרה הזו, מדיניות ה-CORS מוגדרת בתוך routeAction עבור כלל ניתוב ספציפי (pathMatchers[].routeRules[].routeAction.corsPolicy). כך אפשר להחיל מדיניות CORS שונה על מסלולים שונים או על קידומות שונות של נתיבים.

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

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: [ "http://example.com" ]
               allowMethods: [ "GET", "POST" ]
               allowHeaders: [ "Authorization", "Content-Type" ]
               maxAge: 1200
               allowCredentials: true

איך זה עובד

• מדיניות ה-CORS נאכפת רק לגבי בקשות שתואמות לקידומת הנתיב שצוינה (לדוגמה, /PREFIX).
• רק בקשות מהמארח example.com באמצעות שיטות GET או POST, ועם הכותרות המותרות, מורשות עבור המסלול הזה.
• השדה maxAge מציין למשך כמה זמן (בשניות) הדפדפן יכול לשמור במטמון את התוצאות של בקשת קדם-הפעלה.
• מותר להשתמש בפרטי כניסה בבקשות חוצות-דומיינים.
• למסלולים אחרים יכולות להיות מדיניות CORS שונה או ללא מדיניות בכלל.

אפשר גם להגדיר מדיניות CORS ברמות הבאות של מפת URL:

• defaultRouteAction.corsPolicy
• pathMatchers[].pathRules[].routeAction.corsPolicy

הוספה והסרה של כותרות בקשה ותגובה

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

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

יש הגבלות על הערכים התקינים של headerName ו-headerValue. מידע נוסף מופיע במאמר בנושא איך פועלות כותרות בהתאמה אישית.

   defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
   name: global-lb-map
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY  # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

הגדרת זיהוי חריגות

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

    loadBalancingScheme: EXTERNAL_MANAGED
    localityLbPolicy: RANDOM
    name: projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: 30
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: 1
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900

הגדרת פיצול של תנועת הגולשים: שלבים מפורטים

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

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

1. ליצור תבניות נפרדות לשירותים שונים.

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

3. יצירת כללי ניתוב שמגדירים פיצול תנועה של 95% / 5%.

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

במסגרת ההנחיות האלה, אנחנו מניחים:

• נוצרו שרת proxy לחלוקת העומס וכלל העברה, וגם מפת URL בשם global-lb-map.

• מפת URL שולחת את כל התעבורה לשירות לקצה העורפי אחד, שנקרא red-service, שהוא שירות לקצה העורפי שמוגדר כברירת מחדל.

• הגדרתם נתיב חלופי ששולח 5% מהתנועה אל blue-service ו-95% מהתנועה אל green-service.

• נעשה שימוש ב-path matcher.

• אתם משתמשים ב-Cloud Shell או בסביבה אחרת שבה מותקן bash.

הגדרת השירותים

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

ההוראות האלה מניחות שיצרתם בדיקת תקינות של HTTP ‏ (global-lb-basic-check). הוראות מפורטות זמינות באחד מהדפים הבאים:

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

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-12 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=global-lb-basic-check \
    --global \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --global)
}

יצירת השירותים

מתקשרים לפונקציה כדי ליצור שלושה שירותים: red,‏ green ו-blue. השירות red פועל כשירות ברירת המחדל לבקשות אל /. השירותים green ו-blue מוגדרים ב-/prefix לטיפול ב-95% ו-5% מהתנועה, בהתאמה.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /prefix
make_service blue us-west1 us-west1-a lb-network backend-subnet /prefix

יצירת מפת URL

המסוף

1. נכנסים לדף Load balancing במסוף Google Cloud .
   כניסה לדף Load balancing
2. לוחצים על הקישור global-lb-map.
3. לוחצים על עריכה .

הגדרת כללי הניתוב החדשים

1. בקטע כללי ניתוב, בוחרים באפשרות כלל מתקדם של מארח ונתיב.
2. בקטע New hosts and path matcher (מארחים חדשים והתאמה לנתיבים), כדי ליצור את פעולת ברירת המחדל, מגדירים את Service (שירות) ל-red-service.
3. לוחצים על סיום.
4. לוחצים על הוספת כלל מארחים ונתיבים.
5. בשדה Hosts, מזינים את כתובת ה-IP של כלל ההעברה של איזון העומסים.

6. בתיבה Path matcher (התאמת נתיבים), מדביקים את תוכן ה-YAML הבא:

   defaultService: projects/PROJECT_ID/global/backendServices/red-service
   name: matcher1
   routeRules:
   - priority: 2
     matchRules:
       - prefixMatch: /PREFIX
     routeAction:
       weightedBackendServices:
         - backendService: projects/PROJECT_ID/global/backendServices/green-service
           weight: 95
         - backendService: projects/PROJECT_ID/global/backendServices/blue-service
           weight: 5
   

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

8. לוחצים על עדכון.

gcloud

1. מייצאים את מפת ה-URL הקיימת באמצעות הפקודה gcloud compute url-maps export:

   gcloud compute url-maps export global-lb-map \
     --destination=global-lb-map-config.yaml \
     --global
   

2. מעדכנים את קובץ מפת ה-URL‏ global-lb-map-config.yaml על ידי הוספת הטקסט הבא לסוף הקובץ:

   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: projects/PROJECT_ID/global/backendServices/red-service
     name: matcher1
     routeRules:
     - priority: 2
       matchRules:
         - prefixMatch: /PREFIX
       routeAction:
         weightedBackendServices:
           - backendService: projects/PROJECT_ID/global/backendServices/green-service
             weight: 95
           - backendService: projects/PROJECT_ID/global/backendServices/blue-service
             weight: 5
   

3. מעדכנים את מפת ה-URL באמצעות הפקודה gcloud compute url-maps import:

   gcloud compute url-maps import global-lb-map \
      --global \
      --source=global-lb-map-config.yaml
   

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

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

אחר כך בודקים שהבקשות שנשלחות אל FORWARDING_RULE_IP_ADDRESS/prefix מפולגות כמו שצריך.

הגדרת זיקה לסשן (session affinity) על סמך HTTP_COOKIE

התכונה 'בקרת תעבורת נתונים' מאפשרת להגדיר זיקה לסשן (session affinity) על סמך קובץ Cookie שסופק. כדי להגדיר זיקה לסשן (session affinity) מבוססת-HTTP_COOKIE לשירות לקצה העורפי בשם red-service, פועלים לפי ההוראות הבאות.

1. משתמשים בפקודה gcloud compute backend_services export כדי לקבל את הגדרת שירות הקצה העורפי.

   gcloud compute backend-services export red-service \
       --destination=red-service-config.yaml \
       --global
   

2. מעדכנים את הקובץ red-service-config.yaml באופן הבא:

   sessionAffinity: 'HTTP_COOKIE'
   localityLbPolicy: 'RING_HASH'
   consistentHash:
    httpCookie:
     name: 'http_cookie'
     path: '/cookie_path'
     ttl:
       seconds: 100
       nanos: 0
    minimumRingSize: 10000
   

3. בקבץ red-service-config.yaml, מוחקים את השורה הבאה:

   sessionAffinity: NONE
   

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

   gcloud compute backend-services import red-service \
       --source=red-service-config.yaml \
       --global
   

פתרון בעיות

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

מידע על רישום ביומן ועל מעקב זמין במאמר רישום ביומן ומעקב אחרי מאזני עומסים חיצוניים מסוג HTTP(S).

תסמינים:

• תנועה מוגברת לשירותים בכללים שמעל הכלל הרלוונטי.
• עלייה לא צפויה במספר תגובות HTTP מסוג 4xx ו-5xx לכלל מסלול נתון.

פתרון: בודקים את הסדר של כללי הניתוב. כללי הניתוב מתפרשים לפי הסדר שבו הם צוינו.

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

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

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

• מנקים את ההגדרות של מאזן העומסים.