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

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

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

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

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

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

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

1. הפסקת עומסי עבודה: בוחרים את מאגרי הצמתים ומפסיקים את עומסי העבודה שפועלים בהם, או מעבירים את עומסי העבודה לצמתים אחרים שעדיין זמינים.
2. הפעלת תחזוקת המארח: החלת תווית התחזוקה על כל הצמתים שנבחרו בו-זמנית והמתנה לסיום התהליך בכל הצמתים.
3. שדרוג גרסת GKE: שינוי גרסת GKE של הצמתים.
4. הפעלה מחדש של עומסי עבודה: אחרי שכל התחזוקה והשדרוגים של המארחים מסתיימים, מפעילים מחדש את עומסי העבודה.

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

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

נקודות שכדאי לשים לב אליהן לפני שמתחילים

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

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

ביצוע עדכונים לכל הצמתים בו-זמנית

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

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

2. התחלת תחזוקת המארח: החלת התווית לתחזוקה על כל הצמתים במאגר הצמתים שנבחר:

   kubectl label nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME cloud.google.com/perform-maintenance=true --overwrite
   

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

3. מעקב אחרי סטטוס התחזוקה של המארח: מערכת GKE מסירה את תווית התחזוקה כשהתחזוקה מסתיימת. כשהתחזוקה מסתיימת, אפשר למצוא יומן עם ההודעה הבאה ב-Cloud Logging:

   Maintenance window has completed for this instance. All maintenance
   notifications on the instance have been removed.
   

4. אופציונלי: שדרוג הגרסה של צמתי GKE: פועלים לפי ההוראות לשדרוג גרסת GKE של הצמתים.

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

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

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

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

נקודות שכדאי לשים לב אליהן לפני שמתחילים

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

• הבנת הפריסה: כדי להצליח, צריך להכיר את חלוקת עומסי העבודה, את מיקום הרפליקות ואת דומייני הכשל. חשוב לוודא שיש לכם מספיק קיבולת להצגת מודעות לאורך כל התהליך.
• גודלי קבוצות של תוכניות: עדכון צמתים בקבוצות. הגודל של כל אצווה נקבע לפי סובלנות התקלות של עומס העבודה. הגורמים שכדאי להביא בחשבון כוללים את הדברים הבאים:
  • מספר הרפליקות לכל מודל להצגת מודעות.
  • ההתפלגות של העותקים המשוכפלים בין הצמתים ודומייני הכשל.
  • PodDisruptionBudgets יכולים לעזור לאכוף את המספר המקסימלי של פודים שמושבתים בו-זמנית.
  • המלצה: כדי לפשט את הניהול, כדאי להקדיש מאגרי צמתים שונים לקבוצות שונות של רפליקות. כך תוכלו לבודד דומיינים של כשל ברמת מאגר הצמתים.
• חישוב מגבלות הזמן: כדאי להביא בחשבון את גורמי התזמון הבאים:
  • כל חבילת עדכונים יכולה להימשך כמה שעות עד ששלב תחזוקת המארח יושלם.
  • כדי לוודא שכל פעולות התחזוקה יסתיימו במועד הנדרש, צריך לחשב את גודל האצווה המינימלי:
    1. ‫MAINTENANCE_BLOCKS = floor(HOURS_TO_MAINTENANCE / 4) (כאשר HOURS_TO_MAINTENANCE הוא סך הזמן הזמין).
    2. MIN_PER_BATCH = TOTAL_NODE_COUNT / MAINTENANCE_BLOCKS
  • גודל האצווה שבחרתם צריך להיות שווה ל-MIN_PER_BATCH או גדול ממנו.
• בדיקת סוגים ספציפיים של עומסי עבודה: כדאי להביא בחשבון את ההגדרות הבאות עבור סוגי ההגדרות המתאימים:
  • ‫Mixture of Experts (MOE): מוודאים שאסטרטגיית האצווה שלכם שומרת על המספר המינימלי הנדרש של רפליקות לכל מודל.
  • הצגה מפוצלת: כשמתכננים אצווה, חשוב לעקוב אחרי כל העותקים שמעורבים בהגדרה המפוצלת.
  • מאגרי צמתים מרובי-מארחים (TPU, ‏ MNNVL): בהגדרות האלה, סביר להניח שתשביתו מאגר צמתים שלם בכל פעם. חשוב לתכנן את דומייני הכשל בהתאם למאגרי הצמתים השונים.

ביצוע עדכונים הדרגתיים בקבוצות

כדי לבצע עדכונים מצטברים:

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

   • כדי לקבל את כל הצמתים באשכול שמשתמשים במאיצים (TPU או GPU):

     kubectl get nodes -o json | jq -r '.items[] | select(.spec.taints[]? | select(.key=="nvidia.com/gpu" or .key=="google.com/tpu")) | .metadata.name'
     

   • כדי לקבל את כל הצמתים במאגר צמתים ספציפי:

     kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME --no-headers -o custom-columns=":metadata.name"
     

     מחליפים את NODE_POOL_NAME בשם של מאגר הצמתים.

   • כדי לקבל את כל הצמתים עם תווית ספציפית:

     kubectl get nodes -l LABEL -o jsonpath='{.items[*].metadata.name}'
     

     מחליפים את LABEL בתווית הצומת.

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

3. ביצוע תחזוקה של המארח: לכל קבוצה, מבצעים את השלבים הבאים:

   1. בוחרים קבוצה של צמתים ומחילים את תווית התחזוקה:

      kubectl label nodes LIST_OF_NODES_IN_BATCH cloud.google.com/perform-maintenance=true --overwrite
      

      מחליפים את LIST_OF_NODES_IN_BATCH ברשימה של צמתים מהקבוצה, מופרדים ברווחים. לדוגמה, node-1 node-2 node-3.

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

      Maintenance window has completed for this instance. All maintenance
      notifications on the instance have been removed.
      

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

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

שדרוג הגרסה של GKE בצמתים

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

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

שימוש בשדרוגי מתח

1. הגדרת שדרוגים מהירים באמצעות ההגדרה maxUnavailable כדי לקבוע כמה צמתים יכולים להיות לא זמינים בו-זמנית בכל אזור במאגר צמתים. לדוגמה, אם יש לכם 18 צמתים באזור אחד במאגר צמתים, צריך להגדיר את הערך של השדה maxUnavailable ל-18.

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

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

   gcloud container clusters upgrade CLUSTER_NAME \
       --node-pool NODE_POOL_NAME \
       --cluster-version VERSION \
       --location CONTROL_PLANE_LOCATION \
       --quiet
   

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

   • ‫CLUSTER_NAME: השם של האשכול.
   • ‫NODE_POOL_NAME: שם מאגר הצמתים.
   • ‫VERSION: גרסת יעד מומלצת לשדרוג אוטומטי של מאגר הצמתים. מידע נוסף מופיע במאמר בנושא קבלת מידע על שדרוגים של מאגרי צמתים רגילים של אשכולות. אם לא מופיעה גרסת שדרוג אוטומטי מומלצת לאשכול, כדאי לעיין בערכים האחרונים של עדכוני גרסה בהערות הגרסה של GKE.
   • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול.

מחיקה ויצירה מחדש של הצמתים

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

1. מוחקים את מאגר הצמתים:

   gcloud container node-pools delete NODE_POOL_NAME \
       --cluster CLUSTER_NAME \
       --location CONTROL_PLANE_LOCATION
   

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