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

פתרון בעיות בהגדרות אישיות של ComputeClass

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

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

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

מושגים מרכזיים

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

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

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

תיאור הבעיה	שלבים לפתרון בעיות
Pod שמבקש ComputeClass בהתאמה אישית תקוע במצב `Pending`	ביצוע בדיקות אבחון בסיסיות בדיקת מגבלות התזמון של ה-Pod הגדרת מאגר צמתים (עבור אשכולות רגילים) ניתוח המדד של פודים בהמתנה להגדלת קנה מידה אוטומטית של אשכול
המידרוג האוטומטי של האשכול לא יוצר צמתים חדשים שתואמים ל-ComputeClass בהתאמה אישית	אימות הגדרות אישיות של ComputeClass אימות ההגדרות של יצירה אוטומטית של מאגרי צמתים ניתוח המדד של Pods בהמתנה למידרוג אוטומטי של אשכול ניתוח של כשלים בהקצאת צמתים
המידרוג האוטומטי של האשכול יוצר סוגי מכונות שמוגדרים כברירת מחדל במקום סוגים מיוחדים	ניתוח של התנהגות הגיבוי של המידרוג האוטומטי
הפלט מהפקודה `kubectl describe computeclass` מציג סטטוס לא תקין	אימות של הגדרות ComputeClass בהתאמה אישית
עומסי העבודה לא עוברים לצמתים בעדיפות גבוהה יותר	איך בודקים את התקינות הכללית של המידרוג האוטומטי באשכול
בעיות בתזמון של עומסי עבודה במכונות וירטואליות עם GPU או ב-VM במודל Spot	בדיקת אילוצי התזמון של Pod אימות ההגדרה של מכונות וירטואליות עם GPU או VM במודל Spot ניתוח של התנהגות הגיבוי של המידרוג האוטומטי

בעיות שלא נכללות בהיקף

המסמך הזה לא עוסק בנושאים הבאים:

בעיות כלליות ברשת של GKE, כמו קישוריות בין Pod ל-Pod או איזון עומסים בשירות.
בעיות שקשורות ל-Horizontal Pod Autoscaler‏ (HPA) או ל-Vertical Pod Autoscaler‏ (VPA).
בעיות שלא קשורות למנגנון של ComputeClass בהתאמה אישית, כמו שגיאות ברמת האפליקציה או בעיות ב-PersistentVolume שלא קשורות לאילוצי תזמון.
בעיות שקשורות למכסות או לחוסר זמינות של משאבים, שלא קשורות ישירות ללוגיקת החלופות של ComputeClass.

זיהוי משתני פלייסהולדר

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

משתנה	תיאור
`PROJECT_ID`	מזהה הפרויקט ב- Google Cloud .
`LOCATION`	האזור או התחום (zone) של Compute Engine שבו נמצא האשכול.
`CLUSTER_NAME`	שם האשכול.
`NODE_POOL_NAME`	שם מאגר הצמתים שרוצים לבדוק (אם רלוונטי לאשכולות Standard).
`CUSTOM_COMPUTECLASS_NAME`	השם של ComputeClass מותאם אישית שה-Pod מבקש.
`NAMESPACE`	מרחב השמות של ה-Pod שלא ניתן לתזמן.
`POD_NAME`	השם של ה-Pod שלא מצליח לתזמן.

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

כדי לקבל את ההרשאות שדרושות לביצוע המשימות שמפורטות במאמר הזה, בקשו מהאדמין להקצות לכם את התפקידים הבאים ב-IAM בפרויקט Google Cloud :

כדי לגשת לאשכולות GKE: Kubernetes Engine Cluster Viewer (roles/container.viewer).
כדי לצפות ביומנים: מציג היומנים (roles/logging.viewer).
כדי לנהל אשכולות GKE: אדמין Kubernetes Engine‏ (roles/container.admin).

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

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

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

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

ביצוע בדיקות אבחון בסיסיות

מוודאים שרכיבי הליבה מוגדרים בצורה נכונה ושהאשכול תומך ב-ComputeClasses בהתאמה אישית.

אימות הסטטוס והסלקטור של ה-Pod

מוודאים שה-Pod במצב Pending ומבקש בצורה נכונה את ComputeClass בהתאמה אישית.

הצגת רשימה של Pods במצב Pending:

kubectl get pods --all-namespaces -o wide | grep Pending

בודקים את המפרט של ה-Pod בשדה nodeSelector:

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.nodeSelector}'

הערכת התוצאה

הפלט מציג את התווית: השדה nodeSelector מוגדר בצורה נכונה עם התווית cloud.google.com/compute-class.
התווית לא מופיעה בפלט:
- הסבר: יכול להיות ששדה nodeSelector שגוי או חסר בתווית cloud.google.com/compute-class בהגדרות הפריסה של עומס העבודה.
- פתרון: משנים את קובץ ה-YAML של עומס העבודה, כמו פריסה או משימה, כך שיכלול את השדה nodeSelector בקטע spec.template.spec.

אימות התאימות של גרסת האשכול

כדי להשתמש ב-ComputeClasses בהתאמה אישית, צריך GKE בגרסה ‎1.30.3-gke.1451000 ואילך. מוודאים שבגרסה של האשכול יש תמיכה ב-ComputeClasses בהתאמה אישית.

בודקים את גרסת האשכול:

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

הערכת התוצאה

‫גרסה 1.30.3-gke.1451000 ואילך: גרסת האשכול תומכת ב-ComputeClasses בהתאמה אישית.
גרסה מוקדמת יותר מ-1.30.3-gke.1451000:
- הסבר: האשכול לא שודרג לגרסה שתומכת ב-ComputeClasses בהתאמה אישית.
- פתרון: צריך לשדרג את האשכול כדי להשתמש ב-ComputeClasses בהתאמה אישית.

