‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

הצגת אירועים ומדדים של המידרוג האוטומטי באשכול

Standard

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

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

יומני אירועים של הרשאות גישה: יומני אירועים ב-Cloud Logging שמספקים מידע מפורט על פעולות ספציפיות של התאמה לעומס, כמו החלטות לגבי scaleUp, scaleDown ו-noScaleUp. האירועים שמתוארים במדריך הזה נפרדים מאירועי Kubernetes שנוצרים על ידי הכלי להתאמה לעומס (autoscaler) של האשכול.
מדדים של Cloud Monitoring: מדדים מצטברים של סדרות זמן שמספקים מגמות ברמה גבוהה לגבי ניסיונות הקצאה של צמתים, כשלים ו-Pods בהמתנה ב-ComputeClasses.

דרישות

כדי לראות אירועים של המידרוג האוטומטי, צריך להפעיל את Cloud Logging באשכול. האירועים לא יופקו אם הרישום ביומן מושבת.

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

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

מפעילים את ממשק ה-API של Google Kubernetes Engine.

הפעלת Google Kubernetes Engine API

כדי להשתמש ב-Google Cloud CLI למשימה הזו, מתקינים ואז מאתחלים את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שבגרסאות קודמות של ה-CLI של gcloud אי אפשר להריץ את הפקודות שבמסמך הזה.
הערה: אם ה-CLI של gcloud כבר מותקן, צריך להגדיר את המאפיין compute/region. אם אתם משתמשים בעיקר באשכולות אזוריים, הגדירו במקום זאת את compute/zone. אם מגדירים מיקום ברירת מחדל, אפשר להימנע משגיאות ב-CLI של gcloud כמו One of [--zone, --region] must be supplied: Please specify location. יכול להיות שתצטרכו לציין את המיקום בפקודות מסוימות אם המיקום של האשכול שונה מברירת המחדל שהגדרתם.

מוודאים שיש לכם אשכול קיים מסוג Standard. אם אין לכם אשכול, צרו אשכול Standard.

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

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

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

כדי לראות את היומנים:

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

כניסה לדף Kubernetes Clusters
בוחרים את שם האשכול כדי להציג את הדף Cluster Details.
בדף Cluster Details, לוחצים על הכרטיסייה Logs.
בכרטיסייה Logs (יומנים), לוחצים על הכרטיסייה Autoscaler Logs (יומני שינוי גודל אוטומטי) כדי לראות את היומנים.
(אופציונלי) כדי להחיל מסננים מתקדמים יותר ולצמצם את התוצאות, לוחצים על הלחצן עם החץ בצד שמאל של הדף כדי לראות את היומנים בכלי Logs Explorer.

הצגת התראות לגבי אירועי חשיפה

כדי לראות את ההתראות על אירועי החשיפה בדף Google Kubernetes Engine, מבצעים את הפעולות הבאות:

נכנסים לדף Google Kubernetes Engine במסוף Google Cloud :

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

מעקב אחרי סטטוס Pod בהמתנה באמצעות Cloud Monitoring

בנוסף לאירועי חשיפה, המידרוג האוטומטי באשכול GKE, שזמין בגרסה 1.37 ואילך, מייצא את המדד kubernetes.io/autoscaler/cluster_pending_pods_per_ccc בזמן אמת אל Cloud Monitoring. המדד הזה מספק ספירה של Pods במצב Pending, כפי שנראו ועובדו על ידי ה-autoscaler של האשכול, והוא זמין לסוג המשאב במעקב k8s_entity.

המדד הזה שימושי במיוחד כדי להבין את הביקוש ל-ComputeClasses שונים.

תוויות של מקשים

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

‫resource.labels.entity_type: סוג הישות, שתמיד יהיה ComputeClass במדד הזה.
‫resource.labels.entity_name: השם של ComputeClass שה-Pods מבקשים. ריק ("") לפודים בלי ComputeClass ספציפי.
‫metric.labels.reason: השלב הנוכחי של ה-Pod בתצוגה של הכלי לשינוי גודל האשכול (unprocessed, ‏ provisioning_in_progress, ‏ unable_to_provision,‏ no_action_taken).
‫metric.labels.type: סוג ה-Pod ‏ (system_pod או user_pod).

תרחישים לדוגמה

בדוגמאות הבאות אפשר לראות איך לשלוח שאילתות לגבי המדד הזה באמצעות PromQL:

מעקב אחרי הביקוש להגדלת קנה המידה לכל ComputeClass:
```
sum by (entity_name) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    type="user_pod"
  }
)
```
השאילתה הזו מציגה את סך ה-Pods של משתמשים בהמתנה לכל ComputeClass, כדי להראות איפה נמצא הביקוש הנוכחי להרחבת הקיבולת.
מעקב אחרי הגדלות שחסמתם:
```
sum by (entity_name, type) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    reason="unable_to_provision"
  }
)
```
השאילתה הזו עוזרת לזהות במהירות אם יש בעיות ב-ComputeClasses שבהן המידרוג האוטומטי באשכול לא יכול להקצות צמתים.

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

מעקב אחרי הקצאת צמתים

המדדים הבאים של Cloud Monitoring זמינים בגרסה 1.37 ואילך של GKE, ומספקים הרשאות גישה לפעילויות הקצאת הצמתים של המידרוג האוטומטי באשכול, בחלוקה לפי ComputeClasses. המדדים האלה משתמשים בסוג המשאב במעקב k8s_entity. בסוג המשאב הזה, הערך של התווית resource.labels.entity_type הוא ComputeClass, והערך של התווית resource.labels.entity_name הוא השם של ה-ComputeClass שמגדיר את קבוצת הצמתים שמוקצים. מחרוזת ריקה ("") בתווית resource.labels.entity_name מציינת שקבוצת הצמתים שמוקצית לא משויכת ל-ComputeClass ספציפי.

