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

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

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

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

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

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

• חשוב להשתמש באובייקטים של 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 .

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

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

תארו את HorizontalPodAutoscaler

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

kubectl describe hpa HPA_NAME -n NAMESPACE_NAME

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

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

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

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

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

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

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

המסוף

1. במסוף Google Cloud , נכנסים לדף חלונית האובייקטים.

   מעבר לחלונית האובייקטים

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: עומס העבודה (כמו פריסה) שה-HorizontalPodAutoscaler מוגדר לשנות את קנה המידה שלו.
  • ‫minReplicas ו-maxReplicas: הגדרות הרפליקה המינימליות והמקסימליות.
  • ‫metrics: המדדים שהוגדרו להתאמה לעומס (לדוגמה, שימוש ב-CPU או מדדים בהתאמה אישית).
• ‫status (המצב הפעיל של HorizontalPodAutoscaler):
  • ‫currentMetrics: הערכים האחרונים של המדדים שנצפו על ידי HorizontalPodAutoscaler.
  • ‫currentReplicas ו-desiredReplicas: המספר הנוכחי של ה-Pods והמספר שאליו רוצה HorizontalPodAutoscaler לבצע שינוי גודל.
  • ‫conditions: מציג את התקינות של HorizontalPodAutoscaler:
    • ‫AbleToScale: מציין אם האובייקט HorizontalPodAutoscaler יכול למצוא את היעד והמדדים שלו.
    • ‫ScalingActive: מציין אם ל-HorizontalPodAutoscaler יש הרשאה לחשב ולבצע שינוי קנה מידה.
    • ‫ScalingLimited: מציין אם HorizontalPodAutoscaler רוצה לשנות את קנה המידה אבל מוגבל על ידי ההגדרות של minReplicas או maxReplicas.

צפייה ביומני אירועים

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

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

  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 ובודקים את הפלט.

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

פתרון בעיות בהגדרת 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 בגלל בעיה בהגדרה, בקטע 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.

אי אפשר להשתמש בתווית המדד הזו

תסמינים

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

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 מטרגטים את אותו עומס עבודה

תסמינים

אין 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 מיותר שרוצים למחוק.

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

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

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

תסמינים

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

the HorizontalPodAutoscaler was unable to compute the replica count

מטרה

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

רזולוציה

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

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
# Multiple lines are omitted here
spec:
  containers:
  - name: example-container
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"

אי אפשר לאחזר מדדים של Pod

תסמינים

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

unable to fetch pod metrics for pod

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

מטרה

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

רזולוציה

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

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

תסמינים

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

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: השם של ה-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"} תואמים לתוויות של ה-Pod בדוגמה.

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

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

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

   kubectl apply -f MANIFEST_NAME
   

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

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

בקטעים הבאים מוסבר איך לפתור שגיאות שמתרחשות כש-HorizontalPodAutoscaler מנסה לתקשר עם API של מדדים או לשלוח שאילתה ל-backend של מדדים.

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

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

תסמינים

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

• ערך המדד מוצג כ-<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 והערך True בעמודה Available. לדוגמה:

   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‏ 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.

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 שמשויך למתאם המדדים שפרסתם. השירות הזה הוא השירות שמצאתם בשלב הקודם. השירות הזה חושף את הפונקציונליות של המתאם לחלקים אחרים של האשכול, כולל שרת ה-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
        

        בודקים את כללי המדיניות כדי לוודא שהם מאפשרים תעבורת נתונים נכנסת (ingress) ממישור הבקרה או משרת ה-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, כדי לוודא שהמדד קיים ושהשם והתוויות שלו נכונים.

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

