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

Clustered GPUs

בדף הזה מוסבר איך לנהל אשכולות של Google Kubernetes Engine ‏ (GKE) שעברו אופטימיזציה ל-AI של מכונות A4X Max,‏ A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (עם 8 מעבדי GPU), כולל האירועים הנפוצים הבאים שרלוונטיים לאשכולות 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), עליכם לפנות לצוות ניהול החשבון.

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

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

מארח הוא מכונת שרת פיזית יחידה במרכז הנתונים שמריצה מופע מחשוב שמארח את צומת 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 במופע חישוב איטיים יותר מהביצועים של מעבדי 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
הגבלת קצב בקשות (rate limiting) שגויה ב-API של דוחות על מארחים	לא חלות הגבלות על קצב יצירת הבקשות.	יכול להיות שיהיו הגבלות על קצב השליחה של בקשות ל-API.
תהליך דיווח על מארח פגום	כשמדווחים על מארח פגום לצומת שפועל במצב של כל הקיבולת, קורה הדבר הבא: הוצאת Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מוסיף לצומת taint כדי לחסום תזמון של Pods חדשים. בנוסף,‏ GKE מתחיל להוציא את ה-Pods הפועלים בצומת בצורה מסודרת. ‫GKE מכבד את התקציבים להפרעות ב-Pod (PDB) ואת השדה spec.terminationGracePeriodSeconds במניפסטים של ה-Pod. פרטים נוספים זמינים במאמר בנושא הגדרת סיום תקין של עומסי עבודה ב-GKE. דיווח על המארח הפגום ותיקון שלו: GKE מדווח באופן אוטומטי על המארח הפגום ומתקן אותו באמצעות קריאה ל-Compute Engine API. כתוצאה מכך, מתבצע רצף של פעולות שבדרך כלל לוקח 10-12 דקות לדווח על המארח הפגום, ואז יכולות לחלוף 3-14 ימים, או אפילו יותר לפעמים, עד שהמארח יתוקן. הפעלה מחדש של המופע: אחרי שפעולת התיקון של המארח מסתיימת (בדרך כלל תוך 3 עד 14 ימים), אחד מהמצבים הבאים מתרחש: אם המופע במצב REPAIRING והמשאבים זמינים כשהתיקון מסתיים, Compute Engine מפעיל מחדש את המופע באופן אוטומטי במארח המתוקן. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים כשהתיקון מסתיים, מצב המופע נשאר או משתנה לTERMINATED. צריך להפעיל מחדש את המופע באופן ידני כשרוצים שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.	כשמדווחים על מארח פגום לצומת שפועל במצב מנוהל, קורה הדבר הבא: הוצאת Pods: אחרי שהתווית מוחלת על הצומת הפגום, GKE מוסיף לצומת taint כדי לחסום את התזמון של Pods חדשים. בנוסף,‏ GKE מתחיל להוציא את ה-Pods הפועלים בצורה מסודרת מהצומת. ‫GKE מכבד את Pod Disruption Budgets (PDBs) ואת השדה spec.terminationGracePeriodSeconds של מניפסטים של Pod. פרטים נוספים זמינים במאמר בנושא הגדרת סיום תקין של עומסי עבודה ב-GKE. דיווח על המארח הפגום ותיקון שלו: GKE מדווח באופן אוטומטי על המארח הפגום ומתקן אותו באמצעות קריאה ל-Compute Engine API. התוצאה היא רצף של פעולות שנמשך בדרך כלל 10-12 דקות עד לדיווח על המארח הפגום, ואז יכול להימשך 3-14 ימים, או אפילו יותר לפעמים, עד לתיקון המארח. העברה והפעלה מחדש של המכונה: אחרי שפעולת התיקון של המארח מתחילה (בדרך כלל תוך 10-12 דקות), מערכת Compute Engine מנסה לשריין עוד מארח אחד כדי להחליף את המארח הפגום שדווח בקיבולת השמורה. אם Compute Engine מוצא מארח תקין – אם הוא מחליף בהצלחה את המארח הפגום או מוצא מארח תקין תואם בקיבולת השמורה שלכם – אז Compute Engine מעביר את המופע למארח הזה. לאחר מכן, ההפעלה מחדש של המופע מתבצעת באחת מהדרכים הבאות: אם המופע במצב REPAIRING והמשאבים זמינים לפני או בזמן השלמת התיקון, מערכת Compute Engine מפעילה מחדש את המופע באופן אוטומטי במארח תקין. אחרת, אם המופע במצב TERMINATED או אם המשאבים לא זמינים לפני או אחרי השלמת התיקון, מצב המופע נשאר או משתנה לTERMINATED. תצטרכו להפעיל מחדש את המופע באופן ידני כשתרצו שהוא יפעל. עם זאת, יכול להיות שההפעלה מחדש של המכונה תיכשל אם המשאבים לא יהיו זמינים כשמפעילים אותה מחדש. לדוגמה, זה יכול לקרות אם מכונות אחרות כבר משתמשות במארח שתוקן.

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

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

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

אפשר גם להציג את התווית של הצומת 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 node. בנוסף, ב-GKE גרסה ‎1.35.6-gke.1256000 ואילך, או ‎1.36.0-gke.4060000 ואילך, ‏ GKE מחיל cloud.google.com/report-and-replace-failed:NoSchedule taint על הצומת. ההגדרה הזו מונעת תזמון של Pod חדש בצומת, וכך מוודאת שעומסי עבודה לא יוצבו בצומת עם מארח שעלול להיות פגום. מידע נוסף זמין במאמר טיפול בכשלים בהחלפה ובדיווח.

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

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

כשפעולת דיווח והחלפה נכשלת, 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 של המארח