שימוש במדדים וביומנים ביחד

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

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

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

המדד kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc עוקב אחרי התדירות שבה המידרוג האוטומטי מנסה להוסיף צמתים לקבוצת צמתים שמוגדרת על ידי ComputeClass ספציפי. מחרוזת ריקה ("") בתווית resource.labels.entity_name מציינת שפעילות ההקצאה לא משויכת ל-ComputeClass ספציפי.

בדוגמה הבאה של PromQL, מתבצע מעקב אחרי פעילות הגדלת הנפח לכל ComputeClass:

sum by (entity_name) (
  increase(
    kubernetes_io:autoscaler_cluster_node_provisioning_attempts_count_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass"
    }[5m]
  )
)

מעקב אחרי כשלים בהקצאת צמתים

kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc המדד הזה מספק את מספר הניסיונות הכושלים להגדלת הקיבולת. אפשר להשתמש במדד הזה כדי לזהות צווארי בקבוק בתשתית או הגדרות שגויות.

התוויות החשובות למדד הזה כוללות:

‫resource.labels.entity_name: השם של ComputeClass שמגדיר את קבוצת הצמתים שהקצאת המשאבים שלה נכשלה. הערך ריק ("") אם קבוצת הצמתים לא מוגדרת על ידי ComputeClass ספציפי.
‫metric.labels.reason: קוד המחרוזת שמייצג את סיבת הכישלון.

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

sum by (reason, entity_name) (
  increase(
    kubernetes_io:autoscaler_cluster_node_provisioning_failed_attempts_count_per_ccc{
      monitored_resource="k8s_entity",
      entity_type="ComputeClass"
    }[1h]
  )
)

סיבות לכשל (`metric.labels.reason`)

התווית metric.labels.reason במדד kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc מספקת קוד מחרוזת שמציין את הסיבה לכשל בהקצאת הצומת. במדריך לפתרון בעיות פירוש סיבות הכישלון מופיע הסבר מפורט על כל סיבה ופעולות אפשריות לתיקון.

סוגי אירועים

כל האירועים המתועדים הם בפורמט JSON, ואפשר למצוא אותם בשדה jsonPayload של רשומה ביומן. כל חותמות הזמן באירועים הן חותמות זמן של מערכת UNIX בשניות.

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

סוג אירוע	תיאור
`status`	מתרחש מדי פעם ומתאר את הגודל של כל מאגרי הצמתים שמותאמים אוטומטית לעומס ואת גודל היעד של כל מאגרי הצמתים שמותאמים אוטומטית לעומס, כפי שנצפה על ידי המידרוג האוטומטי של האשכול.
`scaleUp`	מתרחש כשהמידרוג האוטומטי של האשכול מגדיל את האשכול.
`scaleDown`	מתרחש כשהמידרוג האוטומטי של האשכול מקטין את האשכול.
`eventResult`	מתרחש כשאירוע scaleUp או scaleDown מסתיים בהצלחה או נכשל.
`nodePoolCreated`	מתרחש כשמגדירים את המאפיין "מידרוג אוטומטי" עם הקצאת צמתים אוטומטית (NAP), ונוצר מאגר צמתים חדש.
`nodePoolDeleted`	מתרחש כשמחיקה של מאגר צמתים מתבצעת על ידי מידרוג אוטומטי של אשכולות, עם הקצאת צמתים אוטומטית (NAP) מופעלת.
`noScaleUp`	מתרחש כשיש באשכול פודים שלא ניתן לתזמן, והמידרוג האוטומטי של האשכול לא יכול להגדיל את האשכול כדי להכיל את הפודים.
`noScaleDown`	מתרחש כשיש צמתים שנחסמים ממחיקה על ידי Cluster Autoscaler.

אירוע שקשור לסטטוס

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

דוגמה

הדוגמה הבאה ליומן מציגה אירוע status:

{
  "status": {
    "autoscaledNodesCount": 4,
    "autoscaledNodesTarget": 4,
    "measureTime": "1582898536"
  }
}

אירוע ScaleUp

אירוע scaleUp מופעל כשמגדילים את האשכול באמצעות המידרוג האוטומטי. התכונה להתאמה אוטומטית לעומס מגדילה את הגודל של מאגרי הצמתים באשכול על ידי הגדלת קבוצות המופעים המנוהלים (MIG) הבסיסיות של מאגרי הצמתים. למידע נוסף על אופן הפעולה של הגדלת קנה המידה, קראו את השאלה How does scale up work?‎ במאמר השאלות הנפוצות בנושא מידרוג אוטומטי של אשכולות Kubernetes.

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

רשימת הפודים שמפעילים את ההתראה מקוצרת ל-50 רשומות שרירותיות. המספר בפועל של ה-Pods שהפעילו את הטריגר מופיע בשדה triggeringPodsTotalCount.

דוגמה

הדוגמה הבאה ליומן מציגה אירוע scaleUp:

{
  "decision": {
    "decideTime": "1582124907",
    "eventId": "ed5cb16d-b06f-457c-a46d-f75dcca1f1ee",
    "scaleUp": {
      "increasedMigs": [
        {
          "mig": {
            "name": "test-cluster-default-pool-a0c72690-grp",
            "nodepool": "default-pool",
            "zone": "us-central1-c"
          },
          "requestedNodes": 1
        }
      ],
      "triggeringPods": [
        {
          "controller": {
            "apiVersion": "apps/v1",
            "kind": "ReplicaSet",
            "name": "test-85958b848b"
          },
          "name": "test-85958b848b-ptc7n",
          "namespace": "default"
        }
      ],
      "triggeringPodsTotalCount": 1
    }
  }
}

