הסבר על תחזוקת המארח ב-GKE

במהלך מחזור החיים של אשכול GKE שפועל לאורך זמן, מתרחשות הפרעות תקופתיות בעומסי העבודה בגלל שיבושים בתשתית שגורמים לCloud de Confiance by S3NS בעיות. האירועים האוטומטיים האלה יכולים להתרחש בתגובה להחלטות תזמון (אירועי קדימות), או לעדכוני צמתים, כולל שדרוגים אוטומטיים של צמתים ב-GKE (אירועי תחזוקה), או לתיקון בעיות שזוהו (אירועי סיום).

במסמך הזה מוסבר מהי הפרעה בצומת ב-GKE, איך לעקוב אחרי התראות על תחזוקה ב-Compute Engine ואיך לצמצם את ההשפעה של הפרעות בצמתים ב-GKE.

המסמך הזה רלוונטי לסוגי המכונות הבאים:

המאמר הזה מיועד לאדמינים ולמפעילים של פלטפורמות שמנהלים את מחזור החיים של התשתית הטכנית הבסיסית. מידע נוסף על תפקידים נפוצים ועל משימות לדוגמה שאנחנו מתייחסים אליהן בתוכן זמין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE. Cloud de Confiance by S3NS

מהי הפרעה בתשתית ב-GKE?

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

  • תיקון בעיות שזוהו (TerminationEvent): האירועים האלה מתרחשים כי Cloud de Confiance by S3NS מזהה בעיה ומפריע לתשתית של האשכול. אירועי TerminationEvent לא תומכים בכיבוי מסודר. אירועי TerminationEvent מופעלים בגלל הבעיות הבאות:

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

  • אירועי תחזוקה או שדרוג (MaintenanceEvent): האירועים האלה מתרחשים כש- Cloud de Confiance by S3NS צריך להפריע למכונה וירטואלית כדי לבצע תחזוקה. האירועים האלה מופעלים על ידי משימות התחזוקה הבאות:

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

  • תגובה להחלטות תזמון (PreemptionEvent): האירועים האלה מתרחשים כש- Cloud de Confiance by S3NS צריך להקדים את הפעלת המכונות הווירטואליות כדי לפנות קיבולת למשאבים בעדיפות גבוהה יותר. הערך PreemptionEvent יכול להיות כל אחד מהבאים:

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

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

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

ברוב המכונות הווירטואליות של Compute Engine, למעט כמה חריגים, מדיניות תחזוקת המארח מוגדרת למיגרציה פעילה, כלומר בדרך כלל יש שיבושים קלים מאוד או בכלל לא בעומסי העבודה הפעילים. עם זאת, סוגים מסוימים של מכונות וירטואליות לא תומכים במיגרציה פעילה, כולל מכונות וירטואליות עם מעבדי GPU ומעבדי TPU מצורפים, סוגי מכונות Z3 עם יותר מ-18 TiB של SSD, סוגי מכונות H4D וסוג המכונה c4a-highmem-96-metal. לדוגמה, כשאירוע של המארח מתרחש במכונה וירטואלית בתוך פרוסת TPU, כל הפרוסה מופרעת ואז מתוזמנת מחדש, כי כל אירועי התחזוקה מתואמים ברמת הפרוסה. לכן, אם יוצרים פרוסת TPU עם מאות מכונות וירטואליות, כל המכונות הווירטואליות האלה יקבלו את אותו לוח זמנים של אירוע תחזוקה.

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

ניהול אירועי תחזוקה

בהמשך המסמך מוסבר איך לנהל שיבושים בMaintenanceEvent.

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

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

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

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

