ניהול אשכולות GKE שעברו אופטימיזציה באמצעות AI

בדף הזה מוסבר איך לנהל אשכולות של Google Kubernetes Engine (GKE) שמותאמים ל-AI במכונות מסוג A4X Max,‏ A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (8 GPUs), כולל האירועים הנפוצים הבאים שרלוונטיים לאשכולות GKE ולעומסי עבודה של AI:

  • תחזוקת מארח
  • שדרוגי אשכולות
  • דיווח על מארח לא תקין

ניהול תחזוקת המארח של עומסי עבודה (workloads) של AI

צומתי GKE פועלים במכונות של Compute Engine שבהן מתרחשים מדי פעם אירועים במארח, שעלולים לשבש את עומסי העבודה של ה-AI. אירועים במארח מתרחשים בתשתית הבסיסית שלGoogle Cloud , ולכן הם עוקפים את חלונות הזמן לתחזוקה וההחרגות של GKE. ברוב המכונות, מדיניות התחזוקה של המארח מוגדרת למיגרציה פעילה, כדי לצמצם את השיבוש לעומסי העבודה. עם זאת, יחידות GPU ו-TPU לא תומכות במיגרציה פעילה. כשהאירועים האלה במארח משפיעים על צומתי GKE שמריצים עומסי עבודה של AI, המערכת של GKE צריכה להפסיק את הצומת ואת ה-Pods שפועלים בצומת. אם ה-Pods נפרסו כחלק מעומס עבודה גדול יותר, כמו Job או Deployment, ‏GKE מנסה להפעיל מחדש את ה-Pods בצומת המושפע.

מידע נוסף על ניהול התחזוקה של המארח של מכונות ה-Compute הבסיסיות זמין במאמר ניהול השיבושים בצומתי GKE עבור GPUs ו-TPUs.

מעקב אחרי אירועי תחזוקה של מארחים

באשכולות שבהם פועלת גרסת GKE‏ 1.31.1-gke.2008000 ואילך, אפשר לראות את שעת ההתחלה המתוכננת של אירוע התחזוקה של המארח באופן הבא. שעת ההתחלה מיוצגת על ידי תוויות של צומת Kubernetes בצומת GKE התואם לכל ה-GPU וה-TPU.

למידע נוסף, קראו את המאמר מעקב אחרי התראות תחזוקה.

בעזרת תוויות הצמתים האלה, אתם יכולים:

הפעלה ידנית של אירוע תחזוקה במארח

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

אם לא תתחילו באופן ידני אירוע תחזוקה של מארח, Compute Engine ישלים באופן אוטומטי את התחזוקה המתוזמנת באופן קבוע.

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

שימוש במידע על תחזוקת המארח בזמן תזמון עומסי העבודה

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

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

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

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

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: DoesNotExist

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

כדי להורות ל-GKE לתזמן Pods רק לצמתים שנקבעה להם תחזוקה אחרי תאריך מסוים, צריך לציין את ראשית זמן יוניקס (Unix epoch):

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/scheduled-maintenance-time
            operator: Gt
            values:
            - 1733296000

ניהול השדרוגים של אשכולות GKE לעומסי עבודה של AI

עומסי עבודה של AI רגישים לשיבושים.

במהלך מחזור החיים של אשכול GKE, עומסי העבודה של ה-AI צריכים להיות מוכנים לשיבושים במכונות הבסיסיות וגם באשכול GKE עצמו:

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

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

דיווח על מארחים פגומים דרך GKE

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

אם אתם מבחינים בשגיאות בזיכרון ה-GPU או בשגיאות Xid בצומת, ורוצים לבדוק אם אמצעי שחזור ידניים כמו הפעלה מחדש של מערכת ההפעלה של האורח (kubectl label nodes <NODE_NAME> cloud.google.com/perform-reboot=true) יכולים לפתור את הבעיה לפני שאתם מדווחים על המארח כפגום, קראו את המאמר בדיקת הודעות Xid.

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

  1. פינוי הדרגתי של עומסי העבודה מהצומת.
  2. מונעת תזמון של Pods חדשים בצומת.
  3. שליחת קריאה ל-API במכונה כדי לסמן את המארח כפגום.
  4. ממתין עד שהמכונה תופעל מחדש במכונה מארחת תקינה. במקומות שמורים שמשתמשים במצב התפעולי של כל הקיבולת, המערכת של Compute Engine מחזירה את המכונה לאותו צומת אחרי שפעולת התיקון מסתיימת.
  5. הסרת ה-taint והתווית fault-behavior מהצומת.