אירוע ScaleDown

scaleDown אירוע מופעל כשכלי המידרוג האוטומטי של האשכול מצמצם את האשכול. למידע נוסף על אופן הפעולה של צמצום אנכי בהתאם לעומס, קראו את השאלה How does scale down work?‎ במאמר השאלות הנפוצות בנושא מידרוג אוטומטי של אשכולות Kubernetes.

השדות cpuRatio ו-memRatio מתארים את ניצול המעבד (CPU) וניצול הזיכרון של הצומת, באחוזים. הניצול הזה הוא סכום של בקשות Pod חלקי הזיכרון שניתן להקצאה לצומת, ולא ניצול אמיתי.

רשימת הפודים שפונו נחתכת ל-50 רשומות שרירותיות. המספר בפועל של ה-Pods שהוצאו מופיע בשדה evictedPodsTotalCount.

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

resource.type="k8s_cluster" \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
log_id("container.googleapis.com/cluster-autoscaler-visibility") \
( "decision" NOT "noDecisionStatus" )

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

‫CLUSTER_NAME: שם האשכול.
‫COMPUTE_REGION: האזור של האשכול ב-Compute Engine, למשל us-central1.

דוגמה

הדוגמה הבאה ליומן מציגה אירוע scaleDown:

{
  "decision": {
    "decideTime": "1580594665",
    "eventId": "340dac18-8152-46ff-b79a-747f70854c81",
    "scaleDown": {
      "nodesToBeRemoved": [
        {
          "evictedPods": [
            {
              "controller": {
                "apiVersion": "apps/v1",
                "kind": "ReplicaSet",
                "name": "kube-dns-5c44c7b6b6"
              },
              "name": "kube-dns-5c44c7b6b6-xvpbk"
            }
          ],
          "evictedPodsTotalCount": 1,
          "node": {
            "cpuRatio": 23,
            "memRatio": 5,
            "mig": {
              "name": "test-cluster-default-pool-c47ef39f-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-f"
            },
            "name": "test-cluster-default-pool-c47ef39f-p395"
          }
        }
      ]
    }
  }
}

אפשר גם לראות את האירוע scale-down בצמתים שבהם לא פועל עומס עבודה (בדרך כלל רק פודים של המערכת שנוצרו על ידי DaemonSets).

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

resource.type="k8s_cluster" \
resource.labels.project_id=PROJECT_ID \
resource.labels.location=COMPUTE_REGION \
resource.labels.cluster_name=CLUSTER_NAME \
severity>=DEFAULT \
logName="projects/PROJECT_ID/logs/events" \
("Scale-down: removing empty node")

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

PROJECT_ID: מזהה הפרויקט.
‫CLUSTER_NAME: שם האשכול.
‫COMPUTE_REGION: האזור של האשכול ב-Compute Engine, למשל us-central1.

אירוע EventResult

אירוע eventResult מופק כשאירוע scaleUp או scaleDown מסתיים בהצלחה או נכשל. האירוע הזה מכיל רשימה של מזהי אירועים (מהשדה eventId באירועי scaleUp או scaleDown), יחד עם הודעות שגיאה. הודעת שגיאה ריקה מציינת שהאירוע הושלם בהצלחה. רשימה של אירועי eventResult נצברת בשדה results.

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

דוגמה

הדוגמה הבאה מציגה אירוע eventResult ביומן:

{
  "resultInfo": {
    "measureTime": "1582878896",
    "results": [
      {
        "eventId": "2fca91cd-7345-47fc-9770-838e05e28b17"
      },
      {
        "errorMsg": {
          "messageId": "scale.down.error.failed.to.delete.node.min.size.reached",
          "parameters": [
            "test-cluster-default-pool-5c90f485-nk80"
          ]
        },
        "eventId": "ea2e964c-49b8-4cd7-8fa9-fefb0827f9a6"
      }
    ]
  }
}

אירוע NodePoolCreated

אירוע nodePoolCreated נוצר כשמגדירים את הכלי למידרוג אוטומטי של אשכולות עם הקצאת צמתים אוטומטית כדי ליצור מאגר צמתים חדש. האירוע הזה מכיל את השם של מאגר הצמתים שנוצר ורשימה של קבוצות ה-MIG שמתחתיו. אם מאגר הצמתים נוצר בגלל אירוע scaleUp, השדה triggeringScaleUpId כולל את הערך eventId של אירוע ה-scaleUp המתאים.

דוגמה

בדוגמה הבאה של יומן מוצג אירוע nodePoolCreated:

{
  "decision": {
    "decideTime": "1585838544",
    "eventId": "822d272c-f4f3-44cf-9326-9cad79c58718",
    "nodePoolCreated": {
      "nodePools": [
        {
          "migs": [
            {
              "name": "test-cluster-nap-n1-standard--b4fcc348-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-f"
            },
            {
              "name": "test-cluster-nap-n1-standard--jfla8215-grp",
              "nodepool": "nap-n1-standard-1-1kwag2qv",
              "zone": "us-central1-c"
            }
          ],
          "name": "nap-n1-standard-1-1kwag2qv"
        }
      ],
      "triggeringScaleUpId": "d25e0e6e-25e3-4755-98eb-49b38e54a728"
    }
  }
}

אירוע NodePoolDeleted

nodePoolDeleted אירוע נפלט כשמחקתם מאגר צמתים באמצעות Cluster Autoscaler עם הקצאת צמתים אוטומטית מופעלת.

דוגמה