כדי לעקוב אחרי אירועי תחזוקה קרובים ולזהות אותם, צריך לעיין בהתראות מ-GKE ומ-Compute Engine:

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

  • צפייה בתחזוקה הקרובה ב-GKE: ב-GKE גרסה ‎1.31.1-gke.2008000 ואילך, אפשר לעקוב אחרי אירועי תחזוקה קרובים. אתם יכולים לעקוב אחרי אירועים קרובים בסוגי המכונות ובגרסאות GKE הבאים:

    • לסוגי מכונות עם מעבדי GPU או TPU מצורפים, גרסה 1.31.1-gke.2008000 ואילך
    • לסוגי מכונות Z3 עם יותר מ-18 TiB של SSD, ‫1.32.4-gke.1376000 ואילך
    • לסוגי מכונות H4D, גרסה 1.32.6-gke.1060000 ואילך
    • ל-c4a-highmem-96-metal, גרסה 1.35.0-gke.2232000 ואילך

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

    kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

    הפלט אמור להיראות כך:

    NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

    העמודה SCHEDULED-MAINTENANCE-TIME מייצגת שניות, שמוצגות בפורמט של זמן Unix epoch.

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

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

פעולה בתגובה לתחזוקה שזוהתה

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

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

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

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

    1. האם הצמתים המושפעים הם מכונות וירטואליות בודדות או מבודדות?

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

    2. בוחרים אחת מהאפשרויות הבאות בהתאם לתרחיש השימוש:

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

      • אם מאגר המאיצים שלכם מפעיל נקודות קצה של AI/ML לזיהוי תנועה או להסקת מסקנות בזמינות גבוהה: כדאי להטמיע את האסטרטגיה המתגלגלת. לתאם תחזוקה מתוזמנת של המארח ושדרוגים של הגרסה במנות מתגלגלות בתוך הגבולות של האזור או המאגר, באמצעות רפליקות פעילות כדי להגן על הסכמי רמת השירות (SLA).

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

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

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

אם התנאים הקודמים מתקיימים, בצומת במאגר הצמתים מגדירים את תווית הצומת cloud.google.com/perform-maintenance לערך true. לדוגמה:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

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

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

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

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

מערכת Compute Engine מתחילה את אירוע התחזוקה לפי לוח הזמנים

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

התחלת תחזוקה מתוזמנת

כשמתחילה תחזוקה מתוזמנת, מערכת Compute Engine מעדכנת את המטא-נתונים בספרייה http://metadata.google.internal/computeMetadata/v1/instance/attributes/. המערכת של Compute Engine מעדכנת את תוויות המטא-נתונים באופן הבא:

  • ההגדרה של maintenance-event היא TERMINATE_ON_HOST_MAINTENANCE.
  • ב-upcoming-maintenance, הערך של maintenance_status מוגדר ל-ONGOING.

‫GKE מזהה את אירוע התחזוקה המתוזמן של המארח ומטפל בו, בין אם מפעילים אותו באופן ידני ובין אם מאפשרים ל-GKE להמשיך באופן אוטומטי.

מדד המערכת של GKE הבא מדווח על מספר ההפרעות בצומת GKE מאז הדגימה האחרונה (המדד נדגם כל 60 שניות):

  • kubernetes.io/node/interruption_count

השדות interruption_type (למשל TerminationEvent, ‏MaintenanceEvent או PreemptionEvent) ו-interruption_reason (למשל HostError, ‏Eviction או AutoRepair) יכולים לעזור להבין למה הייתה הפרעה בצומת.

כדי לקבל פירוט של ההפרעות והסיבות להן בצמתי TPU באשכולות בפרויקט, משתמשים בשאילתת PromQL הבאה:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

כדי לראות רק את אירועי התחזוקה של המארח, צריך לעדכן את השאילתה כדי לסנן את הערך HW/SW Maintenance בשדה interruption_reason. משתמשים בשאילתת PromQL הבאה:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

כדי לראות את מספר ההפרעות שמצטבר לפי מאגר צמתים, משתמשים בשאילתת PromQL הבאה:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

הגדרות מתקדמות לצמצום ההפרעות

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

הפעלת טיפול בשיבושים

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

כדי להפעיל את הטיפול בשיבושים, יוצרים קובץ בשם maintenance-config.yaml עם ה-ConfigMap הזה. מחילים את ה-ConfigMap על האשכול באמצעות הפקודה הבאה:

kubectl apply -f my-configmap.yaml

