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

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

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

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

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

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

תיאור של 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 או מסוף Cloud de Confiance :

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

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

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

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

   כניסה לדף Workloads

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

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

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

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

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

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

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

פתרון בעיות בהמלצות של 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

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

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

תסמינים:

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

הסיבה:

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

פתרון:

• בודקים את השדה 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 (חזרה לגרסה קודמת ויצירה מחדש).

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

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

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