פתרון בעיות בהתאמה אופקית של קבוצות Pod לעומס

אם התאמה אופקית של קבוצות Pod לעומס לא פועלת כמו שציפיתם ב-Google Kubernetes Engine‏ (GKE), יכול להיות שעומסי העבודה לא יותאמו כמו שצריך. הבעיה הזו יכולה למנוע מאפליקציות לטפל בעומס, מה שעלול לגרום לבעיות בביצועים או להפסקות בשירות. יכול להיות שתראו שה-Pods לא גדלים למרות שיש עומס גבוה על המעבד, ערכי המדדים מוצגים כ-<unknown> בסטטוס של HorizontalPodAutoscaler, או שלא מתבצעות פעולות של שינוי קנה מידה.

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

המידע הזה חשוב למפתחי אפליקציות שמגדירים אובייקטים של HorizontalPodAutoscaler וצריכים לוודא שהאפליקציות שלהם משתנות בהתאם לעומס העבודה בצורה נכונה. הוא גם עוזר לאדמינים ולמפעילים של הפלטפורמה לפתור בעיות בצינור המדדים או בהגדרת האשכול שמשפיעות על כל עומסי העבודה שמתבצעת בהם התאמה אוטומטית של קנה המידה. מידע נוסף על התפקידים הנפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Cloud de Confiance by S3NS תוכן, זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.

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

תיאור הבעיה פתרון אפשרי
אין שינוי קנה מידה, אבל התנאים של HorizontalPodAutoscaler הם True פתרון בעיות ב-HorizontalPodAutoscaler תקין שלא מגיב
מוצגת הודעת שגיאה ספציפית באירועים של HorizontalPodAutoscaler פתרון בעיות נפוצות ב-Horizontal Pod Autoscaler
מדד <unknown> פתרון בעיות שקשורות למדדים מותאמים אישית ולמדדים חיצוניים
לא מתבצעת הפחתה בהתאם לעומס פתרון בעיות שקשורות ל-Horizontal Pod Autoscaler שלא מצליח להקטין את קבוצות ה-Pod

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

  • חשוב להשתמש באובייקטים של HorizontalPodAutoscaler עם עומסי עבודה שניתנים להרחבה, כמו Deployments ו-StatefulSets. אי אפשר להשתמש בהרחבה אוטומטית אופקית של Pod עם עומסי עבודה שלא ניתן להרחיב, למשל DaemonSets.

  • כדי לקבל את ההרשאות שדרושות לפתרון בעיות בהתאמה אופקית של קבוצות Pod לעומס ב-GKE, כולל בדיקה של אובייקטים מסוג HorizontalPodAutoscaler וצפייה ביומני האשכול, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

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

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

  • מגדירים את כלי שורת הפקודה kubectl כדי לתקשר עם אשכול GKE:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance by S3NS .

אימות הסטטוס וההגדרה של Horizontal Pod Autoscaler

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

תיאור של HorizontalPodAutoscaler

כדי לראות את החישובים בזמן אמת של HorizontalPodAutoscaler ואת החלטות ההתאמה האחרונות של קנה המידה, משתמשים בפקודה kubectl describe hpa. הפקודה הזו מספקת סיכום של אובייקט HorizontalPodAutoscaler ויומן Events שיכול לעזור באבחון בעיות:

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • ‫HPA_NAME: השם של אובייקט HorizontalPodAutoscaler.
  • ‫NAMESPACE_NAME: מרחב השמות של אובייקט HorizontalPodAutoscaler.

הפלט אמור להיראות כך:

Name:                                                  php-apache-hpa
Reference:                                             Deployment/php-apache
Metrics: ( current / target )
  resource cpu on pods (as a percentage of request):   1% (1m) / 50%
Min replicas:                                          1
Max replicas:                                          10
Conditions:
  Type            Status  Reason              Message
  ----            ------  ------              -------
  AbleToScale     True    ReadyForNewScale    recommended size matches current size
  ScalingActive   True    ValidMetricFound    the HorizontalPodAutoscaler was able to successfully calculate a replica count
Events:
  Type     Reason              Age   From                       Message
  ----     ------              ----  ----                       -------
  Normal   SuccessfulRescale   39m   horizontal-pod-autoscaler  New size: 4; reason: cpu resource utilization...
  Normal   SuccessfulRescale   26m   horizontal-pod-autoscaler  New size: 1; reason: cpu resource utilization...

בפלט, שלושת הקטעים הבאים עוזרים לאבחן את הבעיה:

  • ‫Metrics: בקטע הזה מוצגים ערכי המדדים הנוכחיים בהשוואה לערכי היעד שלהם. כאן אפשר לבדוק אם HorizontalPodAutoscaler מקבל נתונים. ערך המדד <unknown> מציין שהרכיב HorizontalPodAutoscaler לא אחזר את המדד או שצינור המדדים לא תקין.
  • ‫Conditions: בדיקת תקינות ברמה גבוהה שבודקת אם HorizontalPodAutoscaler יכול לאחזר מדדים (AbleToScale) ולבצע חישובי שינוי גודל (ScalingActive). סטטוס False בכל אחד מהתנאים האלה מצביע על כשל.
  • ‫Events: בקטע הזה מתועדות פעולות שינוי קנה מידה, אזהרות ושגיאות מהזמן האחרון מהבקר HorizontalPodAutoscaler. לרוב, זה המקום הראשון שבו אפשר למצוא הודעות שגיאה ספציפיות או סיבות לשגיאה, כמו FailedGetScale או FailedGetResourceMetric, שיעזרו לכם לגלות את מקור הבעיה.

