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

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

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

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

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

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

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

  • סוגי מכונות עם מעבדי GPU ומעבדי TPU מצורפים.
  • סוגי מכונות H4D.
  • סוג המכונה c4a-highmem-96-metal.
  • מכונות C4D ללא מערכת הפעלה (c4d-standard-384-metal,‏ c4d-highcpu-384-metal ו-c4d-highmem-384-metal).
  • סוגי מכונות Z3 עם יותר מ-18 TiB של Titanium SSD מצורף.
  • מכונות מסוג Z4D עם יותר מ-42 TiB של Titanium SSD מחובר.
  • סוגי מכונות Z4M עם יותר מ-48 TiB של Titanium SSD מחובר, או כל מכונות Z4M שמשתמשות ב-Cloud RDMA.

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

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

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

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

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

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

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

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

למידע נוסף על מעקב אחרי התראות ואירועים של תחזוקה, ראו מעקב אחרי אירועי תחזוקה.

ביצוע פעולות בהתאם לתחזוקה שזוהתה

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

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

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

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

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

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

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

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

      • אם מאגר המאיצים מריץ נקודות קצה (endpoints) של הסקה או הצגה של AI או למידת מכונה בזמינות גבוהה: מטמיעים את האסטרטגיה המתגלגלת. לתאם תחזוקה מתוזמנת של מארחים ושדרוגי גרסאות בקבוצות מתגלגלות בתוך גבולות האזור או המאגר, באמצעות רפליקות פעילות כדי להגן על הסכמי ה-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. פינוי Pods בצורה חלקה.
  3. בקשה מ-Compute Engine להתחיל את אירוע התחזוקה באופן מיידי, במקום להמתין לזמן המתוזמן.

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

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

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

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

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

כשהתחזוקה המתוזמנת מתחילה, 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 עושה כמיטב יכולתו כדי לסיים את הפודים האלה בצורה תקינה ולבצע את פעולת הסיום שהגדרתם, למשל שמירת מצב האימון. ‫GKE שולח אות SIGTERM לפודים בתחילת תקופת החסד. אם ה-Pods לא נסגרים עד סוף תקופת החסד, GKE שולח אות SIGKILL לכל התהליכים שעדיין פועלים בקונטיינר ב-Pod.

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

    spec:
      terminationGracePeriodSeconds: 600

מומלץ להגדיר תקופת חסד לסיום שתהיה ארוכה מספיק כדי שכל המשימות המתמשכות יסתיימו במסגרת הזמן של ההתראה. אם עומס העבודה משתמש במסגרת למידת מכונה כמו 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 לפודים של עומסי העבודה שפועלים בצומת, כדי להתריע על כיבוי קרוב. הפודים יכולים להשתמש בהתראה הזו כדי לסיים את המשימות שמתבצעות. 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.
  • תחזוקה אופורטוניסטית לא תואמת ל-Cluster Autoscaler, כי הוא כבר מצמצם אנכית בהתאם לעומס (scale down) צמתים לא פעילים.
  • במאגרי צומתי 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, למשך פרק זמן מסוים.

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