אימות הצמתים שהוקצו ל-ComputeClass בהתאמה אישית

כדי לבדוק אם יש באשכול צמתים שמשויכים ל-ComputeClass, מציגים את הצמתים שתואמים לתווית של ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

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

אימות ההגדרות האישיות של ComputeClass

הגדרות שגויות במשאב ComputeClass בהתאמה אישית יכולות למנוע תזמון של Pods או למנוע מ-GKE להקצות צמתים בצורה נכונה.

בדיקת התקינות והסטטוס של ComputeClass

מוודאים ש-GKE מדווח על ComputeClass בהתאמה אישית כתקין.

הצגת רשימה של כל המשאבים מסוג ComputeClass:
```
kubectl get computeclass
```

תארו את משאב ComputeClass הספציפי:

kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

הערכת התוצאה

סטטוס התקינות הוא True: ה-ComputeClass בהתאמה אישית תקין. הדוגמה הבאה מציגה ComputeClass תקין בהתאמה אישית:

Status:
  Conditions:
    Last Transition Time:  2024-01-19T17:18:48Z
    Message:               CCC is healthy.
    Reason:                Health
    Status:                True
    Type:                  Health

סטטוס התקינות מראה False:
- פירוש: ה-ComputeClass המותאם אישית לא תקין. כדי לזהות את הבעיה, בודקים את השדות Message ו-Reason בפלט.
- פתרון: מבצעים את הפעולה שמתאימה לשדה Reason בפלט:
  - ‫NodePoolNotExist: צריך לוודא שמאגר הצמתים שאליו מפנים קיים, או לעדכן את ComputeClass כך שיפנה למאגר צמתים קיים.
  - ‫ReservationUnusable: בדיקה של התצורה והשימוש בהזמנה שאליה יש הפניה.
  - ‫Invalid machine type: צריך לעדכן את ComputeClass כדי להשתמש בסוג מכונה שנתמך באזור או באזור הזמינות של האשכול.

אימות המדיניות של `unsatisfiable`

השדה whenUnsatisfiable קובע את ההתנהגות כשאי אפשר לעמוד בכללי העדיפות.

קראו את המדיניות:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

בודקים את השדה spec.whenUnsatisfiable בפלט. השדה הזה יכול לכלול אחד מהערכים הבאים:

‫DoNotScaleUp: רצפים נשארים במצב Pending אם אי אפשר ליצור צמתים מועדפים.
‫ScaleUpAnyway: יכול להיות שה-Pods יפעלו בסוגי צמתים שמוגדרים כברירת מחדל (כמו סדרת E2) אם הצמתים המועדפים לא זמינים.

הערכת התוצאה

ההשפעה של המדיניות whenUnsatisfiable תלויה בערך שלה:

אם הערך הוא DoNotScaleUp:
- פרשנות: זוהי התנהגות צפויה כשלא ניתן לעמוד בכללי העדיפות, אולי בגלל חוסר זמינות של משאבים או מגבלות מכסה. אם הפודים צריכים להמתין לחומרה ספציפית, הערך הזה נכון.
- פתרון: אם הפעלת עומס העבודה קריטית יותר מהפעלה בחומרה ספציפית, משנים את המדיניות ל-ScaleUpAnyway.
אם הערך הוא ScaleUpAnyway:
- הסבר: זו התנהגות צפויה. ‫GKE חוזר לסוגי הצמתים שמוגדרים כברירת מחדל כי הצמתים המועדפים לא זמינים.
- פתרון: אם אסור להפעיל Pods בסוגי צמתים שמוגדרים כברירת מחדל, צריך לשנות את המדיניות ל-DoNotScaleUp.
התנהגות ברירת המחדל: אם לא ציינתם ערך לשדה whenUnsatisfiable ואתם משתמשים בגרסה של GKE מוקדמת יותר מ-1.33, ערך ברירת המחדל של המדיניות הוא ScaleUpAnyway.

בדוגמה הבאה מוסבר איך לעדכן את המדיניות על ידי עריכת השדה whenUnsatisfiable במניפסט של ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

בדיקת האילוצים בתזמון Pod

חשוב לוודא שהמפרט של ה-Pod תואם למאפיינים של הצמתים שהוקצו על ידי ה-ComputeClass בהתאמה אישית.

אימות בקשות למשאבים של Pod

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

קבלת בקשות למשאבי Pod:
```
kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.containers[*].resources.requests}'
```
בודקים את הפלט של בקשות cpu, memory ו-GPU, כמו nvidia.com/gpu.
משווים את הבקשות האלה לסוגי המכונות שמוגדרים בשדה priorities של ComputeClass בהתאמה אישית:
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
    -o jsonpath='{.spec.priorities}'