אחרי זה, הצומת יהיה מוכן שוב להצגת עומסי עבודה.

דרישות

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

  • צריך להריץ את גרסת התיקון ‎1.32.3-gke.1057001 של GKE או גרסה חדשה יותר.
  • צריך להשתמש באחד מסוגי המכונות הבאים עם GPU: ‏A4X Max, ‏A4X, ‏A4, ‏A3 Ultra, ‏A3 Mega ו-A3 High (עם 8 מעבדי GPU).
  • צריך להריץ את צומתי GKE במכונה שמוגבלת להזמנה.
  • צומת GKE חייב להיות במצב RUNNING. אם תנסו לדווח על מארח פגום אחרי שתמחקו את המכונה, תופיע הודעת שגיאה והמכונה המארחת לא תסומן כפגומה.
  • יכול להיות שיוגבל מספר הקריאות ל-API הזה לכל הזמנה בחודש, על סמך הערכה של תקינות הבלוקים שלכם. מגבלות הקצב לא חלות אם ההזמנה משתמשת במצב הפעולה all capacity של ההזמנה.

דיווח על מארח לא תקין

כדי לדווח על מארח לא תקין:

  1. כדי לזהות את הצמתים ב-GKE שבהם יש בעיות בביצועים, אתם יכולים להשתמש בכלי התצפית של GKE, בכלי המעקב שלכם או ביומנים. שומרים את ה-NODE_NAME.

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

      kubectl patch node NODE_NAME --type merge -p '{
    "metadata": {
      "labels": {
        "cloud.google.com/fault-behavior": "FAULT_REASON"
      },
      "annotations": {
        "cloud.google.com/fault-description": "FAULT_DESCRIPTION"
      }
    }
  }'

    משנים את הפקודה באופן הבא:

    • מחליפים את NODE_NAME בשם של הצומת הפגום.
    • מחליפים את FAULT_REASON בסיבת התקלה המתאימה, באמצעות אחד או יותר מהערכים הבאים:
      • ‫PERFORMANCE: השתמשו בערך הזה אם המעבדים הגרפיים במכונה פועלים לאט יותר ממעבדים גרפיים אחרים באשכול, ואתם לא רואים שגיאות XID ביומנים, ולא מזוהים דפוסי כשל רגילים אחרים כמו פגיעה שקטה בנתונים.
      • ‫SDC: משתמשים בערך הזה אם יש פגיעה בנתונים אבל המערכת לא קורסת. הפגיעה בנתונים יכולה להיגרם בגלל פגמים במעבד (CPU), באגים בתוכנה כמו use-after-free או memory stomping, בעיות בליבה (kernel) או פגמים אחרים. בדרך כלל, המונח הזה מתייחס לפגמים שנגרמים על ידי חומרה.
      • ‫XID: משתמשים בערך הזה אם זיהיתם שגיאת GPU שלא ניתנת לשחזור עם XID במכונה.
      • ‫unspecified: השתמשו בערך הזה אם אתם לא בטוחים איזו התנהגות גורמת לבעיה במכונה. זה ערך ברירת המחדל. עם זאת, מומלץ לציין אחד מהערכים האחרים, אם הוא רלוונטי.
    • משנים את הבלוק annotations בהתאם לגרסה של מישור הבקרה של אשכול GKE:
      • ‫1.35.6-gke.1017000 ואילך, או 1.36.0-gke.3251000 ואילך: משאירים את בלוק ההערות ומחליפים את FAULT_DESCRIPTION בתיאור טקסט של התקלה שנצפתה. המידע הזה יכול לכלול את קוד השגיאה של XID, תסמינים או חותמות זמן. התיאור הזה מועבר ל-Compute Engine כדי לעזור באבחון התיקון, והוא מוסר מהצומת באופן אוטומטי אחרי שהפעולה מסתיימת. לדוגמה: GPU XID 48 observed on device nvidia0 at 2026-06-10T10:30:00Z.
      • גרסאות קודמות: מסירים את כל הבלוק annotations מהפקודה. השדה fault-description לא מועבר ל-Compute Engine בגרסאות האלה, ולא מוסר אוטומטית מהצומת. במקום זאת, פנו לצוות ניהול החשבון או ל-Cloud Customer Care כדי לספק את פרטי התקלה.
