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

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

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

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

דרישות

הדרישות ל-Pods הן:

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

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

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

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

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

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

  • אפשר לחשוף עד 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 שמשתייכים לשירותים.
  • ללא 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.

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

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

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