```
בודקים את הפלט בשדות machineType או machineFamily. לכל סוג מכונה ב-ComputeClass המותאם אישית, בודקים את המפרטים שלו במסמכי העזרה של סוגי המכונות ומוודאים שהמשאבים שניתן להקצות לו גדולים מהבקשות של ה-Pod.

הערכת התוצאה

משאבים תואמים: בקשות המשאבים של ה-Pod קטנות או שוות למשאבים שניתנים להקצאה של לפחות סוג מכונה אחד ב-ComputeClass.
המשאבים חורגים מהקיבולת:
- הסבר: אי אפשר לתזמן את ה-Pod כי אין סוג מכונה ב-ComputeClass שמספק מספיק מעבד (CPU), זיכרון או GPU. מצב כזה יכול לקרות גם אם השדה nodePoolAutoCreation מוגדר לערך true ובקשת הזיכרון של ה-Pod חורגת מהמגבלות של מאגרי הצמתים שנוצרו אוטומטית.
- פתרון: משנים את בקשות המשאבים של ה-Pod או את סוגי המכונות של ה-ComputeClass המותאם אישית:
  - צמצום בקשות המשאבים של ה-Pod: אם בקשות המשאבים גבוהות, כדאי להקטין את הערכים של cpu, memory או gpu בקובץ ה-YAML של עומס העבודה.
  - שינוי לסוגי מכונות גדולים יותר: אם הבקשות של ה-Pod מוצדקות, משנים את השדה spec.priorities במניפסט של ה-ComputeClass בהתאמה אישית כך שיכלול אפשרויות גדולות יותר של machineType או machineFamily שיכולות למלא את הדרישות של ה-Pod. לדוגמה:
```
spec:
  priorities:
  - machineType: n2d-highmem-96 # A larger machine type
    spot: true
  # ... other priorities