הדוגמה הבאה ליומן מציגה אירוע nodePoolDeleted:

{
  "decision": {
    "decideTime": "1585830461",
    "eventId": "68b0d1c7-b684-4542-bc19-f030922fb820",
    "nodePoolDeleted": {
      "nodePoolNames": [
        "nap-n1-highcpu-8-ydj4ewil"
      ]
    }
  }
}

אירוע NoScaleUp

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

אירועי noScaleUp הם אירועים שנעשה בהם מאמץ מרבי, כלומר הם לא מכסים את כל הסיבות האפשריות לכך שהכלי להתאמה אוטומטית של קנה המידה של האשכול לא יכול לבצע סילומיות אנכית (scale up).
אירועי noScaleUp מוגבלים כדי להגביל את נפח היומן שנוצר. כל סיבה מתמשכת מדווחת רק כל כמה דקות.
כל הסיבות יכולות להתחלק באופן שרירותי בין כמה אירועים. לדוגמה, אין ערובה לכך שכל הסיבות לדחיית MIG עבור קבוצת Pod יחידה יופיעו באותו אירוע.
רשימת קבוצות ה-Pod שלא טופלו נחתכת ל-50 רשומות שרירותיות. המספר בפועל של קבוצות Pod שלא טופלו מופיע בשדה unhandledPodGroupsTotalCount.

שדות של סיבות

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

‫reason: סיבה גלובלית לכך שהמידרוג האוטומטי של האשכול לא יכול להגדיל את קנה המידה. פרטים נוספים מופיעים בקטע הסיבות ברמה העליונה ל-NoScaleUp.
napFailureReason: סיבה גלובלית שמונעת מהמידרוג האוטומטי של האשכול להקצות מאגרי צמתים נוספים (לדוגמה, הקצאת צמתים אוטומטית מושבתת). פרטים נוספים זמינים בקטע סיבות להקצאת צמתים אוטומטית (NAP) של צומת ברמה העליונה NoScaleUp.
‫skippedMigs[].reason: מידע על הסיבה לדילוג על קבוצת MIG מסוימת. הכלי Cluster autoscaler מדלג על קבוצות MIG מסוימות ולא מתייחס אליהן כשהוא מנסה להגדיל את מספר ה-Pods (לדוגמה, כי הוספת צומת נוסף תחרוג ממגבלות המשאבים של האשכול). פרטים נוספים זמינים בקטע סיבות ברמת ה-MIG לאירועי NoScaleUp.
‫unhandledPodGroups: מכיל מידע על הסיבה לכך שקבוצה מסוימת של פודים שלא ניתן לתזמן לא מפעילה הרחבה. התרמילים מקובצים לפי הבקר המיידי שלהם. פודים ללא בקר נמצאים בקבוצות משלהם. כל קבוצת Pods מכילה Pod לדוגמה ומספר Pods בקבוצה, וגם את הסיבות הבאות:
- ‫napFailureReasons: הסיבות לכך שהמידרוג האוטומטי של אשכולות לא יכול להקצות מאגר צמתים חדש כדי להכיל את קבוצת ה-Pods הזו (לדוגמה, ל-Pods יש אילוצי אפיניות). פרטים נוספים זמינים בקטע סיבות ברמת ה-Pod להקצאת צמתים אוטומטית (NAP) ללא הגדלת קנה מידה.
- ‫rejectedMigs[].reason: הסיבות לכך שהמידרוג האוטומטי של האשכול לא יכול להגדיל את קבוצת ה-MIG הספציפית כדי להכיל את קבוצת ה-Pods הזו (לדוגמה, הצומת של ה-MIG קטן מדי בשביל ה-Pods). פרטים נוספים זמינים בקטע סיבות ברמת ה-MIG לאירועי NoScaleUp.

דוגמה

הדוגמה הבאה ליומן מציגה אירוע noScaleUp:

{
  "noDecisionStatus": {
    "measureTime": "1582523362",
    "noScaleUp": {
      "skippedMigs": [
        {
          "mig": {
            "name": "test-cluster-nap-n1-highmem-4-fbdca585-grp",
            "nodepool": "nap-n1-highmem-4-1cywzhvf",
            "zone": "us-central1-f"
          },
          "reason": {
            "messageId": "no.scale.up.mig.skipped",
            "parameters": [
              "max cluster cpu limit reached"
            ]
          }
        }
      ],
      "unhandledPodGroups": [
        {
          "napFailureReasons": [
            {
              "messageId": "no.scale.up.nap.pod.zonal.resources.exceeded",
              "parameters": [
                "us-central1-f"
              ]
            }
          ],
          "podGroup": {
            "samplePod": {
              "controller": {
                "apiVersion": "v1",
                "kind": "ReplicationController",
                "name": "memory-reservation2"
              },
              "name": "memory-reservation2-6zg8m",
              "namespace": "autoscaling-1661"
            },
            "totalPodCount": 1
          },
          "rejectedMigs": [
            {
              "mig": {
                "name": "test-cluster-default-pool-b1808ff9-grp",
                "nodepool": "default-pool",
                "zone": "us-central1-f"
              },
              "reason": {
                "messageId": "no.scale.up.mig.failing.predicate",
                "parameters": [
                  "NodeResourcesFit",
                  "Insufficient memory"
                ]
              }
            }
          ]
        }
      ],
      "unhandledPodGroupsTotalCount": 1
    }
  }
}

אירוע NoScaleDown

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

