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

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

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

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

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

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

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

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

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

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

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

בתיעוד של global URL map API ושל global backend service 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. אפשר להשתמש בה גם כדי לנפות באגים בגרסת ניפוי הבאגים של שירות ה-Backend, במקום בגרסה הרגילה.

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

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

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

יש הגבלות על הערכים התקינים של 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). הוראות מפורטות זמינות באחד מהדפים הבאים:

• הגדרת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) עם קצה עורפי של 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. בשדה מארחים, מזינים את כתובת ה-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 שסופק. כדי להגדיר שיוך סשנים מבוסס-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 מתפרשים לפי הסדר שבו הם צוינו. זה שונה מהאופן שבו כללי נתיב מפורשים על ידי התאמה של הקידומת הארוכה ביותר. בכלל נתיב, מאזן העומסים הגלובלי החיצוני של אפליקציות (ALB) בוחר רק כלל נתיב אחד. עם זאת, כשמשתמשים בכללי ניתוב, יכול להיות שיחולו יותר מכלל אחד.

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

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

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