```

בדיקה אם יש taints ו-tolerations שמתנגשים

לצמתים שנוצרו בשביל ComputeClass בהתאמה אישית יש את ה-taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. ‫GKE מוסיף את הטולרנטיות הזו לפודים באופן אוטומטי.

עם זאת, לחומרה מיוחדת כמו מעבדי GPU יש טיינטים נוספים, כמו הטיינט nvidia.com/gpu=present:NoSchedule. אם ה-ComputeClass שלכם משתמש בצמתים עם חומרה ייעודית, ל-Pods חייבת להיות סבילות ל-taints האלה כדי לתזמן אותם בצמתים האלה.

בודקים את השדה tolerations של ה-Pod:

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

הערכת התוצאה

סובלנויות נכונות: פגמים וסובלנויות מוגדרים בצורה נכונה.
טולרנטיות חסרות:
- פרשנות: אם חסרים tolerations, אי אפשר לתזמן את ה-Pod בצמתים עם taints של חומרה ייעודית. לדוגמה, אם ה-ComputeClass משתמש בצומתי GPU, יכול להיות של-Pod חסרה הסבילות nvidia.com/gpu=present:NoSchedule. לדרישות ספציפיות ל-GPU, ראו אימות הגדרת ה-GPU.
- פתרון: בשדה tolerations במפרט ה-Pod, מוסיפים את ההגדרות הנדרשות של tolerations כדי להתאים ל-taints בצמתים שמוגדרים על ידי ComputeClass. לדוגמה, לצומתי GPU, מוסיפים טולרנטיות ל-taint של nvidia.com/gpu=present:NoSchedule באופן הבא:
```
spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
# ... other tolerations and Pod spec
```

ניתוח המדד "פודים בהמתנה" של Cluster Autoscaler

גרסאות GKE רלוונטיות: 1.37 ואילך

כדי להבין למה פודים שמבקשים ComputeClass ספציפי נמצאים בהמתנה, אתם יכולים להשתמש במדד kubernetes.io/autoscaler/cluster_pending_pods_per_ccc ב-Cloud Monitoring. המדד הזה עוזר לכם להבין אם הבעיה היא מחסור בצמתים שמתאימים ל-ComputeClass, בעיה בהקצאה או בעיה שקשורה להגדרות של ה-Pod. המדד הזה מציג את מספר ה-Pods שה-autoscaler של האשכול מעבד, בחלוקה לפי ComputeClass, הסיבה להמתנה, והאם מדובר ב-Pod של המערכת או של המשתמש.

שלבים לשאילתה

כדי לשלוח שאילתה לגבי המדד במסוף Google Cloud :

במסוף Google Cloud , נכנסים לדף Metrics explorer.
בוחרים את סוג המשאב: k8s_entity.
בוחרים את המדד: kubernetes.io/autoscaler/cluster_pending_pods_per_ccc.
מוסיפים מסנן: entity_type = ComputeClass.
מוסיפים מסנן ל-ComputeClass הספציפי: entity_name = "COMPUTECLASS_NAME".
- כדי לראות Pods שלא משתמשים ב-ComputeClass, מסננים לפי entity_name = "".
קיבוץ לפי metric.labels.reason כדי לראות את מצבי המידרוג האוטומטי של ה-Pods האלה. אפשר גם לקבץ פודים באמצעות metric.labels.typeתווית המפתח.

שאילתת PromQL לדוגמה

כדי למצוא את הסטטוס של פודים של משתמשים בהמתנה שמבקשים את ComputeClass‏ "COMPUTECLASS_NAME", משתמשים בשאילתת PromQL הבאה:

sum by (reason) (
  kubernetes_io:autoscaler_cluster_pending_pods_per_ccc{
    monitored_resource="k8s_entity",
    entity_type="ComputeClass",
    entity_name="COMPUTECLASS_NAME",
    type="user_pod"
  }
)

סיבות שקשורות למדדים

הפלט של תווית המפתח metric.labels.reason יכול לכלול את הפרטים הבאים:

‫unable_to_provision: המידרוג האוטומטי של האשכול חסום. אי אפשר לתזמן Pods במצב הזה ל-ComputeClass כי אי אפשר ליצור צמתים חדשים. כדי לקבל פרטים על חוסרים במלאי, מכסות או הגדרות שגויות בהגדרת ComputeClass, צריך לבדוק את היומנים של המידרוג האוטומטי באשכול במישור הבקרה. כדאי גם לבדוק את אירועי החשיפה של המידרוג האוטומטי באשכול.
‫provisioning_in_progress: הופעלה הרחבה של צמתים שצריכים להתאים לדרישות של ComputeClass. אם ה-Pods נשארים כאן, יכול להיות שיהיו עיכובים ביצירה או במוכנות של הצומת.
‫unprocessed: ה-Pods האלה עדיין לא נבדקו על ידי המידרוג האוטומטי של האשכול. מספר גבוה באופן עקבי עשוי להצביע על השהיה של קנה המידה האוטומטי.
‫no_action_taken: המידרוג האוטומטי של האשכול החליט לא לשנות את קנה המידה של ה-Pods האלה. ההתנהגות הזו יכולה לנבוע מהגבלות של Pod שלא ניתן לעמוד בהן בגלל סוגי הצמתים של ComputeClass או בגלל מגבלות אחרות ברמת האשכול. בודקים את מפרט ה-Pod‏ (kubectl describe pod) ואת היומנים של המידרוג האוטומטי באשכול.

ניתוח כשלים בהקצאת צמתים

גרסאות GKE רלוונטיות: 1.37 ואילך

כדי לבדוק את סטטוס התקינות הנוכחי של ComputeClass, אפשר לעיין במאמר בנושא אימות התקינות של ComputeClass. אם אתם רואים שרכיבי ה-Pod שמשויכים ל-ComputeClass נמצאים במצב unable_to_provision, המידרוג האוטומטי באשכול לא מקצה צמתים חדשים שתואמים לדרישות של ה-ComputeClass. אפשר להשתמש במדד kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc של Cloud Monitoring כדי לאבחן את שורש הבעיה.

במסוף Google Cloud , נכנסים ל-Monitoring ואז ל-Metrics Explorer.
בוחרים באפשרות k8s_entity בשדה Resource type.
בוחרים את המדד kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc.
מוסיפים מסנן: resource.labels.entity_type = ComputeClass.
מוסיפים מסנן ל-ComputeClass הספציפי: entity_name = "CUSTOM_COMPUTECLASS_NAME".
- כדי לראות פודים שלא משתמשים ב-ComputeClass, מסננים לפי entity_name = "".
בקטע קיבוץ לפי, בוחרים באפשרויות metric.labels.reason ו-resource.labels.entity_name.
בוחרים Aggregator, כמו rate או delta.

שיעור הכשלים או השינוי בשיעור הכשלים מוצג לפי הסיבה.

הסבר על הסיבות לכישלון

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

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

סיבה	הסבר	פעולות לתיקון
`QUOTA_EXCEEDED`	‫ Google Cloud הגעתם למגבלת המכסה (לדוגמה, מעבדים, דיסקים או כתובות IP). בודקים את המכסות של הפרויקט.	לבקש להגדיל את המכסה.
`RESOURCE_POOL_EXHAUSTED`	חוסר זמינות של Compute Engine; קיבולת לא מספיקה למשאבים המבוקשים באזור.	נסו להשתמש בסוגי מכונות או באזורים אחרים. משנים את ComputeClass כך שיכלול סוגי מכונות או אזורים חלופיים. להשתמש בהזמנות.
`IP_SPACE_EXHAUSTED`	ברשת המשנה של הצומת נגמרו כתובות ה-IP הזמינות.	הרחבת טווח כתובות ה-IP הראשי של רשת המשנה.
`PERMISSIONS_ERROR`	לחשבון השירות של GKE אין את הרשאות ה-IAM שנדרשות כדי ליצור משאבים (לדוגמה, מכונות ודיסקים).	מקצים את התפקידים הנדרשים לחשבון השירות של GKE.
`VM_EXTERNAL_IP_ACCESS_POLICY_CONSTRAINT`	מדיניות הארגון (`constraints/compute.vmExternalIpAccess`) מונעת יצירת צמתים עם כתובות IP חיצוניות כפי שהוגדרו.	בודקים ומשנים את מדיניות הארגון או את הגדרת הצומת של ComputeClass.
`INVALID_RESERVATION`	ההזמנה שהוגדרה ב-Compute Engine לא תקינה, לא הוגדרה נכון או לא תואמת לבקשת הצומת.	בודקים את הגדרות ההזמנה ואת ההגדרה של ComputeClass.
`RESERVATION_NOT_FOUND`	השם שצוין למקום השמור ב-Compute Engine לא קיים.	מאמתים את שם ההזמנה ב-ComputeClass.
`RESERVATION_NOT_READY`	ההזמנה המטורגטת עדיין לא פעילה או שהיא עדיין בתהליך הקצאה.	מחכים שההזמנה תהפוך לפעילה.
`RESERVATION_CAPACITY_EXCEEDED`	ההזמנה מלאה ואי אפשר להיענות לבקשה.	צריך להגדיל את גודל ההזמנה או להשתמש בסוגי מכונות אחרים.
`RESERVATION_INCOMPATIBLE`	הגדרת הצומת (לדוגמה, סוג המכונה או האזור) לא תואמת למאפייני ההזמנה.	מתאימים את המפרט של הצומת ComputeClass למאפיינים של ההזמנה.
`AUTOMATIC_RESERVATIONS_NOT_AVAILABLE`	הייתה בעיה בניסיון להשתמש בהזמנות אוטומטיות.	כדאי לבדוק את היומנים. יכול להיות שתצטרכו לפנות אל Cloud Customer Care.
`AUTOMATIC_RESERVATIONS_NO_CAPACITY`	אין מספיק קיבולת להזמנות אוטומטיות.	יכול להיות שתצטרכו לעבור להזמנות ידניות או לסוגי מכונות אחרים.
`UNSUPPORTED_TPU_CONFIGURATION`	הגדרת ה-TPU המבוקשת לא תקינה או שלא נתמכת באזור או בפרויקט שנבחרו.	בודקים את התיעוד של TPU ואת ComputeClass.
`GkePersistentOperationError`	אירעה שגיאה מתמשכת במישור הבקרה של GKE במהלך תהליך היצירה של הצומת.	פנייה ל-Cloud Customer Care
`OTHER`	הסבר כללי לכשלים שלא מתאימים לקטגוריות אחרות.	לפרטים נוספים, אפשר לעיין ביומנים של המידרוג האוטומטי של האשכול במישור הבקרה.

הגדרת מאגר צמתים (אשכולות רגילים)

באשכולות GKE Standard, צריך לתייג ולהגדיר טולרנטיות למאגרי צמתים שנוצרו באופן ידני כדי שיעבדו עם ComputeClass בהתאמה אישית.

אימות של תוויות וכתמים של מאגר צמתים

מזהים את מאגרי הצמתים ב-ComputeClass בהתאמה אישית. אם ה-ComputeClass בהתאמה אישית משתמש בשדה nodePools, צריך לשים לב לשמות של מאגרי הצמתים שמופיעים ברשימה:
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

לכל מאגר צמתים שזיהיתם, בודקים את ההגדרות שלו:

gcloud container node-pools describe NODE_POOL_NAME
    --cluster CLUSTER_NAME
    --location LOCATION
    --format="yaml(config.labels, config.taints)"

הערכת התוצאה

מאגר הצמתים מוגדר בצורה נכונה: למאגר הצמתים יש את התווית cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME ואת ה-taint‏ cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule.
הגדרה שגויה של מאגר הצמתים:
- הסבר: מאגר הצמתים לא הוגדר עם התווית וה-taint שנדרשים כדי לשייך אותו ל-ComputeClass בהתאמה אישית.
- פתרון: מעדכנים את מאגר הצמתים כדי להוסיף את התווית וה-taint:
  1. הוספה או עדכון של תווית צומת:
```
gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME
```
  2. הוספה או עדכון של טיינט לצומת:
```
gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule
```

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

גם באשכולות במצב Autopilot וגם באשכולות רגילים עם nodePoolAutoCreation שמוגדר ל-true, צריך להגדיר בצורה נכונה את היצירה האוטומטית של מאגר הצמתים.

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

בודקים אם השדה nodePoolAutoCreation.enabled ב-ComputeClass המותאם אישית מוגדר ל-true:
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

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

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(autoscaling.enableNodeAutoprovisioning)"

אם אחד מהם מושבת, יצירה אוטומטית של מאגר צמתים לא תיצור מאגרי צמתים חדשים עבור ComputeClass בהתאמה אישית.

הערכת התוצאה

היצירה האוטומטית של מאגר הצמתים מופעלת: ב-ComputeClass, השדה nodePoolAutoCreation.enabled מוגדר ל-true, והקצאת צמתים אוטומטית (NAP) מופעלת ברמת האשכול.
היצירה האוטומטית של מאגר הצמתים מושבתת:
- פרשנות: היצירה האוטומטית של מאגרי צמתים מושבתת אם הערך של השדה nodePoolAutoCreation.enabled הוא false או חסר ב-ComputeClass, או אם הקצאת הצמתים האוטומטית ברמת האשכול מושבתת.
- פתרון: מפעילים יצירה אוטומטית של מאגר צמתים:
  1. עורכים את קובץ ה-YAML של ComputeClass בהתאמה אישית כדי לכלול את nodePoolAutoCreation: enabled: true:
```
spec:
  # ... priorities
  nodePoolAutoCreation:
    enabled: true