צמתים שלא ניתן להסיר כי רמת הניצול שלהם גבוהה לא נכללים באירועי noScaleDown.
אירועי NoScaleDown הם אירועים מסוג Best effort, כלומר הם לא מכסים את כל הסיבות האפשריות לכך שהכלי להתאמה אוטומטית של אשכולות לא יכול לבצע הפחתה בהתאם לעומס.
אירועי NoScaleDown מוגבלים כדי להגביל את נפח היומן שנוצר. כל סיבה מתמשכת תופק רק כל כמה דקות.
רשימת הצמתים מקוצרת ל-50 רשומות שרירותיות. המספר בפועל של הצמתים מופיע בשדה nodesTotalCount.

שדות של סיבות

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

‫reason: סיבה כללית לכך שהמידרוג האוטומטי של האשכול לא יכול לצמצם את האשכול (לדוגמה, תקופת השהיה אחרי הרחבה שבוצעה לאחרונה). לפרטים נוספים, עיינו בקטע הסיבות ברמה העליונה ל-NoScaleDown.
‫nodes[].reason: מציין את הסיבות הספציפיות לכל צומת שבגללן לא ניתן למחק צומת מסוים באמצעות שינוי גודל אוטומטי של האשכול (לדוגמה, אין מקום להעביר את ה-Pods של הצומת). פרטים נוספים מופיעים בקטע סיבות ברמת הצומת ל-NoScaleDown.

דוגמה

הדוגמה הבאה ליומן מציגה אירוע noScaleDown:

{
  "noDecisionStatus": {
    "measureTime": "1582858723",
    "noScaleDown": {
      "nodes": [
        {
          "node": {
            "cpuRatio": 42,
            "mig": {
              "name": "test-cluster-default-pool-f74c1617-grp",
              "nodepool": "default-pool",
              "zone": "us-central1-c"
            },
            "name": "test-cluster-default-pool-f74c1617-fbhk"
          },
          "reason": {
            "messageId": "no.scale.down.node.no.place.to.move.pods"
          }
        }
      ],
      "nodesTotalCount": 1,
      "reason": {
        "messageId": "no.scale.down.in.backoff"
      }
    }
  }
}

Messages

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

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

שגיאות ב-ScaleUp

הודעות השגיאה של אירועי scaleUp מופיעות באירוע eventResult התואם, בשדה resultInfo.results[].errorMsg.

כשפעולת הגדלה נכשלת כי היא חורגת מהמכסה, זו שגיאה ביצירת צומת שמפעילה תקופת השהיה מעריכית לפני ניסיון חוזר (exponential backoff) של המערכת, שיכולה להימשך עד 30 דקות. מידע נוסף זמין במאמר תקופות השהיה.

הודעה	פרטים	פרמטרים	צמצום הפגיעה
`"scale.up.error.out.of.resources"`	שגיאות שקשורות למשאבים מתרחשות כשמנסים לבקש משאבים חדשים בתחום שבו אי אפשר לספק את הבקשה בגלל חוסר זמינות של משאב Compute Engine, כמו GPU או CPU.	מזהי ה-MIG שנכשלו.	פועלים לפי השלבים לפתרון בעיות שקשורות לזמינות המשאבים במאמרי העזרה של Compute Engine.
`"scale.up.error.quota.exceeded"`	האירוע scaleUp נכשל כי לא ניתן היה להגדיל חלק מקבוצות ה-MIG, בגלל חריגה מהמכסה של Compute Engine.	מזהי ה-MIG שנכשלו.	בודקים בכרטיסייה Errors של קבוצת ה-MIG במסוף Google Cloud כדי לראות איזו מכסה חורגת. אחרי שתדעו איזו מכסה חרגה, פעלו לפי ההוראות כדי לבקש הגדלה של המכסה.
`"scale.up.error.waiting.for.instances.timeout"`	הגדלה של קבוצת מופעי מכונה מנוהלים נכשלה כי הזמן הקצוב לתפוגה חלף.	מזהי ה-MIG שנכשלו.	אם המופעים מופעלים אבל לא נרשמים במישור הבקרה, פועלים לפי השלבים לפתרון בעיות ברישום מופעים. ההודעה הזו אמורה להיות זמנית. אם הבעיה נמשכת, פנו ל-Cloud Customer Care כדי לבדוק את הנושא.
`"scale.up.error.ip.space.exhausted"`	אי אפשר להגדיל את קבוצת המכונות כי נגמרו כתובות ה-IP במופעים של חלק מקבוצות המכונות המנוהלות. המשמעות היא שאין באשכול מספיק כתובות IP פנויות להוספת צמתים או Pods חדשים.	מזהי ה-MIG שנכשלו.	פועלים לפי השלבים לפתרון בעיות במאמר בנושא אין מספיק מקום פנוי לכתובות IP עבור Pods.
`"scale.up.error.service.account.deleted"`	אי אפשר להגדיל את המכסה כי חשבון השירות נמחק.	מזהי ה-MIG שנכשלו.	נסו לבטל מחיקה של חשבון השירות. אם התהליך לא מצליח, פנו ל-Cloud Customer Care כדי לבדוק את הבעיה.

הסיבות לאירוע noScaleUp

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

סיבות ברמה העליונה ל-NoScaleUp

הודעות הסיבה ברמה העליונה לאירועי noScaleUp מופיעות בשדה noDecisionStatus.noScaleUp.reason. ההודעה מכילה סיבה ברמה העליונה לכך שהמידרוג האוטומטי של האשכול לא יכול להגדיל את האשכול.

הודעה	פרטים	צמצום הפגיעה
`"no.scale.up.in.backoff"`	אין הגדלה כי ההגדלה נמצאת בתקופת השהיה (חסימה זמנית). ההודעה הזו יכולה להופיע במהלך אירועי הגדלה עם מספר גדול של Pods.	ההודעה הזו אמורה להיות זמנית. בדקו את השגיאה הזו אחרי כמה דקות. אם ההודעה ממשיכה להופיע, פנו ל-Cloud Customer Care כדי לבדוק את הבעיה.