הגדרה של GKE להפסקת עומסי העבודה בצורה מסודרת

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

‫GKE עושה מאמץ לסיים את הפעולה של ה-Pods האלה בצורה מסודרת ולבצע את פעולת הסיום שהגדרתם, למשל שמירת מצב האימון. ‫GKE שולח אות SIGTERM ל-Pods בתחילת תקופת ההמתנה. אם ה-Pods לא יוצאים עד סוף תקופת החסד, GKE שולח אות המשך SIGKILL לכל התהליכים שעדיין פועלים בכל קונטיינר ב-Pod.

כדי להגדיר את תקופת החסד לסיום, מגדירים את תקופת החסד לסיום (בשניות) בשדה spec.terminationGracePeriodSeconds של מניפסט ה-Pod. לדוגמה, כדי לקבל התראה 10 דקות לפני הפגישה, צריך להגדיר את השדה spec.terminationGracePeriodSeconds במניפסט של ה-Pod ל-600 שניות, באופן הבא:

    spec:
      terminationGracePeriodSeconds: 600

מומלץ להגדיר תקופת חסד לסיום שמאפשרת לכל המשימות הפעילות להסתיים במסגרת הזמן של ההתראה. אם עומס העבודה משתמש במסגרת ML כמו MaxText,‏ Pax או JAX עם Orbax, עומסי העבודה יכולים לתעד את אות הכיבוי SIGTERM ולהתחיל תהליך של יצירת נקודת שחזור. מידע נוסף זמין במאמר בנושא שמירת נקודות ביקורת אוטומטית ב-TPU.

תהליך של סיום מבוקר

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

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

  1. במהלך 60 השניות הבאות, יקרה אחד מהדברים הבאים:
    1. רכיבי המערכת מחילים את תווית הצומת cloud.google.com/active-node-maintenance node label set to ONGOING כדי לציין שעומסי העבודה מופסקים.
    2. ‫GKE מחיל את ההגדרה taint של הצומת כדי למנוע תזמון של Pods חדשים בצומת. ההכתמה כוללת את המפתח cloud.google.com/impending-node-termination:NoSchedule. אנחנו ממליצים לא לשנות את עומסי העבודה כדי שיוכלו להתמודד עם ההרעלה הזו, בגלל הסיום הידוע שמתרחש.
  2. רכיב ה-maintenance-handler מתחיל להוציא את ה-Pods, קודם את ה-Pods של עומסי העבודה ואז את ה-Pods של המערכת (לדוגמה, kube-system).
  3. ‫GKE שולח אות כיבוי SIGTERM ל-Pods של עומסי עבודה שפועלים בצומת, כדי להודיע להם על כיבוי קרוב. אפשר להשתמש בהתראה הזו כדי לסיים משימות שמתבצעות כרגע. ‫GKE עושה כמיטב יכולתו לסיים את הפעולה של ה-Pods האלה בצורה מסודרת.
  4. אחרי שההוצאה מזיכרון המטמון מסתיימת, GKE מעדכן את הערך של התווית cloud.google.com/active-node-maintenance ל-terminating כדי לציין שהצומת מוכן לסיום.

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

בדיקת ההתקדמות של סגירה הדרגתית פעילה

אפשר לסנן את היומנים של GKE לפי האירועים הבאים של סיום תקין:

  • כשהמכונה הווירטואלית מזהה שיבוש בגלל סיום קרוב של צומת, כמו אירוע תחזוקה של מארח Compute Engine,‏ GKE מגדיר את הערך cloud.google.com/active-node-maintenance ל-ONGOING כשעומסי העבודה מופסקים, ול-terminating כשעומסי העבודה מסתיימים והצומת מוכן לסיום.
  • כשמגבילים את התזמון של עומסי עבודה חדשים, GKE מחיל את ה-taint‏ cloud.google.com/impending-node-termination:NoSchedule.

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

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

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

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

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

