Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

טייס אוטומטי רגילה

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

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

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

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

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

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

חשוב להשתמש באובייקטים של HorizontalPodAutoscaler עם עומסי עבודה שניתנים להרחבה, כמו Deployments ו-StatefulSets. אי אפשר להשתמש בהרחבה אוטומטית אופקית של Pod עם עומסי עבודה שלא ניתן להרחיב, למשל DaemonSets.
כדי לקבל את ההרשאות שדרושות לפתרון בעיות בהתאמה אופקית של קבוצות Pod לעומס ב-GKE, כולל בדיקת אובייקטים של HorizontalPodAutoscaler וצפייה ביומני האשכול, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:
- בדיקת משאבי GKE: GKE Viewer (roles/container.viewer)
- כדי לצפות ביומני אשכול: מציג היומנים (roles/logging.viewer)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

אימות הסטטוס וההגדרה של 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: בדיקת תקינות ברמה גבוהה שמראה אם אפשר לאחזר מדדים (AbleToScale) ולבצע חישובי שינוי גודל (ScalingActive) באמצעות HorizontalPodAutoscaler. סטטוס False בכל אחד מהתנאים האלה מצביע על כשל.
‫Events: בקטע הזה מתועדות פעולות שינוי קנה מידה, אזהרות ושגיאות מהזמן האחרון מהבקר HorizontalPodAutoscaler. לרוב, זה המקום הראשון שבו אפשר למצוא הודעות שגיאה ספציפיות או סיבות לשגיאה, כמו FailedGetScale או FailedGetResourceMetric, שיעזרו לכם לגלות את מקור הבעיה.

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

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

נכנסים לדף Workloads במסוף Google Cloud .

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

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

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

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

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

המסוף

נכנסים לדף Object Browser במסוף Google Cloud .

כניסה לדף Object Browser
ברשימה Object Kinds, מסמנים את התיבה HorizontalPodAutoscaler ולוחצים על OK.
עוברים לקבוצת ה-API‏ autoscaling (שינוי גודל אוטומטי), ואז לוחצים על החץ להרחבה של HorizontalPodAutoscaler.
לוחצים על השם של אובייקט HorizontalPodAutoscaler שרוצים לבדוק.
בודקים את הקטע 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 במסוף Google Cloud .
  
  כניסה לדף 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% CPU והשימוש הנוכחי הוא 93%, היחס הוא בערך 1.094 (93/85≈1.094). הערך הזה קטן מ-1.1, ולכן ה-Horizontal Pod Autoscaler (HPA) לא מגדיל את מספר ה-Pods.
Unready Pods: ‏ Horizontal Pod Autoscaler כולל רק Pods עם סטטוס Ready בחישובי ההתאמה שלו. המערכת מתעלמת מ-Pods שנתקעו בסטטוס Pending או שלא עוברים לסטטוס Ready (בגלל בדיקות תקינות שנכשלו או בעיות במשאבים), והם עלולים למנוע שינוי גודל.
השהיה בתקופת הסנכרון: בקר HorizontalPodAutoscaler בודק את המדדים באופן תקופתי. עיכוב של 15-30 שניות בין הרגע שבו ערך המדד חוצה את הסף לבין הרגע שבו מתחילה פעולת שינוי הגודל הוא נורמלי.
חביון של מדד חדש: כשמשתמשים לראשונה במדד מותאם אישית חדש ב-HorizontalPodAutoscaler, יכול להיות שיופיע חביון חד-פעמי של כמה דקות. העיכוב הזה קורה כי מערכת המעקב (למשל Cloud Monitoring) צריכה ליצור את סדרת הזמן החדשה כשנקודת הנתונים הראשונה נכתבת.
חישוב של כמה מדדים: כשמגדירים כמה מדדים, הכלי Horizontal Pod Autoscaler מחשב את מספר הרפליקות הנדרש לכל מדד בנפרד, ואז בוחר את הערך המחושב הגבוה ביותר כמספר הרפליקות הסופי. בגלל ההתנהגות הזו, עומס העבודה שלכם מותאם כדי לעמוד בדרישות של המדד עם הצרכים הכי גבוהים. לדוגמה, אם מדדי CPU מחשבים שיש צורך ב-9 רפליקות, אבל מדד הבקשות לשנייה מחשב שיש צורך ב-15, הכלי Horizontal Pod Autoscaler משנה את קנה המידה של הפריסה ל-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: השם של שירות.

