חשיפת מדדים מותאמים אישית למאזני עומסים

במאמר הזה מוסבר איך לשלוח מדד אחד או יותר מ-Pod או מעומס עבודה למאזן העומסים.

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

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

דרישות

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

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

  • צריך להיות אפשר לגשת למדדים בנקודת קצה של HTTP ב-Pods שמתבצע בהם איזון עומסים על ידי שער. נתיב ברירת המחדל של נקודת הקצה הוא /metrics.
  • המדדים צריכים להיות בפורמט שתואם לתקן Prometheus.

  • יש הגבלות על שמות המדדים במאזני עומסים. לדוגמה, השם לא יכול להכיל יותר מ-64 תווים. הרשימה המלאה של ההגבלות מופיעה בפרטים על השדה backends[].customMetrics[].name במאמרי העזרה של ה-API של BackendService.

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

  • אפשר להשתמש רק במדדי מדידה בין 0 ל-1, כאשר 1 מייצג ניצול של 100%.

  • שמות התוויות בבוררי תוויות של Pod לא יכולים להכיל תווים מיוחדים. אפשר להשתמש רק באותיות a-z (קטנות או גדולות), מספרים, מקף וקו תחתון.

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

איזון מבוסס-ניצול (UBB) ב-GKE על סמך מדדים מותאמים אישית

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

כשמשתמשים ב-UBB עם מדדים מותאמים אישית ב-GKE, חלות המגבלות הבאות:

  • Gateway API בלבד: אפשר להשתמש ב-UBB עם מדדים בהתאמה אישית רק בשירותים שאתם חושפים באמצעות Gateway API. ‫GKE משתמש ב-GKE Gateway controller כדי ליצור אינטראקציה עם Gateway API. ממשקי ה-API של Service ו-Ingress לא תומכים ב-UBB עם מדדים מותאמים אישית. המדדים המותאמים אישית צריכים להגיע מה-Pods ששייכים ל-Services.
  • ללא Cloud Service Mesh: אי אפשר להשתמש ב-UBB עם מדדים מותאמים אישית ב-Cloud Service Mesh.
  • מאזני עומסים שלא נתמכים: אי אפשר להשתמש ב-UBB עם מדדים מותאמים אישית במאזנים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי ובמאזני עומסי רשת חיצוניים לשרת proxy.

חשיפת מדדים לאיזון עומסים

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

  2. מוסיפים את המשאב המותאם אישית הבא, ומחליפים את הפרטים שספציפיים למדד ול-Pod שלכם:

    apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: NAME
  namespace: NAMESPACE
spec:
  metrics:
  - pod:
      selector:
        matchLabels:
          APP_LABEL_NAME: APP_LABEL_VALUE
      containers:
      - endpoint:
          port: METRIC_PORT
          path: METRIC_PATH
        metrics:
        - gauge:
          name: METRIC
          prometheusMetricName: METRIC_PROMETHEUS_NAME
          loadBalancing:
            enabled: true

    מחליפים את הערכים הבאים בהתאם לעומס העבודה:

    • ‫NAME: השם של אובייקט AutoscalingMetric.
    • ‫NAMESPACE: מרחב השמות שבו נמצאים ה-Pods.
    • ‫APP_LABEL_NAME ו-APP_LABEL_VALUE: שם התווית והערך שלה שתואמים ל-Pods שפולטים את המדד.
    • ‫METRIC_PORT: מספר היציאה.
    • ‫METRIC_PATH: הנתיב למדד. בודקים את הנתיב שבו משתמשים בשירות או באפליקציה. בדרך כלל הנתיב הוא /metrics.
    • ‫METRIC: שם המדד שאתם חושפים. השם צריך להתאים לביטוי הרגולרי ^[a-z]([a-z0-9_-]*[a-z0-9])?, והאורך שלו לא יכול להיות יותר מ-63 תווים. כלומר, התו הראשון חייב להיות אות קטנה, וכל התווים הבאים חייבים להיות מקפים, קווים תחתונים, אותיות קטנות או ספרות, חוץ מהתו האחרון, שחייב להיות אות או ספרה.

    • אופציונלי: METRIC_PROMETHEUS_NAME: שם המדד של Prometheus כפי שהוא מוצג על ידי ה-Pod. אפשר להשתמש בשדה הזה כדי לשנות את השם של המדד, למשל כי השם של המדד שנחשף על ידי ה-Pod לא עומד בהגבלות על השם שהוגדרו על ידי מאזן העומסים.

      רשימה מלאה של ההגבלות מופיעה בפרטים על השדה backends[].customMetrics[].name במאמרי העזרה של ה-API של BackendService.

  3. מחילים את המניפסט באמצעות הפקודה הבאה:

    kubectl apply -f FILE_NAME.yaml

    מחליפים את FILE_NAME בשם של קובץ ה-YAML.

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

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

    kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: ""
    kind: Service
    name: store-v1
  default:
    balancingMode: CUSTOM_METRICS
    customMetrics:
    -   name: gke.named_metrics.queue_depth_util
        dryRun: false

שימו לב: המדדים שמדווחים על ידי Prometheus פועלים לפי תקן שמות שונה. כשמדווחים על המדדים לצורך איזון עומסים, GKE Metrics Agent מוסיף להם את הקידומת gke.named_metrics. באופן פנימי כדי לעמוד בדרישה של BackendService API.

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

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

מידע נוסף על העבודה עם מאזן העומסים זמין במאמר הגדרת איזון עומסים מבוסס-ניצול לשירותי GKE.

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

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

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