סיבות ברמה העליונה לכך שלא בוצעה הקצאת צמתים אוטומטית (NAP) להגדלת הנפח (NoScaleUp)

הודעות לגבי הקצאת משאבים אוטומטית של צומת ברמה העליונה עבור אירועי noScaleUp מופיעות בשדה noDecisionStatus.noScaleUp.napFailureReason. ההודעה מכילה סיבה ברמה העליונה לכך שאין אפשרות להקצות מאגרי צמתים חדשים באמצעות התכונה 'שינוי גודל אוטומטי של אשכולות'.

הודעה פרטים צמצום הפגיעה

הודעה	פרטים	צמצום הפגיעה
`"no.scale.up.nap.disabled"`	לא הייתה אפשרות להגדיל את הקיבולת של הקצאת ההרשאות האוטומטית של הצמתים כי היא לא הופעלה ברמת האשכול. אם הקצאת צמתים אוטומטית (NAP) מושבתת, צמתים חדשים לא יוקצו אוטומטית אם ל-Pod בהמתנה יש דרישות שלא ניתן לספק על ידי אף מאגר צמתים קיים.	בודקים את הגדרות האשכול ושוקלים להפעיל הקצאת צמתים אוטומטית.

"no.scale.up.nap.disabled"

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

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

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

סיבות ברמת ה-MIG ל-NoScaleUp

הודעות עם סיבות ברמת ה-MIG לאירועים מסוג noScaleUp מופיעות בשדות noDecisionStatus.noScaleUp.skippedMigs[].reason ו-noDecisionStatus.noScaleUp.unhandledPodGroups[].rejectedMigs[].reason. ההודעה מכילה את הסיבה לכך שהמידרוג האוטומטי של האשכול לא יכול להגדיל את קבוצת ה-MIG הספציפית.

הודעה	פרטים	פרמטרים	צמצום הפגיעה
`"no.scale.up.mig.skipped"`	אי אפשר להגדיל את קבוצת המכונות המנוהלת כי המערכת דילגה עליה במהלך הסימולציה.	הסיבות לכך שהמערכת דילגה על ה-MIG (לדוגמה, חסרה דרישה של Pod).	בודקים את הפרמטרים שכלולים בהודעת השגיאה ומטפלים בסיבה שבגללה המערכת דילגה על קבוצת ה-MIG.
`"no.scale.up.mig.failing.predicate"`	אי אפשר להגדיל את מאגר הצמתים כי הפרדיקט של התזמון נכשל ב-Pods בהמתנה.	שם התנאי שנכשל והסיבות לכך.	בודקים את הדרישות של Pod, כמו כללי אפיניות, taints או tolerations ודרישות משאבים.

סיבות לכך שלא בוצעה הקצאת צמתים אוטומטית (NAP) ברמת קבוצת Pod-ים (NoScaleUp)

הודעות הסיבה להקצאת צמתים אוטומטית ברמת קבוצת ה-Pod לאירועי noScaleUp מופיעות בשדה noDecisionStatus.noScaleUp.unhandledPodGroups[].napFailureReasons[]. ההודעה מכילה סיבה לכך שהכלי לשינוי גודל האשכול לא יכול להקצות מאגר חדש של צמתים כדי לתזמן קבוצת Pod מסוימת.

הודעה	פרטים	פרמטרים	צמצום הפגיעה
`"no.scale.up.nap.pod.gpu.no.limit.defined"`	הקצאת צמתים אוטומטית לא הצליחה להקצות קבוצת צמתים כי לפוד בהמתנה יש בקשת GPU, אבל מגבלות המשאבים של ה-GPU לא מוגדרות ברמת האשכול.	סוג ה-GPU המבוקש.	בודקים את בקשת ה-GPU של ה-Pod בהמתנה, ומעדכנים את ההגדרות של מגבלות ה-GPU להקצאת צמתים אוטומטית ברמת האשכול.
`"no.scale.up.nap.pod.gpu.type.not.supported"`	התכונה הקצאת צמתים אוטומטית (NAP) לא הקצתה קבוצת צמתים ל-Pod כי יש בו בקשות לסוג GPU לא ידוע.	סוג ה-GPU המבוקש.	בודקים את ההגדרות של ה-Pod בהמתנה לסוג ה-GPU כדי לוודא שהן תואמות לסוג GPU נתמך.
`"no.scale.up.nap.pod.zonal.resources.exceeded"`	הקצאת צמתים אוטומטית (NAP) לא הקצתה קבוצת צמתים לפוד באזור הזה, כי פעולה כזו הייתה מפרה את מגבלות המשאבים המקסימליות ברמת האשכול, חורגת מהמשאבים הזמינים באזור או שאין סוג מכונה שמתאים לבקשה.	שם האזור שנבדק.	בודקים ומעדכנים את מגבלות המשאבים המקסימליות ברמת האשכול, את בקשות המשאבים של Pod או את האזורים הזמינים להקצאת צמתים אוטומטית.
`"no.scale.up.nap.pod.zonal.failing.predicates"`	הקצאת צמתים אוטומטית (NAP) לא הקצתה קבוצת צמתים ל-Pod באזור הזה בגלל פרדיקטים שנכשלו.	שם האזור שנבדק והסיבות לכך שהפרדיקטים נכשלו.	בודקים את הדרישות של ה-Pod בהמתנה, כמו כללי שיוך, כתמי צבע, סבילות או דרישות משאבים.

שגיאות ScaleDown