```
  2. הפעלת יצירה אוטומטית של מאגר צמתים ברמת האשכול והגדרת מגבלות משאבים:
```
gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --enable-autoprovisioning \
  --autoprovisioning-min-cpu=MIN_CPU \
  --autoprovisioning-max-cpu=MAX_CPU \
  --autoprovisioning-min-memory=MIN_MEMORY \
  --autoprovisioning-max-memory=MAX_MEMORY
```

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

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

כדי לראות את מגבלות המשאבים:
```
gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
--format="value(autoscaling.resourceLimits)"
```
הפלט מציג את השדות resourceType,‏ minimum ו-maximum של המעבד (CPU) והזיכרון (ב-GB).
בודקים את סוגי המכונות בעדיפויות של ה-ComputeClass בהתאמה אישית. אפשר לבדוק את המפרטים של המעבד (CPU) והזיכרון שלהם במסמכי התיעוד של סוגי המכונות.
בודקים את הקיבולת הכוללת הנוכחית של המעבד והזיכרון של כל הצמתים באשכול. סכום הקיבולת הנוכחית בתוספת המשאבים של צומת חדש פוטנציאלי לא יכול לחרוג מהמגבלה המקסימלית ליצירה אוטומטית של מאגר צמתים.

הערכת התוצאה

קיבולת מספיקה: לאשכול יש מספיק קיבולת של מעבד (CPU) וזיכרון במסגרת מגבלות המשאבים, כדי שההקצאה האוטומטית של מאגר הצמתים תוכל להקצות צומת חדש.
חריגה מהמגבלות:
- הסבר: אי אפשר להקצות צמתים חדשים באמצעות יצירה אוטומטית של מאגרי צמתים, כי האשכול הגיע למגבלות המעבד (CPU) או הזיכרון, או שהמגבלות שהוגדרו נמוכות מדי לסוגי המכונות ב-ComputeClass.
- פתרון: מגדילים את מגבלות המשאבים ליצירה אוטומטית של מאגרי צמתים:
  1. קובעים מגבלות מקסימליות חדשות שמביאות בחשבון את השימוש הנוכחי ואת הצמיחה העתידית, כולל סוגי המכונות הגדולים ביותר ב-ComputeClass בהתאמה אישית.
  2. עדכון מגבלות המשאבים ליצירה אוטומטית של מאגר צמתים אפשר להגדיר כמה משאבים בפקודה אחת:
```
gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
  --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB
```

ניתוח ההתנהגות של המערכת החלופית להתאמה לעומס (autoscaler)

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

ב-ComputeClasses בהתאמה אישית נעשה שימוש בלוגיקה חלופית לפי סדר עדיפות. אם Pod לא מתזמן בצמתים שתואמים לכלל בעל העדיפות הגבוהה ביותר, לעיתים קרובות זה נובע מאילוצים כמו חוסר זמינות של משאבים או מכסות פרויקט. כש-GKE לא יכול להקצות צמתים שתואמים לכלל עדיפות ספציפי, למשל בגלל שגיאת ZONE_RESOURCE_POOL_EXHAUSTED או QUOTA_EXCEEDED מ-Compute Engine, המידרוג האוטומטי של האשכול מנסה מיד את הכלל הבא ברשימת priorities. אין תקופת המתנה לפני ש-GKE עובר לעדיפות הבאה, אלא אם משתמשים ב-TPU או במודל ההקצאה Flex Start, שתומכים בהשהיה שאפשר להגדיר.

בדיקה אם המשאב לא זמין

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

אפשרות 1: בדיקת אירועי החשיפה של המידרוג האוטומטי באשכול

במסוף Google Cloud , נכנסים לדף Cloud Logging > Logs Explorer ומריצים את השאילתה הבאה כדי למצוא אירועים של התאמה אוטומטית לעומס (autoscaler) שעשויים להצביע על חוסר זמינות של משאבים:

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

אפשרות 2: בדיקת שגיאות ב-MIG

אתם יכולים לבדוק אם יש שגיאות ב-MIG במסוף Google Cloud או באמצעות שאילתה ב-Cloud Logging.

באמצעות מסוף Google Cloud :
1. במסוף Google Cloud , עוברים אל Compute Engine > Instance groups.
2. מוצאים את ה-MIG שמתאים למאגר הצמתים שלא מצליח להתרחב.
3. לוחצים על שם ה-MIG ועוברים לכרטיסייה שגיאות. מחפשים הודעות שמעידות על מיצוי המשאבים.

באמצעות שאילתה ב-Cloud Logging:

במסוף Google Cloud , נכנסים לדף Cloud Logging > Logs explorer.
מריצים את השאילתה הבאה כדי לבדוק אם יש שגיאות של מיצוי משאבים מה-MIG:

resource.type="gce_instance"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")

הערכת התוצאה

המשאבים זמינים: אם ביומנים לא מופיעות ההודעות של ZONE_RESOURCE_POOL_EXHAUSTED, כנראה שהסיבה לכישלון בהגדלת ההיקף היא לא חוסר זמינות של משאבים.
מקורות המידע לא זמינים:
- הסבר: הקצאת הצומת נכשלה בגלל ביקוש גבוה זמני לסוג מכונה ספציפי (במיוחד VM במודל Spot או GPUs) באותו אזור, או בגלל ש-Pod מוגבל על ידי זיקה של PersistentVolume לאזור שבו המשאבים לא זמינים.
- פתרון: חוסר הזמינות של המשאבים הוא זמני, אבל אפשר לשפר את העמידות על ידי הוספת גמישות להגדרות האישיות:
  - גיוון סוגי המכונות: ודאו שהשדה spec.priorities ב-ComputeClass בהתאמה אישית מכיל כמה סוגים או משפחות של מכונות כחלופות:
```
spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority
```
  - שימוש באשכולות אזוריים: אם האשכול הוא אזורי, הוא פגיע לזמינות משאבים באזור אחד. שימוש באשכולות אזוריים מאפשר ל-Cluster Autoscaler לנסות להקצות צמתים באזורים אחרים באזור שבו יכול להיות שיש קיבולת זמינה.
  - שימוש במקומות שמורים ב-Compute Engine: לעומסי עבודה קריטיים שלא יכולים לסבול עיכובים, צרו מקומות שמורים ב-Compute Engine כדי להבטיח קיבולת לסוגי מכונות ספציפיים.

אימות מכסות הפרויקט

מוודאים שיש בפרויקט מכסה מספקת למשאבים, כמו מעבדי CPU, מעבדי GPU וכתובות IP שנדרשים לצמתים החדשים.

בודקים אם יש שגיאות מכסה ביומנים של ההתאמה האוטומטית לעומס. משתמשים ב-Cloud Logging כדי לחפש הודעות שגיאה שקשורות למכסות באירועי החשיפה של המידרוג האוטומטי:
```
resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"
```
אפשר גם להשתמש בשאילתה הבאה ב-Cloud Logging כדי לבדוק אם יש ביומנים שגיאות שקשורות למכסות בקבוצת ה-MIG:
```
resource.type="gce_instance"
protoPayload.methodName:"compute.instances.insert"
protoPayload.status.message:"QUOTA_EXCEEDED"
severity=ERROR
```
בדיקת המכסות במסוף Google Cloud :
1. במסוף Google Cloud , נכנסים לדף IAM & Admin > Quotas.
2. מסננים לפי השירות Compute Engine API.
3. בודקים את השימוש במדדים רלוונטיים כמו מעבדים (CPU), מעבדים גרפיים (GPU) (מכל הסוגים) וכתובות IP בשימוש באזור שבו נמצא אשכול GKE. מוודאים שהשימוש הנוכחי לא הגיע למגבלה.

הערכת התוצאה

המכסה מתחת למגבלות: אם השימוש במכסה נמוך ממגבלות המכסה ולא נמצאו שגיאות QUOTA_EXCEEDED ביומנים, מגבלות המכסה לא יחסמו את ההרחבה.
חריגה מהמכסה:
- הסבר: הקצאת הצמתים נכשלת בגלל מכסה לא מספיקה למשאבים כמו מעבדים (CPU), מעבדי GPU, כתובות IP או MIG.
- פתרון: אם הפרויקט הגיע למגבלת המכסה, בקשו להגדיל את המכסה.

הגדרות מתקדמות

להגדרות כמו GPUs, מכונות וירטואליות במודל Spot ושמירת מקום ב-Compute Engine יש דרישות ספציפיות משלהן ונקודות כשל פוטנציאליות שצריך לבדוק.

אימות הגדרות ה-GPU

במקרה של ComputeClasses בהתאמה אישית שמקצים צמתים של GPU, צריך לאמת את הגדרת ה-GPU ב-ComputeClass בהתאמה אישית ולוודא של-Pod יש את ה-toleration nvidia.com/gpu הנדרש.

בודקים את ה-YAML של ה-ComputeClass בהתאמה אישית כדי לראות אם יש בלוק gpu בתוך כלל עדיפות:
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```
בבלוק gpu צריך לציין את השדות type ו-count, לדוגמה:
```
priorities:
- machineType: a2-highgpu-1g
  gpu:
    type: nvidia-tesla-a100
    count: 1
```
בדיקת ה-Pod כדי לראות אם הוא יכול לפעול על צומת עם GPU. כל Pod שצריך לתזמן בצומת GPU חייב לכלול את ה-toleration של nvidia.com/gpu, גם אם ה-Pod עצמו לא מבקש GPU.
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'
```
בודקים את הסבילות בשדה spec.tolerations.

הערכת התוצאה

ה-GPU מוגדר בצורה נכונה: אם ComputeClass מגדיר GPU type ו-count, ו-Pods כולל את ה-toleration‏ nvidia.com/gpu, הגדרת ה-GPU נכונה. כאן מוצגת הסבילות הנדרשת:
```
tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"
```
הגדרת ה-GPU לא תקינה:
- פרשנות: יכול להיות שה-Pod לא מכיל את ה-toleration הנדרש של nvidia.com/gpu, שה-ComputeClass לא תקין בגלל חוסר התאמה בשדות של ה-GPU, או שגרסת GKE לא מטפלת נכון בהגדרת ה-GPU.
- פתרון: מבצעים את אחת מהפעולות הבאות:
  - משנים את קובץ ה-YAML של עומס העבודה כדי לכלול את ההגדרה המנדטורית של סבילות ל-GPU, ומחילים מחדש את קובץ ה-YAML.
  - משדרגים את אשכול GKE. אם ה-ComputeClass בהתאמה אישית לא תקין והבעיה קשורה לשדות GPU, צריך לבדוק אם יש בעיות מוכרות ולשדרג לגרסת GKE עם תיקון, למשל 1.31.8-gke.1045000 ואילך.

אימות ההגדרה של VM במודל Spot

אם אתם משתמשים ב-VM במודל Spot, ודאו שההגדרה spot: true נמצאת בכללי העדיפות הנכונים במניפסט של ComputeClass. חשוב גם להבין את לוגיקת התמחור של המידרוג האוטומטי באשכול.

בודקים את המניפסט של ComputeClass:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

בפלט, מחפשים את הערך spot: true בשדה spec.priorities, לדוגמה:

priorities:
- machineFamily: n2d
  spot: true

יכול להיות שהמידרוג האוטומטי של אשכולות ישתמש בנתוני תמחור מ-us-central1 כבסיס להשוואה בין העלויות של סוגים שונים של VM במודל Spot, מה שיכול להוביל לבחירות שנראות לא אופטימליות באזורים אחרים. אנחנו מודעים להתנהגות הזו.

הערכת התוצאה

מכונות וירטואליות במודל Spot מוגדרות בצורה נכונה: אם השדה spot: true צוין והכלי להתאמה לעומס של אשכולות מקצה מכונות וירטואליות במודל Spot, ההגדרה פועלת כצפוי.
לא ניתן לתזמן מכונות וירטואליות במודל Spot:
- פרשנות: יכול להיות שאי אפשר לתזמן פודים שדורשים מכונות וירטואליות במחיר נמוך במכונות וירטואליות במחיר נמוך, כי המשאבים לא זמינים באזור היעד, או כי הכלי להתאמה אוטומטית של קנה המידה של האשכול בוחר סוג אחר של מכונה וירטואלית על סמך מודל התמחור של us-central1.
- פתרון:
  - אם אתם חושדים שמשאב לא זמין, עיינו בקטע בדיקה אם משאב לא זמין.
  - כדי לשלוט בבחירה של VM במודל Spot, צריך לציין במפורש את הרשומות של machineType בשדה priorities, מהזולה ביותר ליקרה ביותר באזור שלכם. הגישה הזו מאפשרת לכם שליטה ישירה בסדר החזרה למצב הקודם. לדוגמה:
```
spec:
  priorities:
  - machineType: t2d-standard-48 # Cheapest in this region
    spot: true
  - machineType: n2d-standard-48 # Fallback Spot option
    spot: true
  - machineType: n2d-standard-48 # On-demand fallback
    spot: false
