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

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

במסמך הזה נסביר מהי הפרעה בצומת ב-GKE ואיך אפשר למזער את ההשפעה של ההפרעה בצמתים של GKE.

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

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

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

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

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

  • Remediation of detected issues (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 מתחיל את אירוע התחזוקה לפי לוח הזמנים או כשאתם מתחילים אותו באופן ידני.

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

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

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

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

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

  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 שמוגדרת ל-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 מחיל את 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, למשך תקופה מסוימת.

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