אחרי שמדווחים על מארח פגום של צומת, הזמן שבו הצומת מופעל מחדש משתנה בהתאם למצב התפעולי של ההזמנה שצוין בהזמנה שבה הצומת משתמש. כדי לבדוק את מצב הפעולה של ההזמנה, צפו בשדה reservationOperationalMode בהזמנה. בטבלה הבאה מפורט התהליך של מארח פגום בשני מצבי הפעולה של המאגרים: מצב כל הקיבולת ומצב מנוהל.
מצב קיבולת מלאה (ALL_CAPACITY) מצב מנוהל (HIGHLY_AVAILABLE_CAPACITY)
סוגי המכונות הנתמכים ‫A4X Max ו-A4X ‫A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (‏8 יחידות GPU)
הגבלת קצב של יצירת בקשות ב-API לדיווח על מארח פגום אין הגבלות על קצב יצירת הבקשות. יכול להיות שקצב הקריאות ל-API יהיה מוגבל.
תהליך הדיווח על מארח לא תקין

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

  1. פינוי Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מסמן את הצומת כדי לחסום תזמון של Pods חדשים. ‫GKE גם מתחיל לפנות בצורה תקינה את ה-Pods שפועלים בצומת. ‫GKE מכבד את התקציבים לשיבוש Pod‏ (PDB) ואת השדה spec.terminationGracePeriodSeconds של מניפסט ה-Pod. מידע נוסף זמין במאמר הגדרת GKE לסגירה תקינה של עומסי העבודה.
  2. דיווח על המארח הפגום ותיקון שלו: GKE קורא ל-Compute Engine API כדי לדווח על המארח הפגום ולתקן אותו. רצף הפעולות הזה נמשך בדרך כלל בין 10 ל-12 דקות עד לדיווח על המארח הפגום, ובין 3 ל-14 ימים, ולפעמים אפילו יותר, עד לתיקון המארח.

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

    • אם הצומת נמצא במצב REPAIRING והמשאבים זמינים כשהתיקון מסתיים, Compute Engine מפעיל מחדש באופן אוטומטי את הצומת במארח המתוקן.
    • אחרת, אם הצומת במצב TERMINATED או אם המשאבים לא זמינים כשהתיקון מסתיים, מצב הצומת נשאר או משתנה ל-TERMINATED. צריך להפעיל מחדש את הצומת באופן ידני כשרוצים להריץ אותו. עם זאת, אם המשאבים לא זמינים כשמפעילים מחדש את הצומת – לדוגמה, אם מכונות אחרות כבר משתמשות במארח המתוקן – יכול להיות שההפעלה מחדש תיכשל.

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

  1. פינוי Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מסמן את הצומת כדי לחסום תזמון של Pods חדשים. בנוסף, GKE מתחיל לפנות בצורה מסודרת את ה-Pods שפועלים בצומת. ‫GKE מכבד את התקציבים לשיבוש Pod‏ (PDB) ואת השדה spec.terminationGracePeriodSeconds של מניפסט ה-Pod. מידע נוסף זמין במאמר הגדרת GKE לסגירה תקינה של עומסי העבודה.

  2. דיווח ותחילת התיקון של המארח הפגום: GKE קורא ל-Compute Engine API כדי לדווח על המארח הפגום ולתקן אותו. רצף הפעולות הזה נמשך בדרך כלל בין 10 ל-12 דקות עד לדיווח על המארח הפגום.

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

    • ‫A4 ו-A3 Ultra: המערכת של GKE מנסה לבצע מיגרציה פעילה של הצומת למארח אחר. אם אין לכם מספיק קיבולת שמורה או שאין קיבולת זמינה באזור של הצומת, הצומת יפסיק לפעול.
    • ‫A3 Mega ו-A3 High: ‏GKE עוצר את הצומת ומפעיל אותו מחדש במארח תקין.

    תיקון המארח המקורי הפגום יכול להימשך בין 3 ל-14 ימים, ולפעמים אפילו יותר.

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

    • ‫A4 ו-A3 Ultra: אם הצומת הועבר במיגרציה פעילה בשלב הקודם, הוא ממשיך לפעול במארח החלופי. אם הצומת הופסק, הוא יופעל מחדש במארח החלופי.
    • ‫A3 Mega ו-A3 High: הצומת מופעל מחדש במארח החלופי.

    אם Compute Engine לא מוצא מארח חלופי באופן מיידי, הצומת מופעל מחדש באופן הבא:

    • אם הצומת במצב REPAIRING והמשאבים זמינים לפני או אחרי שהתיקון מסתיים, Compute Engine מפעיל מחדש באופן אוטומטי את הצומת במארח תקין.
    • אחרת, אם הצומת במצב TERMINATED או אם המשאבים לא זמינים לפני או אחרי שהתיקון מסתיים, מצב הצומת נשאר או משתנה ל-TERMINATED. צריך להפעיל מחדש את הצומת באופן ידני כשרוצים שהוא יפעל.

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