```

תקינות כללית של המידרוג האוטומטי של האשכול

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

בדיקה אם יש פעולות בו-זמניות

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

הצגת רשימה של פעולות מתמשכות שלא נמצאות במצב DONE:

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

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

הערכת התוצאה

אין פעולות בו-זמניות: אם הפקודה list מחזירה רשימה ריקה, אין פעולות שחוסמות את המידרוג האוטומטי של גודל האשכול.
נמצאו פעולות בו-זמניות:
- פרשנות: אם הפקודה מציגה פעולות עם הסטטוס RUNNING או PENDING, יכול להיות שפעולה בו-זמנית, כמו שדרוג אשכול או שינוי של מאגר צמתים, מתבצעת וחוסמת את ההתאמה האוטומטית לעומס.
- פתרון: צריך לחכות שהפעולה הנוכחית תסתיים. אתם יכולים לעקוב אחרי הסטטוס באמצעות מזהה הפעולה, בעזרת:
```
gcloud container operations wait OPERATION_ID --location LOCATION
```
  מחליפים את OPERATION_ID במזהה מהפלט של הפקודה list. אחרי שפעולת החסימה מסתיימת, המידרוג האוטומטי של האשכול אמור לחזור לפעול כרגיל.

בדיקת העברה פעילה

אם אתם רואים שעומסי עבודה נשארים בצמתים בעדיפות נמוכה יותר כשצמתים בעדיפות גבוהה יותר זמינים, בדקו אם ההעברה הפעילה מופעלת. אם השדה activeMigration.optimizeRulePriority מוגדר ל-false או מושמט ב-ComputeClass, ‏ GKE לא יעביר באופן אוטומטי עומסי עבודה לצמתים בעדיפות גבוהה יותר כשהם יהיו זמינים.

כדי לבדוק את ה-tolerations של ה-Pod, בודקים את השדה spec.tolerations. אם ל-Pod יש tolerations שתואמים ל-taints בכמה מאגרי צמתים עם עדיפויות שונות, יכול להיות שהמתזמן ימקם אותו בצומת עם עדיפות נמוכה יותר אם הוא זמין קודם.
```
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'
```
כדי לבדוק אם ההעברה הפעילה מופעלת, בודקים את המניפסט של ComputeClass בשדה spec.activeMigration.optimizeRulePriority.
```
kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml
```

הערכת התוצאה

העברה פעילה מופעלת: אם הערך בשדה activeMigration.optimizeRulePriority הוא true, ‏ GKE מנסה להעביר עומסי עבודה לצמתים בעדיפות גבוהה יותר כשהם הופכים לזמינים.
העברה פעילה מושבתת או לא יעילה:
- פרשנות: אם השדה activeMigration.optimizeRulePriority הוא false או מושמט, או אם הסבילות של Pod רחבה מדי, עומסי העבודה נשארים בצמתים בעלי עדיפות נמוכה יותר כשצמתים בעלי עדיפות גבוהה יותר זמינים. הגישה הזו מאפשרת לתזמן עומסי עבודה בצמתים בעדיפות נמוכה יותר שמתפנים ראשונים.
- פתרון: אם רוצים שהעומסים יועברו לצמתים עם עדיפות גבוהה יותר, מבצעים אחת מהפעולות הבאות:
  - כדי להעדיף מאגרי צמתים בעדיפות גבוהה יותר, אפשר להשתמש באילוצי תזמון ספציפיים יותר כמו nodeAffinity.
  - עורכים את המניפסט של ComputeClass כדי להגדיר את activeMigration.optimizeRulePriority: true ומחילים את קובץ ה-YAML:
```
spec:
  activeMigration:
    optimizeRulePriority: true
