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

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

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

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

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

מידע נוסף על ניהול תחזוקת המארח של מופעי המחשוב הבסיסיים זמין במאמר ניהול שיבושים בצמתי GKE עבור GPU ו-TPU.

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

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

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

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

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

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

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

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

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

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

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

כדי לצמצם את ההפרעות לעומסי העבודה, אפשר להשתמש במידע על התחזוקה שמוצג באמצעות תוויות של צמתים ב-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 עבור יחידות GPU ו-TPU. הסבר על כך מופיע גם בסעיפים הקודמים.
• שדרוגי אשכולות: כדי לנהל שיבושים שנובעים משדרוגי אשכולות, אפשר להשתמש בכלים הבאים:
  • חלונות תחזוקה: תזמון של מועדים שבהם GKE יכול לבצע שדרוגים של אשכולות וסוגים אחרים של פעולות באשכולות.
  • החרגות תחזוקה: אפשר למנוע שדרוגים של אשכולות וסוגים אחרים של פעולות באשכולות במהלך תקופה מסוימת.

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

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

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

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

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

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

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

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

דרישות

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

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

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

הערה: הנתונים ב-SSD המקומי יימחקו אחרי הפעלה מוצלחת של ה-API, כי המכונה לחישוב תעבור בין מארחים. מומלץ לגבות את נתוני ה-SSD המקומיים לפני שמדווחים על צומת פגום דרך GKE.

כדי לדווח על מארח עם בעיה:

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

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

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

     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: משתמשים בערך הזה אם הביצועים של מעבדי ה-GPU במופע Compute איטיים יותר מהביצועים של מעבדי GPU אחרים באשכול, ולא מופיעות שגיאות XID ביומנים, ולא מזוהים אף אחד מדפוסי הכשל הרגילים האחרים, כמו השחתת נתונים שקטה.
     • ‫SDC: משתמשים בערך הזה אם יש נתונים פגומים אבל לא קריסת מערכת. השחתת הנתונים הזו יכולה להיגרם מפגמים במעבד, באגים בתוכנה כמו use-after-free או memory stomping, בעיות בקרנל או פגמים אחרים. בדרך כלל, המונח הזה מתייחס לפגמים שנגרמים בגלל בעיות בחומרה.
     • ‫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
