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

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

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

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

אבחון בעיות ב-VerticalPodAutoscaler

כדי לאבחן בעיות ב-VerticalPodAutoscaler, בודקים את הסטטוס וההגדרות באמצעות kubectl או המסוף Google Cloud .

תארו את VerticalPodAutoscaler

כדי לראות את החישובים בזמן אמת ואת ההחלטות האחרונות לגבי שינוי הגודל, משתמשים בפקודה kubectl describe vpa:

kubectl describe vpa VPA_NAME -n NAMESPACE_NAME

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

  • ‫VPA_NAME: השם של VerticalPodAutoscaler.
  • ‫NAMESPACE_NAME: מרחב השמות של VerticalPodAutoscaler.

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

Name:         sample-deployment-vpa
Namespace:    default
API Version:  autoscaling.k8s.io/v1
Kind:         VerticalPodAutoscaler
# Multiple lines are omitted here
Spec:
  Target Ref:
    API Version:  apps/v1
    Kind:         Deployment
    Name:         sample-deployment
  Update Policy:
    Update Mode:  Auto
Status:
  Conditions:
    Last Transition Time:  2025-10-09T10:00:00Z
    Message:               VPA is fetching history in order to provide recommendation
    Reason:                FetchingHistory
    Status:                True
    Type:                  FetchingHistory
    Last Transition Time:  2025-10-09T10:05:00Z
    Message:               VPA pod metrics aren't available yet
    Reason:                NoMetrics
    Status:                True
    Type:                  LowConfidence
    Last Transition Time:  2025-10-09T10:10:00Z
    Message:               VPA is able to provide a recommendation
    Reason:                RecommendationProvided
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  sample-container
      Lower Bound:
        Cpu:     100m
        Memory:  128Mi
      Target:
        Cpu:     200m
        Memory:  256Mi
      Upper Bound:
        Cpu:     500m
        Memory:  512Mi
Events:          <none>

בפלט, בודקים את הקטעים העיקריים האלה:

  • ‫Spec: הצגת פרטי ההגדרה, כולל השדה targetRef (עומס העבודה המטורגט) והשדה updatePolicy (אופן החלת העדכונים).
  • ‫Status: מוצג הקטע Conditions (תקינות תפעולית) והקטע Recommendation (ערכי משאבי המעבד והזיכרון שנוצרו לכל מאגר).
  • ‫Events: רשימה של פעולות או שגיאות שקרו לאחרונה שקשורות לאובייקט VerticalPodAutoscaler.

הצגת קובץ המניפסט של VerticalPodAutoscaler

כדי לראות את ההגדרה המלאה ואת המצב של VerticalPodAutoscaler, בודקים את מניפסט ה-YAML שלו באמצעות kubectl או מסוף Google Cloud :

המסוף

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

    כניסה לדף Object Browser

  2. לוחצים על רשימת המסננים סוג האובייקט.

  3. מבטלים את הסימון של כל האפשרויות הקיימות.

  4. בוחרים באפשרות VerticalPodAutoscaler ולוחצים על OK.

  5. ברשימה המסוננת, בוחרים את קבוצת ה-API‏ autoscaling.k8s.io.

  6. בוחרים את סוג האובייקט VerticalPodAutoscaler.

  7. לוחצים על השם של VerticalPodAutoscaler שרוצים לבדוק.

kubectl

kubectl get vpa VPA_NAME \
    -n NAMESPACE_NAME \
    -o yaml

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

  • ‫VPA_NAME: השם של VerticalPodAutoscaler.
  • ‫NAMESPACE_NAME: מרחב השמות של VerticalPodAutoscaler.

בדיקת הסטטוס של VerticalPodAutoscaler ב Google Cloud מסוף

כדי לבדוק את הסטטוס של VerticalPodAutoscaler עבור עומסי העבודה במסוף Google Cloud :

  1. עוברים לדף Workloads.

    כניסה לדף Workloads

  2. לוחצים על השם של עומס העבודה.

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

  4. בודקים את השורה Vertical Pod Autoscaler כדי לראות הודעות סטטוס לגבי איסוף מדדים ותקינות ההגדרה.

איסוף יומני החלטות

כדי לקבל תובנות מפורטות לגבי החישובים וההחלטות של VerticalPodAutoscaler, צריך להפעיל את יומני ההחלטות של Vertical Pod Autoscaler (גרסת Preview) ב-Cloud Logging.

ביומנים האלה מתועדים אירועים כמו UPDATE_RECOMMENDATION,‏ EVICT_POD,‏ APPLY_RECOMMENDATION_IN_PLACE ו-APPLY_RECOMMENDATION_ON_EVICTION.

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

פתרון בעיות בהמלצות של VerticalPodAutoscaler

בקטעים הבאים מפורטות בעיות שבהן הכלי VerticalPodAutoscaler לא מצליח להפיק המלצות או שהוא מפיק המלצות ששונות מהציפיות.

מערכת VerticalPodAutoscaler לא מספקת המלצות

תסמינים:

  • השדה Status.Recommendation במניפסט של VerticalPodAutoscaler ריק.
  • התנאים במניפסט של VerticalPodAutoscaler מציגים את תנאי הסטטוס NoPodsMatched, FetchingHistory או LowConfidence.