הסיבה:

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

הפתרון:

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

מאתרים את התוויות של ה-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"}
```
כדי למצוא את כל השירותים שתואמים לתוויות האלה, בודקים את השדה spec.selector של כל השירותים במרחב השמות.
```
kubectl get services -n NAMESPACE -o yaml
```
מזהים כל שירות שהסלקטור שלו תואם לתוויות מהשלב הקודם. לדוגמה, גם {"app": "my-app"} וגם {"app": "my-app", "env": "prod"} יתאימו לתוויות של ה-Pod לדוגמה.
כדי לפתור את הבעיה, בוחרים באחת מהאפשרויות הבאות:
- כדי להפוך את הסלקטור של השירות המיועד לייחודי, מוסיפים תווית חדשה וייחודית לשדה spec.template.metadata.labels של הפריסה. לאחר מכן, מעדכנים את השדה spec.selector של השירות הרלוונטי כדי לכלול את התווית החדשה.
- משנים את השדה spec.selector של כל שאר השירותים שמתנגשים כך שהם יהיו מגבילים יותר ולא יתאימו יותר ל-Pods של עומס העבודה.
מחילים את השינויים:
```
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 לא מזהה את המפתח הזה ולא מאפשר להשתמש בו למדד.

הפתרון:

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

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

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

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

תסמינים:

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

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

הסיבה:

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

הפתרון:

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

כדי לזהות אילו אובייקטים של HorizontalPodAutoscaler מכוונים לאותו עומס עבודה, צריך לקבל את מניפסט ה-YAML של כל אובייקט HorizontalPodAutoscaler. חשוב לשים לב לשדה spec.scaleTargetRef בפלט.
```
kubectl get hpa -n NAMESPACE_NAME -o yaml
```
מחליפים את NAMESPACE_NAME במרחב השמות של אובייקט HorizontalPodAutoscaler.

מחפשים מקרים שבהם למשאבי HorizontalPodAutoscaler שונים יש את אותם ערכים במאפיינים apiVersion, kind ו-name בשדה scaleTargetRef שלהם.
איחוד מדדים לאובייקט HorizontalPodAutoscaler יחיד:
1. בוחרים אובייקט HorizontalPodAutoscaler אחד לשמירה. זהו ה-HorizontalPodAutoscaler שתשנו.
2. בודקים את הקטע spec.metrics במניפסט של כל אחד מאובייקטי HorizontalPodAutoscaler האחרים שמטרגטים את אותה עומס עבודה.
3. מעתיקים את הגדרות המדדים שרוצים לשמור מהקטעים spec.metrics של אובייקטים כפולים של HorizontalPodAutoscaler.
4. מדביקים את הגדרות המדדים שהועתקו למערך spec.metrics של HorizontalPodAutoscaler שהחלטתם לשמור.
מחילים את השינויים:
```
kubectl apply -f MANIFEST_NAME
```
מחליפים את MANIFEST_NAME בשם של מניפסט ה-HorizontalPodAutoscaler שרוצים לשמור.
מוחקים את האובייקטים האחרים של 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. יכול להיות שהמשאב שצוין לא קיים, שהוא נמחק או שיש בו שגיאת איות.

הפתרון:

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