בדיקת הסטטוס של HorizontalPodAutoscaler ב-Deployments

כדי לבדוק את הסטטוס של אובייקטים מסוג HorizontalPodAutoscaler שמשמשים עם פריסות, משתמשים במסוף Cloud de Confiance :

  1. נכנסים לדף Workloads במסוף Cloud de Confiance .

    כניסה לדף Workloads

  2. לוחצים על השם של הפריסה.

  3. עוברים לכרטיסייה שינוי גודל.

  4. בקטע התאמה לגודל, בודקים את שיטת ההתאמה לגודל הפעילה:

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

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

בדיקת המניפסט של HorizontalPodAutoscaler

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

כדי לראות את קובץ ה-YAML של המניפסט, בוחרים באחת מהאפשרויות הבאות:

המסוף

  1. נכנסים לדף Object Browser במסוף Cloud de Confiance .

    כניסה לדף Object Browser

  2. ברשימה Object Kinds, מסמנים את התיבה HorizontalPodAutoscaler ולוחצים על OK.

  3. עוברים לקבוצת ה-API‏ autoscaling (שינוי גודל אוטומטי), ואז לוחצים על החץ להרחבה של HorizontalPodAutoscaler.

  4. לוחצים על השם של אובייקט HorizontalPodAutoscaler שרוצים לבדוק.

  5. בודקים את הקטע YAML שבו מוצגת ההגדרה המלאה של אובייקט HorizontalPodAutoscaler.

kubectl

מריצים את הפקודה הבאה:

kubectl get hpa HPA_NAME -n NAMESPACE_NAME -o yaml

מחליפים את מה שכתוב בשדות הבאים:

  • ‫HPA_NAME: השם של אובייקט HorizontalPodAutoscaler.
  • ‫NAMESPACE_NAME: מרחב השמות של אובייקט HorizontalPodAutoscaler.

אחרי שמאחזרים את המניפסט, מחפשים את הקטעים החשובים הבאים:

  • spec (ההגדרה שלכם):
    • ‫scaleTargetRef: עומס העבודה (למשל, Deployment) שאובייקט HorizontalPodAutoscaler אמור לשנות את קנה המידה שלו.
    • ‫minReplicas ו-maxReplicas: הגדרות המינימום והמקסימום של העותק.
    • ‫metrics: המדדים שהגדרתם לצורך שינוי גודל (לדוגמה, ניצול CPU או מדדים מותאמים אישית).
  • ‫status (המצב הפעיל של HorizontalPodAutoscaler):
    • ‫currentMetrics: הערכים האחרונים של המדדים שנצפו על ידי HorizontalPodAutoscaler.
    • ‫currentReplicas ו-desiredReplicas: המספר הנוכחי של ה-Pods והמספר שאליו רוצה HorizontalPodAutoscaler לבצע שינוי גודל.
    • ‫conditions: החלק הכי חשוב לפתרון בעיות. בקטע הזה מוצג מצב התקינות של HorizontalPodAutoscaler:
      • ‫AbleToScale: מציין אם האובייקט HorizontalPodAutoscaler יכול למצוא את היעד והמדדים שלו.
      • ‫ScalingActive: מראה אם ל-HorizontalPodAutoscaler מותר לחשב ולבצע שינוי קנה מידה.
      • ‫ScalingLimited: מציין אם HorizontalPodAutoscaler רוצה לשנות את קנה המידה, אבל יש מגבלה בגלל ההגדרות של minReplicas או maxReplicas.

שימוש בתכונות מתקדמות של רישום ביומן

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

  • הצגת אירועים של Horizontal Pod Autoscaler ב-Cloud Logging: אפשר להשתמש במסנן יומן כדי למצוא את כל האירועים של Horizontal Pod Autoscaler עבור אשכול ספציפי. לדוגמה:

    1. נכנסים לדף Logs Explorer במסוף Cloud de Confiance .

      כניסה לדף Logs Explorer

    2. בחלונית השאילתה, מזינים את השאילתה הבאה:

      resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