מעקב אחרי התקדמות הפעולה

כדי לעקוב אחרי התקדמות הפעולה של GKE, אפשר להשתמש בתווית הצומת cloud.google.com/report-and-replace-status בצומת GKE, שיכולה להכיל את אחד מהערכים הבאים:

אפשר גם להציג את התווית של הצומת node.gke.io/report-and-replace-operation כדי לראות את מזהה הפעולה של Compute Engine, ולעקוב אחרי סטטוס הפעולה.

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

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,node.gke.io/report-and-replace-operation

אם מתרחשת שגיאת API, ‏ GKE מגדיר את תווית הצומת cloud.google.com/report-and-replace-status לערך Error. אם הפעולה נכשלת, GKE מגדיר את התווית כ-OperationFAILED. בשני המקרים, GKE מסיר את תווית הצומת cloud.google.com/fault-behavior. בנוסף, ב-GKE בגרסה 1.35.6-gke.1256000 ואילך, או בגרסה 1.36.0-gke.4060000 ואילך, GKE מחיל על הצומת את ה-taint‏ cloud.google.com/report-and-replace-failed:NoSchedule. הכתם הזה מונע תזמון של Pods חדשים בצומת, וכך מבטיח שעומסי העבודה לא ימוקמו בצומת עם מארח שעלול להיות פגום. מידע נוסף זמין במאמר טיפול בכשלים של דיווח והחלפה.

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

טיפול בכשלים בדיווח ובהחלפה

אם פעולת הדיווח וההחלפה נכשלת, GKE מחיל את ה-taint‏ cloud.google.com/report-and-replace-failed:NoSchedule על הצומת המושפע. הכתם הזה משאיר את הצומת מבודד, כך שלא מתוזמנים בו עומסי עבודה חדשים בזמן שהמארח הבסיסי עדיין פגום.

בדיקה אם יש טיינט של כשל

כדי לבדוק אם לצומת יש את הטיינט report-and-replace, מריצים את הפקודה הבאה:

  kubectl describe node NODE_NAME | grep "report-and-replace-failed"

מה עושים אם הדיווח וההחלפה נכשלו

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

  • מנסים שוב לבצע את הפעולה על ידי החלה מחדש של התווית cloud.google.com/fault-behavior על הצומת. אם הניסיון החוזר מצליח, GKE מסיר אוטומטית את ה-taint של cloud.google.com/report-and-replace-failed:NoSchedule:

      kubectl label node NODE_NAME cloud.google.com/fault-behavior=FAULT_REASON

  • הסרה ידנית של הטיינט אם החלטתם שהצומת תקין או שאתם רוצים להחזיר אותו לשירות:

      kubectl taint nodes NODE_NAME cloud.google.com/report-and-replace-failed:NoSchedule-

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