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

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

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

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

דרישות

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

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

  • צריך להיות אפשר לגשת למדדים בנקודת קצה של HTTP. נתיב נקודת הקצה הוא /metrics.
  • הפורמט של המדדים צריך להיות בהתאם לתקן Prometheus.

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

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

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

  • אפשר לחשוף עד 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 עם מדדים מותאמים אישית.
  • ללא 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:
  selector:
    matchLabels:
      name: APP_LABEL_NAME
  endpoints:
  - port: METRIC_PORT
    path: METRIC_PATH
    metrics:
    - name: METRIC
      exportName: METRIC_NEW_NAME

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

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

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

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

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

    kubectl apply -f FILE_NAME.yaml

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

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

  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.

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

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

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