logName="projects/PROJECT_ID/logs/events"
jsonPayload.involvedObject.kind="HorizontalPodAutoscaler"`

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫CLUSTER_NAME: השם של האשכול שאליו שייך HorizontalPodAutoscaler.
      • ‫LOCATION: האזור או התחום של Compute Engine (לדוגמה, us-central1 או us-central1-a) של האשכול.
      • PROJECT_ID: מזהה הפרויקט.

    3. לוחצים על Run query (הפעלת שאילתה) ובודקים את הפלט.

  • הצגת אירועים של Horizontal Pod Autoscaler‏ (HPA): היומנים האלה מספקים יומנים מובנים שקלים לקריאה, עם הסבר על האופן שבו HorizontalPodAutoscaler מחשב המלצה, ומציעים תובנות מפורטות לגבי תהליך קבלת ההחלטות שלו.

פתרון בעיות ב-HorizontalPodAutoscaler תקין שלא מגיב

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

תסמינים:

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

הסיבה:

יש כמה גורמים שיכולים לגרום להתנהגות הזו:

  • מגבלות של רפליקות: המספר הנוכחי של הרפליקות כבר הגיע לגבול שהוגדר בשדה minReplicas או maxReplicas בהגדרת HorizontalPodAutoscaler.
  • חלון סבילות: מערכת Kubernetes משתמשת בחלון סבילות של 10% כברירת מחדל כדי למנוע שינוי גודל בעקבות תנודות קלות במדדים. ההתאמה מתבצעת רק אם היחס בין המדד הנוכחי למדד היעד חורג מהטווח 0.9 עד 1.1. לדוגמה, אם יעד השימוש במעבד הוא 85% והשימוש הנוכחי הוא 93%, היחס הוא בערך 1.094 (93/85≈1.094). הערך הזה קטן מ-1.1, ולכן המערכת לא מגדילה את מספר העותקים של הפוד.
  • ‫Pods שלא מוכנים: הכלי Horizontal Pod Autoscaler כולל רק Pods עם סטטוס Ready בחישובי ההתאמה שלו. המערכת מתעלמת מ-Pods שנתקעו עם סטטוס Pending או שלא עוברים לסטטוס Ready (בגלל בדיקות תקינות שנכשלו או בעיות במשאבים), והם עלולים למנוע שינוי גודל.
  • עיכוב בתקופת הסנכרון: בקר HorizontalPodAutoscaler בודק מדדים באופן תקופתי. עיכוב של 15-30 שניות בין הרגע שבו ערך המדד חוצה את הסף לבין הרגע שבו מתחילה פעולת שינוי הגודל הוא נורמלי.
  • חביון של מדד חדש: כשמשתמשים לראשונה במדד חדש מותאם אישית ב-HorizontalPodAutoscaler, יכול להיות שיופיע חביון חד-פעמי של כמה דקות. העיכוב הזה קורה כי מערכת המעקב (כמו Cloud Monitoring) צריכה ליצור את סדרת הזמן החדשה כשנקודת הנתונים הראשונה נכתבת.
  • חישוב של כמה מדדים: כשמגדירים כמה מדדים, הכלי Horizontal Pod Autoscaler מחשב את מספר הרפליקות הנדרש לכל מדד בנפרד, ואז בוחר את הערך המחושב הגבוה ביותר כמספר הרפליקות הסופי. בגלל ההתנהגות הזו, עומס העבודה שלכם מותאם כדי לעמוד בדרישות של המדד עם הצרכים הכי גבוהים. לדוגמה, אם מדדי CPU מחשבים שיש צורך ב-9 רפליקות, אבל מדד הבקשות לשנייה מחשב שיש צורך ב-15, ‏ Horizontal Pod Autoscaler (HPA) משנה את קנה המידה של הפריסה ל-15 רפליקות.

הפתרון:

אפשר לנסות את הפתרונות הבאים:

  • מגבלות של רפליקות: בודקים את הערכים minReplicas ו-maxReplicas במניפסט של HorizontalPodAutoscaler או בפלט של הפקודה kubectl describe. אם המגבלות האלה מונעות את ההרחבה הנדרשת, צריך לשנות אותן.
  • חלון הטולרנס: אם נדרשת התאמה של קנה המידה בתוך טווח הטולרנס שמוגדר כברירת מחדל, צריך להגדיר ערך אחר של טולרנס. אחרת, צריך לחכות שהמדד יחרוג מהיחס 0.9 עד 1.1.
  • Unready Pods: בודקים למה ה-Pods הם Pending או לא Ready ופותרים את הבעיות הבסיסיות (למשל, מגבלות משאבים, בדיקות מוכנות שנכשלו). טיפים לפתרון בעיות זמינים במאמר Debug Pods (ניפוי באגים ב-Pods) במסמכי התיעוד של Kubernetes.
  • עיכוב בתקופת הסנכרון וחביון של מדדים חדשים: אלה הם חביונים רגילים. מחכים עד לסיום תקופת הסנכרון או עד ליצירת סדרת הזמן של המדד המותאם אישית החדש.
  • חישוב של כמה מדדים: זו ההתנהגות הרצויה. אם ההגדלה מתבצעת על סמך מדד אחד (למשל, בקשות לשנייה), היא מבטלת בצורה נכונה את החישוב הנמוך יותר של מדד אחר (למשל, CPU).

פתרון בעיות נפוצות ב-Horizontal Pod Autoscaler

בקטעים הבאים מפורטים פתרונות להודעות שגיאה ספציפיות ולסיבות לאירועים שבהם אתם עשויים להיתקל כשאתם בודקים את הסטטוס של HorizontalPodAutoscaler. בדרך כלל ההודעות האלה מופיעות בקטע Events בפלט של הפקודה kubectl describe hpa.

פתרון בעיות בהגדרת Horizontal Pod Autoscaler (HPA)

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

שגיאה: מדדים לא תקינים

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

תסמינים:

אם לא ניתן לחשב את העותקים הנדרשים של HorizontalPodAutoscaler בגלל בעיה בהגדרות, בקטע Events שלו מוצגת הסיבה FailedComputeMetricsReplicas עם הודעה שדומה להודעה הבאה:

invalid metrics (1 invalid out of 1)

הסיבה:

בדרך כלל, השגיאה הזו מצביעה על חוסר התאמה בין המדד type לבין target שהגדרתם במניפסט של HorizontalPodAutoscaler. לדוגמה, יכול להיות שציינתם type של Utilization, אבל סיפקתם ערך יעד של averageValue במקום averageUtilization.

הפתרון:

מתקנים את המניפסט של HorizontalPodAutoscaler כך שהערך של השדה target יתאים למדד type:

  • אם הערך של type הוא Utilization, הערך בשדה target צריך להיות averageUtilization.
  • אם הערך של type הוא AverageValue, הערך בשדה target צריך להיות averageValue.

שגיאה: כמה שירותים בוחרים את אותו יעד

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

תסמינים:

השגיאה הבאה מופיעה:

multiple services selecting the same target of HPA_NAME: SERVICE_NAME

הפלט הזה כולל את הערכים הבאים:

  • ‫HPA_NAME: השם של HorizontalPodAutoscaler.
  • ‫SERVICE_NAME: השם של שירות.

הסיבה:

התאמה אוטומטית לעומס (autoscaling) על סמך תנועה מוגדרת, אבל יותר משירות Kubernetes אחד מכוון לשדה scaleTargetRef של HorizontalPodAutoscaler. שינוי גודל אוטומטי על סמך תעבורה תומך רק ביחס של אחד לאחד בין השירות לבין עומס העבודה שגודלו משתנה אוטומטית.

הפתרון:

כדי לפתור את הבעיה, מוודאים שרק בורר תוויות של שירות אחד תואם ל-Pods של עומס העבודה:

  1. מאתרים את תוויות ה-Pod של עומס העבודה:

    kubectl get deployment HPA_TARGET_DEPLOYMENT \
    -n NAMESPACE \
    -o jsonpath='{.spec.template.metadata.labels}'

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫HPA_TARGET_DEPLOYMENT: השם של הפריסה שאליה מכוון HorizontalPodAutoscaler.
    • ‫NAMESPACE: מרחב השמות של הפריסה.

    הפלט אמור להיראות כך:

    {"app":"my-app", "env":"prod"}

  2. כדי למצוא את כל השירותים שתואמים לתוויות האלה, בודקים את השדה spec.selector של כל השירותים במרחב השמות.

    kubectl get services -n NAMESPACE -o yaml

    מזהים כל שירות שהסלקטור שלו תואם לתוויות מהשלב הקודם. לדוגמה, גם {"app": "my-app"} וגם {"app": "my-app", "env": "prod"} יתאימו לתוויות של רצף המודעות לדוגמה.

  3. כדי לפתור את הבעיה, בוחרים באחת מהאפשרויות הבאות:

    • כדי להפוך את הסלקטור של השירות המיועד לייחודי, מוסיפים תווית חדשה וייחודית לשדה spec.template.metadata.labels של הפריסה. לאחר מכן, מעדכנים את השדה spec.selector של השירות הרלוונטי כדי לכלול את התווית החדשה.
    • משנים את השדה spec.selector של כל שאר השירותים שמתנגשים כדי שהם יהיו מגבילים יותר ולא יתאימו יותר ל-Pods של עומס העבודה.

  4. מחילים את השינויים:

    kubectl apply -f MANIFEST_NAME

    מחליפים את MANIFEST_NAME בשם של קובץ ה-YAML שמכיל את המניפסט המעודכן של השירות או הפריסה.

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

תסמינים:

השגיאה הבאה מופיעה:

unable to fetch metrics from external metrics API: googleapi: Error 400: Metric label: 'LABEL_NAME' is not allowed

בפלט הזה, LABEL_NAME הוא השם של התווית השגויה.

הסיבה:

במניפסט של HorizontalPodAutoscaler מצוין מפתח תווית לא חוקי בקטע metric.selector.matchLabels, ו-Cloud Monitoring לא מזהה את המפתח הזה ולא מאפשר להשתמש בו למדד.

הפתרון:

כדי לפתור את הבעיה:

  1. מזהים את שם התווית האסור מתוך הודעת השגיאה.
  2. מסירים או מתקנים את מפתח התווית הזה בקטע metric.selector.matchLabels של קובץ המניפסט HorizontalPodAutoscaler.
  3. כדי למצוא מפתח תווית תקין שאפשר לסנן לפיו, אפשר לעיין במסמכי Cloud Monitoring בנושא המדד הזה.

בעיה: כמה רכיבי HorizontalPodAutoscaler מכוונים לאותו עומס עבודה

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

תסמינים:

אין ערך ספציפי של Condition או Reason בסטטוס של HorizontalPodAutoscaler שמציין ישירות את הקונפליקט הזה. במקום זאת, יכול להיות שתבחינו בתסמינים הבאים:

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

הסיבה:

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

הפתרון:

כדי למנוע התנגשויות, צריך להגדיר את כל מדדי ההרחבה באובייקט HorizontalPodAutoscaler יחיד. כל HorizontalPodAutoscaler מחשב את הצורך בהרחבה מהשדה spec.metrics שלו, ולכן מיזוג שלהם מאפשר לאובייקט HorizontalPodAutoscaler שנבחר להתחשב בכל הגורמים, כמו CPU ובקשות לשנייה, ביחד:

  1. כדי לזהות אילו אובייקטים של HorizontalPodAutoscaler מכוונים לאותו עומס עבודה, צריך לקבל את מניפסט ה-YAML של כל אובייקט HorizontalPodAutoscaler. חשוב לשים לב לשדה spec.scaleTargetRef בתוצאה.

    kubectl get hpa -n NAMESPACE_NAME -o yaml

    מחליפים את NAMESPACE_NAME במרחב השמות של אובייקט HorizontalPodAutoscaler.

    מחפשים מקרים שבהם למשאבי HorizontalPodAutoscaler שונים יש את אותם ערכים במאפיינים apiVersion, kind ו-name בשדה scaleTargetRef שלהם.

  2. איחוד מדדים לאובייקט HorizontalPodAutoscaler יחיד:

    1. בוחרים אובייקט HorizontalPodAutoscaler אחד לשמירה. זהו ה-HorizontalPodAutoscaler שתשנו.
    2. בודקים את הקטע spec.metrics במניפסט של כל אחד מאובייקטי HorizontalPodAutoscaler האחרים שמטרגטים את אותה עומס עבודה.
    3. מעתיקים את הגדרות המדדים שרוצים לשמור מהקטעים spec.metrics של אובייקטים כפולים של HorizontalPodAutoscaler.
    4. מדביקים את הגדרות המדדים שהועתקו למערך spec.metrics של HorizontalPodAutoscaler שהחלטתם לשמור.

  3. מחילים את השינויים:

    kubectl apply -f MANIFEST_NAME

    מחליפים את MANIFEST_NAME בשם של מניפסט ה-HorizontalPodAutoscaler שרוצים לשמור.

  4. מוחקים את אובייקטי HorizontalPodAutoscaler האחרים שמוגדרים לטירגוט של אותה עומס עבודה:

    kubectl delete hpa DUPLICATE_MANIFEST_NAME -n NAMESPACE_NAME

    מחליפים את DUPLICATE_MANIFEST_NAME בשם של אובייקט HorizontalPodAutoscaler המיותר שרוצים למחוק.

פתרון בעיות שקשורות לעומס עבודה ולמטרות

השגיאות בקטע הזה נגרמות בגלל שינוי קנה המידה של Deployment,‏ StatefulSet או Pods, ולא בגלל האובייקט HorizontalPodAutoscaler עצמו.

שגיאה: לא ניתן לקבל את קנה המידה הנוכחי של היעד

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

תסמינים:

בקטע Events יש תנאי של FailedGetScale עם הודעה שדומה להודעה הבאה:

the HorizontalPodAutoscaler controller was unable to get the target's current scale: WORKLOAD_TYPE.apps "TARGET_WORKLOAD" not found

הפלט הזה כולל את הערכים הבאים:

  • ‫WORKLOAD_TYPE: סוג עומס העבודה, למשל Deployment או StatefulSet.
  • ‫TARGET_WORKLOAD: שם עומס העבודה.

הסיבה:

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

הפתרון:

אפשר לנסות את הפתרונות הבאים:

  1. בודקים את השדה scaleTargetRef של המניפסט של HorizontalPodAutoscaler: מוודאים שהערכים של name,‏ kind ו-apiVersion בשדה scaleTargetRef זהים בדיוק למטא-נתונים התואמים של עומס העבודה של היעד. אם שם עומס העבודה שגוי, צריך לעדכן את השדה scaleTargetRef של HorizontalPodAutoscaler כך שיצביע על השם הנכון.
  2. מוודאים שעומס העבודה קיים: מוודאים שעומס העבודה של היעד קיים באותו מרחב שמות כמו HorizontalPodAutoscaler. אפשר לבדוק את זה באמצעות פקודה כמו kubectl get deployment DEPLOYMENT_NAME. אם מחקתם את עומס העבודה בכוונה, צריך למחוק את אובייקט HorizontalPodAutoscaler המתאים כדי לנקות את האשכול. אם צריך ליצור מחדש את עומס העבודה, ה-HorizontalPodAutoscaler מוצא אותו באופן אוטומטי אחרי שהוא זמין, והשגיאה נפתרת.
  3. מוודאים ש-HorizontalPodAutoscaler ועומס העבודה נמצאים באותו מרחב שמות: ‏ HorizontalPodAutoscaler ועומס העבודה של היעד שלו צריכים להיות באותו מרחב שמות. אם שוכחים לציין מרחב שמות כשיוצרים אובייקט באמצעות פקודות kubectl, ‏ Kubernetes ממקם את האובייקט במרחב השמות default. התנהגות כזו עלולה לגרום לחוסר התאמה אם ה-HorizontalPodAutoscaler נמצא במרחב השמות default ועומס העבודה נמצא במרחב שמות אחר, או להיפך. בודקים את מרחב השמות של שני האובייקטים ומוודאים שהם זהים.

אחרי שהרכיב HorizontalPodAutoscaler מאתר בהצלחה את היעד שלו, התנאי AbleToScale הופך ל-True, וההודעה משתנה ל-the HorizontalPodAutoscaler controller was able to get the target's current scale.

שגיאה: אי אפשר לחשב את מספר העותקים

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

תסמינים:

התנאי ScalingActive הוא False עם Reason של FailedGetResourceMetric. בדרך כלל מוצגת גם הודעה שדומה להודעה הבאה:

the HorizontalPodAutoscaler was unable to compute the replica count

הסיבה:

כדי לשנות את גודל עומס העבודה, כלי Horizontal Pod Autoscaler צריך לחשב את ניצול המשאבים באחוזים, אבל הוא לא יכול לבצע את החישוב הזה כי חסרה הגדרה של resources.requests למשאב המתאים (cpu או memory) לפחות באחד מהקונטיינרים במפרט ה-Pod.

הפתרון:

כדי לפתור את הבעיה, מעדכנים את מניפסט ה-Pod ב-Deployment, ב-StatefulSet או בבקר אחר כדי לכלול שדה resources.requests עבור המשאב (cpu או memory) ש-HorizontalPodAutoscaler מנסה לשנות את קנה המידה שלו עבור כל הקונטיינרים ב-Pod. לדוגמה:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
...
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

שגיאה: אי אפשר לאחזר מדדים של Pod עבור Pod

יכול להיות שתראו את השגיאה הזו אם יש בעיה באחזור המדדים שנדרשים ל-HorizontalPodAutoscaler כדי לקבל החלטות לגבי שינוי גודל. לרוב, הוא קשור להגדרות של משאבי Pod.

תסמינים:

מופיעה הודעה קבועה שדומה להודעה הבאה:

unable to fetch pod metrics for pod

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

הסיבה:

כדי לשנות את קנה המידה על סמך אחוז ניצול המשאבים (למשל cpu או memory), כל קונטיינר ב-Pods שמטרגטים על ידי אובייקט HorizontalPodAutoscaler צריך להגדיר את השדה resources.requests עבור המשאב הספציפי הזה. אחרת, ל-HorizontalPodAutoscaler לא תהיה אפשרות לבצע את החישובים שהוא צריך, והוא לא יבצע פעולה שקשורה למדד הזה.

הפתרון:

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

פתרון בעיות שקשורות לממשק API של מדדים ולזמינות נתונים

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

שגיאה: לא נמצאו גרסאות זמינות ידועות של מדדים

תסמינים:

השגיאה הבאה מופיעה:

unable to fetch metrics from custom metrics API: no known available metric versions found

הסיבה:

השגיאה הזו מציינת שיש בעיה בתקשורת בתוך האשכול, ולא בעיה במקור המדדים (כמו Cloud Monitoring). הנה כמה סיבות נפוצות:

  • שרת ה-API של Kubernetes לא זמין זמנית (לדוגמה, במהלך שדרוג של אשכול או תיקון של מישור הבקרה).
  • ה-Pods של מתאם המדדים (לדוגמה, custom-metrics-stackdriver-adapter) לא תקינים, לא פועלים או לא רשומים בצורה נכונה בשרת ה-API.

הפתרון:

הבעיה הזו היא לרוב זמנית. אם הבעיה נמשכת, אפשר לנסות את הפתרונות הבאים:

  1. בדיקת התקינות של מישור הבקרה של Kubernetes:

    1. במסוף Cloud de Confiance , אפשר לראות את התקינות והסטטוס של האשכול.

      1. עוברים לדף Kubernetes clusters.

        מעבר אל Kubernetes clusters

      2. בודקים את העמודות סטטוס והתראות של האשכול.

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

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

  2. בודקים את התקינות והיומנים של ה-Pods של מתאם המדדים: מוודאים שהסטטוס של ה-Pods של מתאם המדדים הוא Running ושלא בוצעו הפעלות מחדש לאחרונה:

    kubectl get pods -n custom-metrics,kube-system -o wide

    אם הסטטוס של ה-Pod הוא כל דבר אחר מלבד Running, או אם יש לו מספר גבוה של הפעלות מחדש, צריך לבדוק את ה-Pod כדי למצוא את הסיבה הבסיסית. טיפים לפתרון בעיות זמינים במאמר Debug Pods במסמכי התיעוד של Kubernetes.

  3. מוודאים שממשקי ה-API של המדדים רשומים וזמינים:

    kubectl get apiservice | grep metrics.k8s.io

    אם ממשקי ה-API של המדדים תקינים, הפלט דומה לפלט הבא:

    NAME                            SERVICE                                             AVAILABLE   AGE
v1beta1.custom.metrics.k8s.io   custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.external.metrics.k8s.io custom-metrics/custom-metrics-stackdriver-adapter   True        18d
v1beta1.metrics.k8s.io          kube-system/metrics-server                          True        18d

    אם בעמודה AVAILABLE מופיע הערך False, יכול להיות שבעמודה Message במניפסט המלא של APIService יופיעו פרטים נוספים.

    כדי לראות את המניפסט המלא, מריצים את הפקודה הבאה:

    kubectl get apiservice API_SERVICE_NAME -o yaml

    מחליפים את API_SERVICE_NAME בשם של אובייקט ה-APIService, כמו v1beta1.custom.metrics.k8s.io.

שגיאה: השאילתה לא תחזיר סדרות זמן

תסמינים:

השגיאה הבאה מופיעה:

unable to fetch metrics from custom or external metrics API: googleapi: Error
400: The supplied filter [...] query will not return any time series

הסיבה:

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

הפתרון:

אפשר לנסות את הפתרונות הבאים:

  1. אימות ההגדרה: מוודאים ששמות המדדים והתוויות באובייקט HorizontalPodAutoscaler זהים בדיוק לאלה שמופקים על ידי האפליקציה.
  2. בדיקת ההרשאות: מוודאים שהאפליקציה מוגדרת בצורה נכונה עם ההרשאות הנדרשות ונקודות הקצה של ה-API לפרסום מדדים ב-Cloud Monitoring.
  3. אישור פעילות האפליקציה: מוודאים שהאפליקציה שאחראית למדד פעלה וניסתה לשלוח נתונים ל-Cloud Monitoring במהלך פרק הזמן שבו התרחשו האזהרות של Horizontal Pod Autoscaler.
  4. בודקים אם יש שגיאות: בודקים ביומנים של האפליקציה מאותו פרק זמן אם יש שגיאות מפורשות שקשורות לפליטת מדדים, כמו כשלים בחיבור, פרטי כניסה לא תקינים או בעיות בפורמט.

פתרון בעיות שקשורות למדדים מותאמים אישית ולמדדים חיצוניים

אם ה-HorizontalPodAutoscaler מסתמך על מדדים ממקורות אחרים ולא על מדדי ברירת המחדל של CPU או זיכרון, יכולות להתרחש בעיות בצינור של המדדים המותאמים אישית או החיצוניים. הצינור הזה מורכב מהבקר HorizontalPodAutoscaler, משרת ה-API של מדדי Kubernetes, ממתאם המדדים וממקור המדדים (לדוגמה, Cloud Monitoring או Prometheus), כמו שמוצג בתרשים הבא:

צינור של מדדי HPA עם הרכיבים הבאים: בקר HPA, שרת Kubernetes API, מתאם מדדים ומקור מדדים.

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

תסמינים:

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

  • ערך המדד מוצג כ-<unknown>.
  • באירועים של HorizontalPodAutoscaler מוצגות שגיאות כמו FailedGetExternalMetric או FailedGetCustomMetric.

הסיבה:

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

הפתרון:

כדי לנפות באגים בצינור:

  1. בודקים אם מתאם המדדים רשום וזמין: מתאם המדדים צריך להירשם בשרת ה-API הראשי של Kubernetes כדי להציג מדדים. הפעולה הזו היא הדרך הכי ישירה לבדוק אם המתאם פועל ואם שרת ה-API יכול להגיע אליו:

    kubectl get apiservice | grep -E 'NAME|metrics.k8s.io'

    בפלט אמורים להופיע הערכים v1beta1.custom.metrics.k8s.io או v1beta1.external.metrics.k8s.io, ובעמודה Available אמור להופיע הערך True. לדוגמה:

    NAME                   SERVICE                      AVAILABLE   AGE
v1beta1.metrics.k8s.io kube-system/metrics-server   True        18d

    • אם הערך בעמודה Available הוא False או שהוא חסר, סביר להניח שהמתאם קרס או שההגדרה שלו שגויה. בודקים את היומנים של ה-Pod של המתאם במרחב השמות kube-system או custom-metrics אם יש שגיאות שקשורות להרשאות, לקישוריות לרשת למקור המדדים או להודעות שמציינות שלא ניתן למצוא את המדד.

    • אם הערך הוא True, עוברים לשלב הבא.

  2. ביצוע שאילתה ישירות בממשק ה-API של המדדים: אם המתאם זמין, אפשר לעקוף את HorizontalPodAutoscaler ולבקש את המדד ישירות מממשק ה-API של Kubernetes. הפקודה הזו בודקת את הפייפליין כולו, משרת ה-API ועד למתאם המדדים ומקור הנתונים.

    מהפקודות כדי לראות את תגובת ה-JSON הגולמית.

    כדי לשלוח שאילתה למדדים חיצוניים, מריצים את הפקודה הבאה:

    kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/METRIC_NAME" | jq .

    כדי לשלוח שאילתה לגבי מדדים מותאמים אישית של Pod, מריצים את הפקודה הבאה:

    kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/NAMESPACE_NAME/pods/*/METRIC_NAME" | jq .

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NAMESPACE_NAME: מרחב השמות שבו פועלים ה-Pods.
    • ‫METRIC_NAME: השם של המדד המותאם אישית או החיצוני שאתם מנסים לשלוח לגביו שאילתה. לדוגמה, requests_per_second או queue_depth.

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

    • תגובת JSON מוצלחת עם ערך: צינור העברת הנתונים של המדדים פועל בצורה תקינה. הבעיה היא כנראה בעיה בהגדרות במניפסט של HorizontalPodAutoscaler. בודקים אם יש שגיאות איות בשם המדד או אם יש matchLabelsשגוי.

    • ‫Error: Error from server (Service Unavailable): השגיאה הזו מצביעה בדרך כלל על בעיה בקישוריות לרשת, ולרוב מדובר בבעיה בחומת האש באשכולות שמשתמשים בבידוד רשת.

      1. מזהים את שירות מתאם המדדים. בדרך כלל הוא נמצא במרחב השמות custom-metrics או kube-system:

        kubectl get service -n custom-metrics,kube-system | grep -E 'adapter|metrics'

      2. מאתרים את היציאה שהמתאם מאזין לה:

        kubectl get service ADAPTER_SERVICE -n ADAPTER_NAMESPACE -o yaml

        מחליפים את מה שכתוב בשדות הבאים:

        • ‫ADAPTER_SERVICE: השם של שירות Kubernetes שמשויך למתאם המדדים שפרסתם. ‫This Service הוא השירות שמצאתם בשלב הקודם. השירות הזה חושף את הפונקציונליות של המתאם לחלקים אחרים באשכול, כולל שרת ה-API של Kubernetes.
        • ‫ADAPTER_NAMESPACE: מרחב השמות שבו נמצא שירות המתאם (לדוגמה, custom-metrics או kube-system).

      3. מחפשים את הכללים של חומת האש לשיחות נכנסות במישור הבקרה של האשכול:

        gcloud compute firewall-rules list \
    --filter="name~gke-CLUSTER_NAME-[0-9a-z]*-master"

        מחליפים את CLUSTER_NAME בשם האשכול.

      4. מוסיפים את targetPort של המתאם לכלל:

        1. כדי לראות את היציאות המותרות הקיימות, מתארים את הכלל הנוכחי:

          gcloud compute firewall-rules describe FIREWALL_RULE_NAME

          מחליפים את FIREWALL_RULE_NAME בשם של כלל חומת האש ששולט בתעבורת הרשת למישור הבקרה של אשכול Kubernetes.

        2. מעדכנים את הכלל כדי להוסיף את יציאת המתאם לרשימה:

          gcloud compute firewall-rules update FIREWALL_RULE_NAME \
    --allow tcp:443,tcp:10250,tcp:ADAPTER_PORT

          מחליפים את ADAPTER_PORT ביציאת הרשת שהמתאם של המדדים מאזין לה.

      5. מוודאים שכללי מדיניות של רשת Kubernetes לא חוסמים תעבורה לקבוצות Pod של מתאם המדדים:

        kubectl get networkpolicy -n custom-metrics,kube-system

        בודקים את כללי המדיניות כדי לוודא שהם מאפשרים תנועת נתונים נכנסת ממישור הבקרה או משרת ה-API אל ADAPTER_SERVICE ב-ADAPTER_PORT.

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

      • בעיות ב-Adapter Pod: בודקים את היומנים של ה-Adapter Pod או של ה-Pods של המדדים כדי לראות אם יש שגיאות שקשורות לקריאות ל-API, לאימות או לאחזור מדדים. כדי לבדוק את היומנים:

        1. מאתרים את השם של ה-Pod של המתאם:

          kubectl get pods -n ADAPTER_NAMESPACE

        2. צפייה ביומנים:

          kubectl logs ADAPTER_POD_NAME \
    -n ADAPTER_NAMESPACE

          מחליפים את מה שכתוב בשדות הבאים:

          • ‫ADAPTER_POD_NAME: השם של ה-Pod של המתאם שזיהיתם בשלב הקודם.
          • ‫ADAPTER_NAMESPACE: מרחב השמות שבו נמצא ה-Pod של המתאם (לדוגמה, custom-metrics או kube-system).

      • אין נתונים במקור: יכול להיות שהמדד לא קיים במערכת המקורית. משתמשים בכלי מעקב, כמו Metrics Explorer, כדי לוודא שהמדד קיים ושהשם והתוויות שלו נכונים.

פתרון בעיות שגורמות ל-Horizontal Pod Autoscaler (HPA) להיכשל בהקטנת קנה המידה

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

תסמינים:

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

הסיבה:

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

  • שימוש בכמה מדדים: Horizontal Pod Autoscaler מבצע שינוי גודל על סמך המדד שדורש את מספר הרפליקות הגבוה ביותר. אם יש לכם כמה מדדים, עומס העבודה לא יצטמצם אלא אם כל המדדים יצביעו על כך שנדרשות פחות רפליקות. מדד אחד שדורש מספר גבוה של עותקים מונע את ההקטנה, גם אם ערכי המדדים האחרים נמוכים.
  • מדדים לא זמינים: אם מדד כלשהו לא זמין (לרוב מוצג כ-<unknown>), הכלי Horizontal Pod Autoscaler מסרב להקטין את נפח העבודה. התכונה לא יכולה לקבוע אם המדד חסר כי השימוש הוא באמת אפס או כי צינור המדדים שבור. הבעיה הזו נפוצה במדדים מותאמים אישית שמבוססים על שיעורים (לדוגמה, messages_per_second), שיכולים להפסיק לדווח על נתונים כשאין פעילות, ולגרום ל-Horizontal Pod Autoscaler (HPA) לראות את המדד כלא זמין ולהפסיק את פעולות ההקטנה.
  • השהיית הקטנת הקיבולת ממדיניות שינוי הגודל: השדה behavior של HorizontalPodAutoscaler מאפשר להגדיר מדיניות שינוי גודל. מדיניות ברירת המחדל לצמצום הקיבולת כוללת חלון ייצוב של 300 שניות (חמש דקות). במהלך החלון הזה, ה-HorizontalPodAutoscaler לא יקטין את מספר הרפליקות, גם אם ערכי המדדים ירדו מתחת לסף היעד. החלון הזה מונע תנודות מהירות, אבל הוא עלול להאט את ההקטנה בהשוואה למה שמצפים.

הפתרון:

אפשר לנסות את הפתרונות הבאים:

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

    kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

    בפלט, בודקים בקטע Metrics אם יש מדד עם סטטוס <unknown>, ובקטע Events אם יש אזהרות כמו FailedGetCustomMetric או FailedGetExternalMetric. למידע מפורט על ניפוי באגים בצינורות, אפשר לעיין בקטע פתרון בעיות במדדים מותאמים אישית ובמדדים חיצוניים.

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

    • אם אפשר, כדאי להשתמש במדדים שמבוססים על מדד במקום במדדים שמבוססים על שיעור. מדד של מדד רציף, כמו המספר הכולל של ההודעות בתור (לדוגמה, subscription או num_undelivered_messages), מדווח באופן עקבי על ערך, גם אם הערך הוא 0, וכך מאפשר ל-Horizontal Pod Autoscaler (HPA) לקבל החלטות לגבי שינוי גודל באופן מהימן.
    • מוודאים שמקור המדד מדווח על ערכים של אפס. אם אתם שולטים במדד המותאם אישית, אתם יכולים להגדיר אותו כך שיפרסם 0 בתקופות של חוסר פעילות, במקום לא לשלוח נתונים בכלל.

  3. אם חלון הייצוב של חמש דקות שמוגדר כברירת מחדל לצמצום הקיבולת ארוך מדי, אפשר להתאים אותו אישית. בודקים את הקטע spec.behavior.scaleDown במניפסט של HorizontalPodAutoscaler. אפשר להקטין את הערך של stabilizationWindowSeconds כדי לאפשר לשינוי הגודל האוטומטי להקטין את מספר המכונות מהר יותר אחרי שהמדדים יורדים. למידע נוסף על הגדרת כללי המדיניות האלה, אפשר לעיין במאמר בנושא מדיניות שינוי גודל במסמכי העזרה של Kubernetes.

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