הגבלת קצב בקשות שגויה ב-API של דוחות על מארחים	אין הגבלות על קצב יצירת הבקשות.	יכול להיות שיהיו הגבלות על קצב השליחה של בקשות ל-API.
תהליך דיווח על מארח פגום	כשמדווחים על מארח פגום בצומת שפועל במצב של כל הקיבולת, קורה הדבר הבא: הוצאת Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מוסיף לצומת taint כדי לחסום תזמון של Pods חדשים. בנוסף,‏ GKE מתחיל להוציא את ה-Pods הפועלים בצומת בצורה מסודרת. ‫GKE מכבד את תקציבי ההפרעות של הפודים (PDB) ואת השדה spec.terminationGracePeriodSeconds במניפסטים של הפודים. פרטים נוספים זמינים במאמר בנושא הגדרת סיום תקין של עומסי עבודה ב-GKE. דיווח על המארח הפגום ותיקון שלו: GKE מדווח באופן אוטומטי על המארח הפגום ומתקן אותו באמצעות קריאה ל-Compute Engine API. כתוצאה מכך, מתבצע רצף של פעולות שבדרך כלל לוקח 10-12 דקות לדווח על המארח הפגום, ואז יכולות לחלוף 3-14 ימים, או אפילו יותר לפעמים, עד שהמארח יתוקן. הפעלה מחדש של המופע: אחרי שפעולת התיקון של המארח מסתיימת (בדרך כלל תוך 3 עד 14 ימים), אחד מהדברים הבאים קורה: אם המופע במצב REPAIRING והמשאבים זמינים כשהתיקון מסתיים, Compute Engine מפעיל מחדש את המופע באופן אוטומטי במארח המתוקן. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים כשהתיקון מסתיים, מצב המופע נשאר TERMINATED או משתנה לTERMINATED. צריך להפעיל מחדש את המופע באופן ידני כשרוצים שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.	כשמדווחים על מארח פגום לצומת שפועל במצב מנוהל, קורה הדבר הבא: הוצאת Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מוסיף לצומת taint כדי לחסום את התזמון של Pods חדשים. בנוסף,‏ GKE מתחיל להוציא את ה-Pods הפועלים בצורה מסודרת מהצומת. ‫GKE מכבד את התקציבים להפרעות בפודים (PDB) ואת השדה spec.terminationGracePeriodSeconds במניפסטים של הפודים. פרטים נוספים זמינים במאמר בנושא הגדרת סיום תקין של עומסי עבודה ב-GKE. דיווח על המארח הפגום ותיקון שלו: GKE מדווח באופן אוטומטי על המארח הפגום ומתקן אותו באמצעות קריאה ל-Compute Engine API, וכתוצאה מכך מתבצע רצף של פעולות. בדרך כלל לוקח 10-12 דקות לדווח על המארח הפגום, ואז יכולות לעבור 3-14 ימים, או אפילו יותר לפעמים, עד שהמארח מתוקן. העברה והפעלה מחדש של המכונה: אחרי שפעולת התיקון של המארח מתחילה (בדרך כלל תוך 10-12 דקות), מערכת Compute Engine מנסה לשריין עוד מארח אחד כדי להחליף את המארח הפגום שדווח בקיבולת השמורה. אם Compute Engine מוצא מארח תקין – אם הוא מחליף בהצלחה את המארח הפגום או מוצא מארח תקין תואם בקיבולת השמורה שלכם – אז Compute Engine מעביר את המופע למארח הזה. לאחר מכן, ההפעלה מחדש של המופע מתבצעת באחת מהדרכים הבאות: אם המופע במצב REPAIRING והמשאבים זמינים לפני או בזמן השלמת התיקון, Compute Engine מפעיל מחדש את המופע באופן אוטומטי במארח תקין. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים לפני או אחרי השלמת התיקון, מצב המופע נשאר TERMINATED או משתנה לTERMINATED. תצטרכו להפעיל מחדש את המופע באופן ידני כשתרצו שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.

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

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

• ‫PodsEvicted: מערכת GKE סיימה להוציא את ה-Pods מהצומת המושפע.
• ‫OperationRUNNING: הפעולה לדיווח על המארח הפגום פועלת.
• ‫OperationDONE: המארח הבסיסי דווח כפגום וצומת GKE מוכן להעברה למארח חדש.
• ‫OperationFAILED: ה-API במופע של Compute נכשל בגלל מגבלות מכסה או בעיות אחרות בתשתית. כדי להבין את השגיאה, אפשר לעיין במאמר בנושא פתרון בעיות שקשורות לשגיאות API של מארח פגום בדוחות. במאמר טיפול בכשלים בהחלפה של דוחות מוסבר איך לשחזר את הדוחות.
• ‫Error: הקריאה ל-API נכשלה כי הבקשה לא עמדה באחת הדרישות שמתוארות בקטע הקודם.

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

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

  kubectl get nodes NODE_NAME \
  -L cloud.google.com/report-and-replace-status,cloud.google.com/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 מחיל cloud.google.com/report-and-replace-failed:NoSchedule taint על הצומת. ההגדרה הזו מונעת תזמון של Pods חדשים בצומת, וכך מוודאת שעומסי עבודה לא יוצבו בצומת עם מארח שעלול להיות פגום. מידע נוסף זמין במאמר טיפול בכשלים בהחלפה ובדיווח.

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

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

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

בדיקה אם יש כתם של כשל

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

  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-
  

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

• איך מתזמנים עומסי עבודה ב-GKE באמצעות תזמון שמודע לטופולוגיה

• איך מבצעים אופטימיזציה של רשתות אשכולות באמצעות NCCL/gIB

• איך פותרים בעיות שקשורות לשגיאות ב-API של המארח