הודעות על אירועי שגיאה של אירועי scaleDown מופיעות באירוע eventResult התואם, בשדה resultInfo.results[].errorMsg.

הודעה על אירוע	פרטים	פרמטר	צמצום הפגיעה
`"scale.down.error.failed.to.mark.to.be.deleted"`	לא ניתן לסמן צומת למחיקה.	שם הצומת שנכשל.	ההודעה הזו אמורה להיות זמנית. אם הבעיה נמשכת, אפשר לפנות ל-Cloud Customer Care כדי לבדוק את הנושא.
`"scale.down.error.failed.to.evict.pods"`	המידרוג האוטומטי של האשכול לא יכול להקטין את מספר הצמתים כי לא ניתן להוציא חלק מה-Pods מצומת.	שם הצומת שנכשל.	בודקים את התקציב להפרעות ב-Pod ומוודאים שהכללים מאפשרים פינוי של רפליקות של האפליקציה כשזה מקובל. למידע נוסף, קראו את המאמר הגדרת תקציב שיבושים לאפליקציה במסמכי התיעוד של Kubernetes.
`"scale.down.error.failed.to.delete.node.min.size.reached"`	אי אפשר לצמצם את האשכול באמצעות התאמה אוטומטית לעומס כי אי אפשר למחוק צומת, כי האשכול כבר בגודל המינימלי.	שם הצומת שנכשל.	בודקים את הערך המינימלי שהוגדר עבור שינוי גודל אוטומטי של מאגר הצמתים ומשנים את ההגדרות לפי הצורך. מידע נוסף זמין במאמר בנושא שגיאה: הצמתים באשכול הגיעו לגודל המינימלי.

סיבות לאירוע noScaleDown

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

הסיבות העיקריות ל-NoScaleDown

הודעות הסיבה ברמה העליונה לאירועי noScaleDown מופיעות בשדה noDecisionStatus.noScaleDown.reason. ההודעה מכילה סיבה ברמה העליונה לכך שהמידרוג האוטומטי של אשכולות לא יכול להקטין את האשכול.

הודעת אירוע פרטים צמצום הפגיעה

הודעת אירוע	פרטים	צמצום הפגיעה
`"no.scale.down.in.backoff"`	מידרוג אוטומטי של אשכולות לא יכול לצמצם אנכית בהתאם לעומס כי הצמצום נמצא בתקופת השהיה לפני ניסיון חוזר (חסימה זמנית).	ההודעה הזו אמורה להיות זמנית, והיא יכולה להופיע אם לאחרונה היה אירוע של הגדלת נפח. אם ההודעה ממשיכה להופיע, פנו אל Cloud Customer Care כדי לבדוק את הבעיה.
`"no.scale.down.in.progress"`	המידרוג האוטומטי של האשכול לא יכול לצמצם את מספר הצמתים כי צמצום קודם עדיין מתבצע.	ההודעה הזו אמורה להיות זמנית, כי בסופו של דבר ה-Pod יוסר. אם ההודעה הזו מופיעה לעיתים קרובות, כדאי לבדוק את תקופת החסד לסיום של הפודים שחוסמים את הצמצום האנכי בהתאם לעומס. כדי לזרז את הפתרון, אפשר גם למחוק את ה-Pod אם הוא כבר לא נחוץ.

"no.scale.down.in.backoff"

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

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

אם ההודעה ממשיכה להופיע, פנו אל Cloud Customer Care כדי לבדוק את הבעיה.

"no.scale.down.in.progress"

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

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

סיבות ברמת הצומת ל-NoScaleDown

הודעות הסיבה ברמת הצומת לאירועי noScaleDown מופיעות ב-noDecisionStatus.noScaleDown.nodes[].reason field. ההודעה מכילה את הסיבה לכך שהמידרוג האוטומטי של האשכול לא יכול להסיר צומת מסוים.