```

פנייה לתמיכה

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

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

מושגים מרכזיים

פתרון בעיות לפי תסמינים

בעיות שלא נכללות בהיקף

זיהוי משתני פלייסהולדר

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

ביצוע בדיקות אבחון בסיסיות

אימות הסטטוס והסלקטור של ה-Pod

הערכת התוצאה

אימות התאימות של גרסת האשכול

הערכת התוצאה

אימות הצמתים שהוקצו ל-ComputeClass בהתאמה אישית

אימות ההגדרות האישיות של ComputeClass

בדיקת התקינות והסטטוס של ComputeClass

הערכת התוצאה

אימות המדיניות של unsatisfiable

הערכת התוצאה

בדיקת האילוצים בתזמון Pod

אימות בקשות למשאבים של Pod

הערכת התוצאה

בדיקה אם יש taints ו-tolerations שמתנגשים

הערכת התוצאה

ניתוח המדד "פודים בהמתנה" של Cluster Autoscaler

שלבים לשאילתה

שאילתת PromQL לדוגמה

סיבות שקשורות למדדים

ניתוח כשלים בהקצאת צמתים

הסבר על הסיבות לכישלון

הגדרת מאגר צמתים (אשכולות רגילים)

אימות של תוויות וכתמים של מאגר צמתים

הערכת התוצאה

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

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

הערכת התוצאה

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

הערכת התוצאה

ניתוח ההתנהגות של המערכת החלופית להתאמה לעומס (autoscaler)

בדיקה אם המשאב לא זמין

הערכת התוצאה

אימות מכסות הפרויקט

הערכת התוצאה

הגדרות מתקדמות

אימות הגדרות ה-GPU

הערכת התוצאה

אימות ההגדרה של VM במודל Spot

הערכת התוצאה

תקינות כללית של המידרוג האוטומטי של האשכול

בדיקה אם יש פעולות בו-זמניות

הערכת התוצאה

בדיקת העברה פעילה

הערכת התוצאה

פנייה לתמיכה

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

פתרון בעיות בהגדרות אישיות של ComputeClass

אימות המדיניות של `unsatisfiable`