בודקים את השדה scaleTargetRef של המניפסט של HorizontalPodAutoscaler: מוודאים שהערך של name,‏ kind ו-apiVersion בשדה scaleTargetRef תואם בדיוק למטא-נתונים המתאימים של עומס העבודה של היעד. אם שם עומס העבודה שגוי, צריך לעדכן את השדה scaleTargetRef של HorizontalPodAutoscaler כך שיצביע על השם הנכון.
מוודאים שעומס העבודה קיים: מוודאים שעומס העבודה של היעד קיים באותו מרחב שמות כמו HorizontalPodAutoscaler. אפשר לבדוק את זה באמצעות פקודה כמו kubectl get deployment DEPLOYMENT_NAME. אם מחקתם את עומס העבודה בכוונה, צריך למחוק את אובייקט HorizontalPodAutoscaler המתאים כדי לנקות את האשכול. אם צריך ליצור מחדש את עומס העבודה, ה-HorizontalPodAutoscaler מוצא אותו באופן אוטומטי אחרי שהוא זמין, והשגיאה נפתרת.
מוודאים ש-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), צריך להגדיר את השדה resources.requests לכל משאב ספציפי בכל קונטיינר ב-Pods שמטרגטים על ידי אובייקט HorizontalPodAutoscaler. אחרת, האובייקט HorizontalPodAutoscaler לא יכול לבצע את החישובים שהוא צריך, ולא מבצע פעולה שקשורה למדד הזה.

הפתרון:

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

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

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

הפתרון:

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

בדיקת התקינות של מישור הבקרה של Kubernetes:
1. במסוף Google Cloud , אפשר לראות את התקינות והסטטוס של האשכול.
  1. עוברים לדף Kubernetes clusters.
    
    מעבר אל Kubernetes clusters
  2. בודקים את העמודות סטטוס והתראות של האשכול.
  3. לוחצים על התראות כדי לבדוק אם יש פעולות שמתבצעות כרגע, כמו שדרוגים או תיקונים. יכול להיות ששרת ה-API לא יהיה זמין לזמן קצר במהלך הזמנים האלה.
2. בודקים ביומני הביקורת של Cloud אם יש שגיאות שקשורות לרכיבי מישור הבקרה. מידע על צפייה ביומנים האלה זמין במאמר מידע על רישום ביומן ביקורת ב-GKE.
בודקים את התקינות והיומנים של ה-Pods של מתאם המדדים: מוודאים שהסטטוס של ה-Pods של מתאם המדדים הוא Running ושלא בוצעו הפעלות מחדש לאחרונה:
```
kubectl get pods -n custom-metrics,kube-system -o wide
```
אם הסטטוס של ה-Pod הוא כל דבר אחר מלבד Running, או אם יש לו ספירה גבוהה של הפעלה מחדש, צריך לבדוק את ה-Pod כדי למצוא את הסיבה הבסיסית. טיפים לפתרון בעיות מופיעים במאמר Debug Pods (ניפוי באגים ב-Pods) במסמכי התיעוד של Kubernetes.
מוודאים שממשקי ה-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 בזמן שהשגיאות דווחו.

הפתרון:

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

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

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

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

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

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

תסמינים:

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

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

הסיבה:

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

הפתרון:

כדי לנפות באגים בצינור, אפשר לפעול לפי השלבים הבאים:

בודקים אם מתאם המדדים רשום וזמין: מתאם המדדים צריך להירשם בשרת ה-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, ממשיכים לשלב הבא.
ביצוע שאילתה ישירות בממשק ה-API של המדדים: אם המתאם זמין, אפשר לעקוף את HorizontalPodAutoscaler ולבקש את המדד ישירות מממשק ה-API של Kubernetes. הפקודה הזו בודקת את כל צינור הנתונים, משרת ה-API ועד למתאם המדדים ומקור הנתונים.

