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

במאמר הזה מוסבר איך לבצע תחזוקת מארח של מכונות 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. התחלה של תחזוקת המארח ומעקב אחריה:

    • בלוקים משניים מהזמנות שמשתמשות בתזמון תחזוקה מקובץ: הפעלת תחזוקה בהזמנות, בבלוקים של הזמנות או בבלוקים משניים של הזמנות באמצעות פקודת המשנה המתאימה gcloud compute reservations. לדוגמה, הפקודה הבאה מפעילה תחזוקה של תת-בלוק:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

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

      • ‫RESERVATION_NAME: השם של ההזמנה.
      • ‫BLOCK_NAME: השם של בלוק ההזמנה.
      • ‫SUB_BLOCK_NAME: השם של תת-הבלוק של ההזמנה.
      • ‫ZONE: האזור שבו קיימת ההזמנה.

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

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

    • מכונות שמשתמשות בתזמון תחזוקה עצמאי: כדי להפעיל תחזוקה למכונות לפי דרישה או להזמנות שלא משתמשות בתת-בלוקים, צריך להחיל את התווית cloud.google.com/perform-maintenance=true על הצמתים במאגר הצמתים:

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

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

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

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

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

    1. הצגת רשימה של שם ההזמנה ומזהי הטופולוגיה של הבלוק הפיזי ובלוק המשנה מהצמתים במאגר הצמתים:

      kubectl get nodes -l cloud.google.com/gke-nodepool=NODE_POOL_NAME \
    -o custom-columns='NAME:.metadata.name,RESERVATION:.metadata.labels.cloud\.google\.com/reservation-name,BLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-block,SUBBLOCK_ID:.metadata.labels.cloud\.google\.com/gce-topology-subblock'

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

      שימו לב לערכי הפלט: שם ההזמנה (לדוגמה, nvidia-gb300-m7kp2xq9vd4j1), מזהה הבלוק (לדוגמה, 3f2a8c9b1d4e0756f8a2b3c1d9e4f0a5) ומזהה תת-הבלוק (לדוגמה, e7b91f4a3c2d58069e1a4b7f3d2c8056).

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

      gcloud compute reservations blocks list RESERVATION_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.block=BLOCK_ID"

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

      • ‫RESERVATION_NAME: השם של ההזמנה.
      • ‫ZONE: האזור שבו קיימת ההזמנה.
      • ‫PROJECT_ID: מזהה הפרויקט שבו קיימת ההזמנה.
      • ‫BLOCK_ID: מזהה הבלוק שאוחזר מתוויות הצומת.

      רושמים את שם הבלוק מהפלט.

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

      gcloud compute reservations sub-blocks list RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --filter="physicalTopology.subBlock=SUBBLOCK_ID"

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

      • ‫RESERVATION_NAME: השם של ההזמנה.
      • ‫BLOCK_NAME: שם המשאב של בלוק ההזמנה.
      • ‫ZONE: האזור שבו קיימת ההזמנה.
      • ‫PROJECT_ID: מזהה הפרויקט שבו קיימת ההזמנה.
      • ‫SUBBLOCK_ID: מזהה תת-הבלוק שאוחזר מתוויות הצמתים.

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

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

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

    1. בוחרים קבוצה של בלוקים משניים של הזמנות ומפעילים תחזוקה של המארח. אתם יכולים להפעיל תחזוקה בכל ההזמנות, בחלונות הזמנות או בחלונות משנה של הזמנות. בסוגי מכונות כמו A4X, ‏ A4X Max, ‏ TPU v6e ו-TPU7x, צריך להפעיל את התחזוקה באופן הזה. התחזוקה מתבצעת בקבוצות של בלוקים משניים. משתמשים בפקודה gcloud compute reservations sub-blocks perform-maintenance:

      gcloud compute reservations sub-blocks perform-maintenance RESERVATION_NAME \
    --block-name=BLOCK_NAME \
    --sub-block-name=SUB_BLOCK_NAME \
    --zone=ZONE

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

      • ‫RESERVATION_NAME: השם של ההזמנה.
      • ‫BLOCK_NAME: השם של בלוק ההזמנה.
      • ‫SUB_BLOCK_NAME: השם של תת-הבלוק של ההזמנה.
      • ‫ZONE: האזור שבו קיימת ההזמנה.

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

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

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

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

עדכון של צמתים בקבוצות

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

  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. בוחרים קבוצה של צמתים ומפעילים תחזוקה בשכבת המופע באמצעות instances API על ידי החלת תווית התחזוקה:

      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.

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

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

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

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

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

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

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

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

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

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

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