תסמינים

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

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. במסוף Google Cloud , אפשר לראות את התקינות והסטטוס של האשכול.

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

         מעבר אל Kubernetes clusters

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

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

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

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

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

   אם הסטטוס של ה-Pod הוא כל דבר אחר מלבד Running, או אם יש לו מספר גבוה של הפעלות מחדש, צריך לבדוק את ה-Pod כדי למצוא את שורש הבעיה. טיפים לפתרון בעיות אפשר למצוא במאמר Debug Pods (ניפוי באגים ב-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 במהלך התקופה שבה התרחשו האזהרות של HorizontalPodAutoscaler.
4. בדיקה אם יש שגיאות: בודקים ביומנים של האפליקציה מאותו פרק זמן אם יש שגיאות מפורשות שקשורות לפליטת מדדים, כמו כשלים בחיבור, פרטי כניסה לא תקינים או בעיות בפורמט.

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

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

‫HorizontalPodAutoscaler תקין אבל לא משנה את קנה המידה

תסמינים

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

מטרה

יש כמה סיבות אפשריות לכך:

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

רזולוציה

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

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

HorizontalPodAutoscaler לא מצליח להקטין את קנה המידה

תסמינים

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

מטרה

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

• שימוש בכמה מדדים: ה-HorizontalPodAutoscaler מבצע שינוי גודל על סמך המדד שדורש את מספר העותקים המשוכפלים הגבוה ביותר. אם יש כמה מדדים, עומס העבודה לא יצומצם אלא אם כל המדדים יצביעו על כך שצריך פחות רפליקות. מדד אחד שמצריך מספר גבוה של רפליקות מונע את ההקטנה, גם אם ערכי המדדים האחרים נמוכים.
• מדדים לא זמינים: אם מדד כלשהו לא זמין (לרוב מוצג כ-<unknown>), המערכת HorizontalPodAutoscaler מסרבת באופן שמרני לצמצם את היקף העבודה. התכונה לא יכולה לקבוע אם המדד חסר כי השימוש הוא אפס או כי צינור המדדים לא תקין. הבעיה הזו נפוצה במדדים מותאמים אישית שמבוססים על קצב (למשל messages_per_second), שיכולים להפסיק לדווח על נתונים כשאין פעילות. כתוצאה מכך, HorizontalPodAutoscaler רואה את המדד כלא זמין ועוצר את פעולות ההקטנה.
• ‫Scale-down delay from scaling policy: השדה behavior של HorizontalPodAutoscaler מאפשר להגדיר מדיניות שינוי גודל. מדיניות ברירת המחדל לצמצום אנכית (scale down) כוללת חלון ייצוב של 300 שניות (חמש דקות). במהלך החלון הזה, ה-HorizontalPodAutoscaler לא יקטין את מספר הרפליקות, גם אם ערכי המדדים ירדו מתחת לסף היעד. החלון הזה מונע תנודות מהירות, אבל הוא עלול להאט את הצמצום האנכי בהשוואה למה שמצפים.

רזולוציה

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

1. כדי לאבחן בעיות שקשורות למדדים מרובים או למדדים לא זמינים:

   kubectl describe hpa HPA_NAME -n NAMESPACE_NAME
   

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

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

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

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

פתרון בעיות בהתאמה אוטומטית לעומס (automatic scaling) של עומסי עבודה ב-GKE לאפס ומאפס באמצעות HPA

בקטע הזה מוסבר איך לאבחן בעיות בהגדרת עומסי עבודה לשינוי גודל מאפס ואל אפס באמצעות HPA ‏ (minReplicas: 0) ב-GKE בגרסה 1.37 ואילך.

עומס העבודה לא מצטמצם לאפס

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

1. בודקים את minReplicas: מוודאים שצמד הערכים של השדה minReplicas: 0 מוגדר במניפסט של HorizontalPodAutoscaler.
2. בדיקת סוגי המדדים: אם ה-HPA משתמש רק במדדים של מעבד או זיכרון (Resource), הוא לא יכול להגדיל את קנה המידה לאפס. צריך להגדיר לפחות מדד אחד של External או Object.
3. בדיקת כמה מדדים: ה-HPA מבצע שינוי גודל על סמך המדד שדורש את מספר העותקים הגבוה ביותר. אם מגדירים כמה מדדים, עומס העבודה לא יצטמצם לאפס אלא אם כל מדד מנוטר יקבל את הערך אפס.
4. המתנה לחלון הייצוב של הקטנת קנה המידה: כברירת מחדל, GKE ממתין חמש דקות (scaleDown.stabilizationWindowSeconds: 300) של אפס ביקוש רציף לפני הקטנת קנה המידה מרפליקה אחת לאפס רפליקות.
5. בדיקה אם יש מדדים לא זמינים: אם הערך של מדד כלשהו מוצג בתור <unknown>, ה-HPA משהה את פעולות הצמצום האנכי כדי למנוע הקטנה מוקדמת מדי. מידע נוסף זמין במאמר פתרון בעיות: Horizontal Pod Autoscaler (HPA) לא מצליח לצמצם אנכית בהתאם לעומס את קבוצת ה-Pod.

עומס העבודה לא מתרחב אנכית מאפס

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

1. בדיקת ה-HorizontalPodAutoscaler: מריצים את הפקודה kubectl describe hpa HPA_NAME ובודקים את הקטעים הבאים בפלט:

   • בקטע "מדדים": מוודאים שערך המדד גדול מאפס ולא מוצג כ-<unknown>. אם המדד חסר או לא מתעדכן, צריך לוודא שהמקור החיצוני (כמו Pub/Sub) מפרסם אירועים ושהם מתקבלים ב-Cloud Monitoring.
   • הקטע "תנאים":
     • מצב תקין של אפס רפליקות: מוודאים שהתנאים מציגים את AbleToScale: True, ScalingActive: True ו-ScaledToZero: True (עם הסיבה ScaledToZero). במצב הזה, GKE מבצע התאמה אוטומטית לעומס כשהביקוש עולה.
     • זוהתה עקיפה חיצונית: בודקים אם הערך של התנאי ScalingActive הוא False עם הסיבה ScalingDisabledExternalScaleToZero או הסיבה ScalingDisabledReplicaCountZero, שמציינת שעומס העבודה הוקטן ידנית לאפס. לדוגמה, אם עומס העבודה הוגדל ידנית באמצעות הפקודה kubectl scale, ההתאמה האוטומטית של קנה המידה מושהית כדי למנוע שינויים סותרים.

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

     kubectl scale deployment DEPLOYMENT_NAME --replicas=1
     

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

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

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

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