הערה: הפקודות הבאות משתמשות במעבד ה-JSON‏ jq כדי להדפיס את פלט ה-JSON. אם לא התקנתם את jq, תוכלו להסיר את הקטע | jq .
מהפקודות כדי לראות את תגובת ה-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.
ניתוח פלט הפקודה: התוצאה של הפקודות הקודמות מציינת איפה הבעיה. בוחרים את התרחיש שמתאים לפלט:
- תגובת 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 שמשויך למתאם המדדים שפרסתם. השירות הזה הוא השירות שמצאתם בשלב הקודם. השירות הזה חושף את הפונקציונליות של המתאם לחלקים אחרים באשכול, כולל שרת ה-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 של המתאם לכלל:
    
    זהירות: הפקודה הבאה מחליפה את היציאות המותרות הקיימות. כדי למנוע שיבוש בפונקציונליות של האשכול, צריך לכלול את הפורטים הקיימים (בדרך כלל tcp:443 ל-Kubernetes API ו-tcp:10250 ל-kubelet) בנוסף ל-ADAPTER_PORT.
    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 לא יקטין את מספר הרפליקות, גם אם ערכי המדדים ירדו מתחת לסף היעד. החלון הזה מונע תנודות מהירות, אבל יכול להאט את ההקטנה מעבר למה שמצפים.

הפתרון:

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

אם יש כמה מדדים או מדדים לא זמינים, צריך לאבחן את המדד שגורם לבעיות:
```
kubectl describe hpa HPA_NAME -n NAMESPACE_NAME
```
בפלט, בודקים בקטע Metrics אם יש מדד עם סטטוס <unknown>, ובקטע Events אם יש אזהרות כמו FailedGetCustomMetric או FailedGetExternalMetric. למידע מפורט על ניפוי באגים בצינורות, אפשר לעיין בקטע פתרון בעיות במדדים מותאמים אישית ובמדדים חיצוניים.
אם מדד מסוים לא זמין, והוא הופך ללא זמין בתקופות של תנועה נמוכה (תופעה שכיחה במדדים שמבוססים על שיעורים), אפשר לנסות את אחד מהפתרונות הבאים:
- אם אפשר, כדאי להשתמש במדדים שמבוססים על מדד במקום במדדים שמבוססים על שיעור. מדד, כמו המספר הכולל של הודעות בתור (לדוגמה, subscription או num_undelivered_messages), מדווח באופן עקבי על ערך, גם אם הערך הוא 0, וכך מאפשר ל-Horizontal Pod Autoscaler (HPA) לקבל החלטות לגבי שינוי גודל באופן מהימן.
- מוודאים שמקור המדדים מדווח על ערכים של אפס. אם אתם שולטים במדד המותאם אישית, אתם יכולים להגדיר אותו כך שיפרסם 0 בתקופות של חוסר פעילות, במקום לא לשלוח נתונים בכלל.
אם חלון הייצוב של חמש דקות שמוגדר כברירת מחדל לצמצום הקיבולת ארוך מדי, אפשר להתאים אותו אישית. בודקים את הקטע spec.behavior.scaleDown במניפסט של HorizontalPodAutoscaler. אפשר להקטין את הערך של stabilizationWindowSeconds כדי לאפשר למנגנון המידרוג האוטומטי להקטין את מספר המכונות מהר יותר אחרי שהמדדים יורדים. למידע נוסף על הגדרת כללי המדיניות האלה, אפשר לעיין במאמר בנושא כללי מדיניות לשינוי גודל במסמכי העזרה של Kubernetes.

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

אם לא מצאתם פתרון לבעיה שלכם במסמכים, תוכלו להיעזר בקבלת תמיכה, כולל עצות בנושאים הבאים:
- פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
- קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג google-kubernetes-engine כדי לחפש בעיות דומות. אפשר גם להצטרף לערוץ Slack‏ #kubernetes-engine כדי לקבל תמיכה נוספת מהקהילה.
- פתיחת דיווחים על בעיות או בקשות להוספת תכונות באמצעות הכלי הציבורי למעקב אחר בעיות.

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

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

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

תאור של HorizontalPodAutoscaler

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

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

המסוף

kubectl

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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