הודעת אירוע	פרטים	פרמטרים	צמצום הפגיעה
`"no.scale.down.node.scale.down.disabled.annotation"`	מידרוג אוטומטי לא יכול להסיר צומת ממאגר הצמתים כי הצומת מסומן ב-`cluster-autoscaler.kubernetes.io/scale-down-disabled: true`.	לא רלוונטי	‫Cluster autoscaler מדלג על צמתים עם ההערה הזו בלי להתחשב בשימוש בהם, וההודעה הזו נרשמת ביומן בלי קשר לגורם השימוש של הצומת. אם רוצים שהמידרוג האוטומטי של אשכולות יצמצם אנכית את הצמתים האלה, צריך להסיר את האנוטציה.
`"no.scale.down.node.node.group.min.size.reached"`	‫Cluster autoscaler לא יכול לצמצם את האשכול אם גודל קבוצת הצמתים חורג מהגודל המינימלי. זה קורה כי הסרת צמתים תפר את מגבלות המשאבים המינימליות ברמת האשכול, שמוגדרות בהגדרות של הקצאת הצמתים האוטומטית.	לא רלוונטי	בודקים את הערך המינימלי שהוגדר להתאמה אוטומטית לעומס של מאגר הצמתים. אם רוצים שהמידרוג האוטומטי יצמצם את הצומת הזה, צריך לשנות את ערך המינימום.
`"no.scale.down.node.minimal.resource.limits.exceeded"`	המידרוג האוטומטי של האשכול לא יכול לצמצם את מספר הצמתים כי זה יגרום להפרה של מגבלות המינימום של המשאבים באשכול. אלה מגבלות המשאבים שמוגדרות להקצאת צמתים אוטומטית (NAP).	לא רלוונטי	בודקים את המגבלות של הזיכרון וה-vCPU, ואם רוצים שהמידרוג האוטומטי של האשכול יצמצם אנכית את הגודל של הצומת הזה, צריך להקטין את המגבלות.
`"no.scale.down.node.no.place.to.move.pods"`	המידרוג האוטומטי של האשכול לא יכול להקטין את מספר הצמתים כי אין מקום להעביר את ה-Pods.	לא רלוונטי	אם אתם מצפים שה-Pod יתוזמן מחדש, בדקו את דרישות התזמון של ה-Pods בצומת שלא מנוצל מספיק כדי לקבוע אם אפשר להעביר אותם לצומת אחר באשכול. מידע נוסף זמין במאמר שגיאה: אין מקום להעברת ה-Pods.
`"no.scale.down.node.pod.not.backed.by.controller"`	ה-Pod חוסם את הצמצום האנכי בהתאם לעומס (scale down) כי הוא לא מגובה על ידי בקר. באופן ספציפי, המידרוג האוטומטי של האשכול לא יכול לצמצם אנכית בהתאם לעומס (scale down) צומת שלא מנוצל מספיק, בגלל Pod שחסר לו בקר מזוהה. הבקרי ההיתריים כוללים את ReplicationController,‏ DaemonSet,‏ Job,‏ StatefulSet או ReplicaSet.	שם ה-Pod שחוסם.	מגדירים את ההערה `"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"` ל-Pod או מגדירים בקר קביל.
`"no.scale.down.node.pod.not.safe.to.evict.annotation"`	ל-Pod בצומת יש את ההערה `safe-to-evict=false`.	שם ה-Pod שחוסם.	אם אפשר לפנות את ה-Pod בבטחה, עורכים את המניפסט של ה-Pod ומעדכנים את ההערה ל-`"cluster-autoscaler.kubernetes.io/safe-to-evict": "true"`.
`"no.scale.down.node.pod.kube.system.unmovable"`	ה-Pod חוסם את הצמצום האנכי בהתאם לעומס (scale down) כי הוא Pod ללא DaemonSet, ללא שיקוף וללא PodDisruptionBudget במרחב השמות `kube-system`.	השם של ה-Pod החוסם.	בגרסאות GKE קודמות ל-1.32.4-gke.1236000, המידרוג האוטומטי של האשכול לא מסיר Pods במרחב השמות `kube-system`. החל מגרסה 1.32.4-gke.1236000, המידרוג האוטומטי של האשכול מסיר את הפודים האלה אחרי שעה מהיצירה שלהם. כדי לפתור את הבעיה הזו, צריך להוסיף PodDisruptionBudget ל-Pods של `kube-system` או להשתמש בשילוב של taints ו-tolerations של מאגרי צמתים כדי להפריד בין ה-Pods של `kube-system` לבין ה-Pods של האפליקציה. למידע נוסף, ראו שגיאה: לא ניתן להעביר את Pod kube-system.
`"no.scale.down.node.pod.not.enough.pdb"`	ה-Pod חוסם את ההקטנה כי אין לו מספיק PodDisruptionBudget.	השם של ה-Pod החוסם.	בודקים את PodDisruptionBudget של ה-Pod ומשנים אותו כך שיהיה פחות מגביל. מידע נוסף זמין במאמר שגיאה: אין מספיק PodDisruptionBudget.
`"no.scale.down.node.pod.controller.not.found"`	ה-Pod חוסם את ההקטנה כי לא ניתן למצוא את בקר ה-Pod (לדוגמה, Deployment או ReplicaSet).	לא רלוונטי	כדי לזהות אילו פעולות בוצעו וגרמו ל-Pod להמשיך לפעול אחרי שהבקר שלו הוסר, צריך לבדוק את היומנים. כדי לפתור את הבעיה, צריך למחוק את ה-Pod באופן ידני.
`"no.scale.down.node.pod.unexpected.error"`	Pod חוסם את הצמצום האנכי בגלל שגיאה לא צפויה.	לא רלוונטי	הגורם לשגיאה הזו לא ידוע. פנו ל-Cloud Customer Care כדי לבדוק את הנושא.

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

דרישות

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

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

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

הצגת התראות לגבי אירועי חשיפה

מעקב אחרי סטטוס Pod בהמתנה באמצעות Cloud Monitoring

תוויות של מקשים

תרחישים לדוגמה

מעקב אחרי הקצאת צמתים

שימוש במדדים וביומנים ביחד

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

מעקב אחרי כשלים בהקצאת צמתים

סיבות לכשל (metric.labels.reason)

סוגי אירועים

אירוע שקשור לסטטוס

דוגמה

אירוע ScaleUp

דוגמה

אירוע ScaleDown

דוגמה

אירוע EventResult

דוגמה

אירוע NodePoolCreated

דוגמה

אירוע NodePoolDeleted

דוגמה

אירוע NoScaleUp

שדות של סיבות

דוגמה

אירוע NoScaleDown

שדות של סיבות

דוגמה

Messages

שגיאות ב-ScaleUp

הסיבות לאירוע noScaleUp

סיבות ברמה העליונה ל-NoScaleUp

סיבות ברמה העליונה לכך שלא בוצעה הקצאת צמתים אוטומטית (NAP) להגדלת הנפח (NoScaleUp)

סיבות ברמת ה-MIG ל-NoScaleUp

סיבות לכך שלא בוצעה הקצאת צמתים אוטומטית (NAP) ברמת קבוצת Pod-ים (NoScaleUp)

שגיאות ScaleDown

סיבות לאירוע noScaleDown

הסיבות העיקריות ל-NoScaleDown

סיבות ברמת הצומת ל-NoScaleDown

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

הצגת אירועים ומדדים של המידרוג האוטומטי באשכול

סיבות לכשל (`metric.labels.reason`)