הסיבה:

  • יעד שגוי: השדה spec.targetRef במניפסט של VerticalPodAutoscaler לא מצביע על עומס עבודה קיים באותו מרחב שמות.
  • איסוף ראשוני של מדדים: הרכיב VerticalPodAutoscaler נוצר לאחרונה ועדיין אוסף נתוני שימוש היסטוריים במשאבים.
  • בעיות ברכיב metrics-server: הרכיב VerticalPodAutoscaler מסתמך על מדדים מהרכיב metrics-server. אם הרכיב metrics-server לא פועל בצורה תקינה, אי אפשר לאחזר נתוני שימוש באמצעות VerticalPodAutoscaler.
  • אין פודים פעילים: לעומס העבודה של היעד אין פודים פעילים או מוכנים שהכלי VerticalPodAutoscaler יכול לעקוב אחריהם.

הפתרון:

  • בודקים את השדה targetRef: בודקים את הערכים בשדות kind, name ו-apiVersion בקטע spec.targetRef. מוודאים שכל הערכים תואמים לעומס העבודה של היעד. כדי לוודא שעומס העבודה קיים, מריצים את הפקודה:

    kubectl get KIND WORKLOAD_NAME \
    -n NAMESPACE_NAME

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

    • ‫KIND: סוג עומס העבודה, לדוגמה, deployment או statefulset.
    • ‫WORKLOAD_NAME: השם של עומס העבודה.
    • ‫NAMESPACE_NAME: מרחב השמות של עומס העבודה.

  • המתנה לאיסוף נתונים של מדדים: נדרש זמן לאיסוף נתונים של משאבי VerticalPodAutoscaler חדשים. עוקבים אחרי השדה Status.Conditions כדי לראות מתי הוא משתנה לסטטוס RecommendationProvided.

  • בודקים את הרכיב metrics-server:

    1. מוודאים שרכיב ה-Pod של metrics-server פועל:

      kubectl get pods -n kube-system | grep metrics-server

    2. אם ה-Pod לא פועל או שיש לו מספר גבוה של הפעלות מחדש, כדאי לבדוק את היומנים שלו:

      kubectl logs -n kube-system -l k8s-app=metrics-server

      רשומות ביומן שכוללות מילים כמו error,‏ failed או unable to fetch מצביעות על בעיות באיסוף מדדים.

  • מוודאים שפועלים פודים: מוודאים שלעומס העבודה של היעד יש לפחות פוד אחד שפועל ומוכן.

ההמלצות של VerticalPodAutoscaler לא צפויות

תסמינים:

  • הערכים של ה-CPU או הזיכרון בקטע Status.Recommendation גבוהים או נמוכים מהצפוי.
  • ההמלצות לא תואמות לצריכת המשאבים של עומס העבודה שנצפתה.

הסיבה:

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

הפתרון:

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

  • בדיקה אם יש משאבי VerticalPodAutoscaler שמתנגשים:

    1. כדי להציג רשימה של כל משאבי VerticalPodAutoscaler באשכול:

      kubectl get vpa --all-namespaces

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

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

בקטעים הבאים מוסבר איך לפתור בעיות שבהן יש המלצות אבל הן לא מיושמות על יחידות Pods של יעד.

בקשות למשאבי Pod לא מתעדכנות

תסמינים:

  • המניפסט של VerticalPodAutoscaler מציג המלצות בקטע Status, אבל השדה resources.requests במניפסט של ה-Pod לא מתעדכן.
  • כשמשתמשים במצב העדכון Auto או Recreate, הפודים לא מופעלים מחדש כדי להחיל את ההמלצות.

הסיבה:

  • השדה updateMode הוא Off: כשהשדה spec.updatePolicy.updateMode מוגדר כ-Off, הכלי VerticalPodAutoscaler יוצר המלצות אבל לא מיישם אותן.
  • ל-Workload יש רק עותק אחד: במצב עדכון Auto או Recreate,‏ VerticalPodAutoscaler לא מפנה עומסי עבודה עם עותק אחד כדי למנוע השבתה.

הפתרון:

  • בודקים את השדה updateMode: משנים את מניפסט VerticalPodAutoscaler כדי להגדיר את השדה spec.updatePolicy.updateMode לערך Auto, ‏Recreate או InPlaceOrRecreate.
  • הגדלת מספר הרפליקות: בעומסי עבודה שמשתמשים במצב עדכון Auto או Recreate, מוודאים של-Deployment או ל-StatefulSet יש יותר מרפליקה אחת.

עדכונים במקום נכשלים או נדחים

תסמינים:

  • השלמת השינוי של גודל מאגר התגים במקום נכשלת או נדחית.

הסיבה:

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

הפתרון:

  • בדיקת הסטטוס של שינוי הגודל שנדחה והקיבולת של הצומת:

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

    1. בודקים את ההערות של ה-Pod כדי לראות אם ההערה vpaInPlaceUpdated מוגדרת ל-"true":

      metadata:
  annotations:
    vpaInPlaceUpdated: "true"
    vpaUpdates: 'Pod resources updated by sample-deployment-vpa: container 0: cpu request, memory request'

    2. כדי לבדוק את הסטטוס של הדחייה, בודקים את השדה status.conditions של אירועי שינוי הגודל שנדחו:

      status:
  conditions:
  - type: PodResizePending
    status: "True"
    reason: Deferred
    message: "Node didn't have enough resource: ..."

    3. בודקים את אירועי Kubernetes של ה-Pod:

      kubectl get events -n NAMESPACE_NAME --field-selector involvedObject.kind=Pod,involvedObject.name=POD_NAME

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

      • ‫NAMESPACE_NAME: מרחב השמות של ה-Pod.
      • ‫POD_NAME: השם של ה-Pod.

      מחפשים אירועים עם אחת מהסיבות הבאות: ResizedPod (עדכון מוצלח במקום) או EvictedByVPA (חזרה ל יצירה מחדש).

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