מחליפים את הערכים הבאים:

  • ‫NODE_POOL_NAME: השם של מאגר הצמתים של GKE.
  • ‫CLUSTER_NAME : השם של אשכול GKE.
  • ‫NODE_IDLE_TIME : משך הזמן שבו צומת יכול להישאר במצב לא פעיל (כלומר, לא מופעלות עומסי עבודה שצורכים מאיץ) לפני הפעלת תחזוקה. הערך מייצג משך בשניות, עם עד תשע ספרות אחרי הנקודה העשרונית, ומסתיים בתו s, לדוגמה: 80000s.
  • ‫MIN_NODES : מספר הצמתים המינימלי שצריך להיות זמין במאגר הצמתים. האפשרות הזו חוסמת תחזוקה אם היא גורמת למספר הצמתים הפעילים להיות נמוך מהערך הזה, לדוגמה: 10.
  • ‫WINDOW : חלון הזמן, בשניות, שבו אפשר להריץ תחזוקה אופציונלית. הערך מסתיים בתו s. לדוגמה, ערך של 14 ימים, או 1209600s, מציין שאפשר להפעיל תחזוקה אופורטוניסטית רק בשבועיים שלפני תאריך התחזוקה המתוזמן. ערך של 28 ימים, או 2419200s, מאפשר לתחזוקה אופורטוניסטית לפעול בכל זמן במהלך חלון זמן לתחזוקה המתוזמן. חלון הזמן הזה לתחזוקת מארח ב-Compute Engine שונה מחלונות הזמן לתחזוקה ב-GKE, שקובעים מתי אפשר לבצע תחזוקה באשכול GKE ומוגדרים בנפרד.

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

לדוגמה: יש לכם מאגר צמתים עם ארבעה צמתים, והגדרת התחזוקה האופציונלית מוגדרת ל---opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. במקרה כזה:

  • node1 מריץ עליו עומס עבודה של GPU. הצומת הזה לא במצב סרק, ולכן הוא ידלג.
  • node2 לא היה פעיל במשך 60 שניות. הצומת הזה לא היה במצב סרק מספיק זמן, לכן הוא נדלג.
  • node3 לא פעיל במשך 600 שניות. הצומת הזה עומד בדרישה של מצב המתנה.
  • node4 לא פעיל במשך 600 שניות. הצומת הזה עומד בדרישה של מצב המתנה.

גם node3 וגם node4 עומדים בדרישה של חוסר פעילות. עם זאת, רק אחד מהצמתים האלה יפעיל תחזוקה אופורטוניסטית כי הערך של האפשרות min-nodes מוגדר ל-3.

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

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

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

מחליפים את NODE_NAME בשם הצומת שרוצים לבדוק.

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

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

אם הצומת מופעל על ידי תחזוקה אופורטוניסטית, ההערה maintenance-state מוצגת כopportunistic-triggered true.

מגבלות

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

  • אפשר להשתמש בתכונה הזו רק עם מאגרי צמתים של GPU ו-TPU.
  • תחזוקה אופורטוניסטית לא תואמת למידרוג אוטומטי של אשכולות, כי המידרוג האוטומטי של אשכולות כבר מצמצם את מספר הצמתים הלא פעילים.
  • במאגרי צמתים של TPU עם כמה מארחים, הערך של ההגדרה min-nodes-per-pool צריך להיות 0 כי מאגרי הצמתים האלה הם אטומיים.
  • הגרסה המינימלית הנתמכת של GKE היא ‎1.33.3-gke.1118000.
  • יש תמיכה רק בתחזוקה מתוכננת שכוללת את can_reschedule=TRUE ההתראה.
  • כדי להשבית את התכונה הזו, צריך ליצור מחדש את מאגר הצמתים בלי הדגלים המתאימים. אפשר גם להשבית את התכונה באופן ידני בצמתים ספציפיים באמצעות cloud.google.com/opportunistic-disable=true.
  • במקרים נדירים, יכול להיות שהתחזוקה של צומת מסוים תימשך זמן רב יותר. לקוחות שמשתמשים בתכונה הזו עשויים לראות פחות צמתים זמינים, עד לערך של ההגדרה min-nodes-per-pool, למשך תקופה מסוימת.

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