מכונות וירטואליות של Spot

במאמר הזה מוסבר מהן מכונות וירטואליות מסוג Spot ואיך הן פועלות ב-Google Kubernetes Engine‏ (GKE). מידע נוסף על שימוש במכונות וירטואליות מסוג Spot:

אתם יכולים לבקש מכונות וירטואליות מסוג Spot לעומסי העבודה שלכם במצב Standard ובמצב Autopilot באמצעות ComputeClasses או בוררי צמתים.

סקירה כללית של מכונות וירטואליות מסוג Spot ב-GKE

מכונות וירטואליות מסוג Spot הן מכונות וירטואליות (VM) של Compute Engine, שמחירן נמוך ממחירן של מכונות וירטואליות רגילות של Compute Engine, ואין עליהן הבטחה לזמינות. מכונות VM זמניות מציעות את אותם סוגי מכונות ואפשרויות כמו מכונות VM רגילות.

אתם יכולים להשתמש ב-VM במודל Spot באשכולות ובמאגרי הצמתים כדי להריץ עומסי עבודה בלי שמירת מצב, באצווה או עמידים בכשלים, שיכולים לעמוד בשיבושים שנגרמים בגלל הארעיות של VM במודל Spot.

מכונות וירטואליות מסוג Spot נשארות זמינות עד ש-Compute Engine צריך את המשאבים למכונות וירטואליות רגילות.

מידע נוסף על מכונות וירטואליות מסוג Spot זמין במאמר מכונות וירטואליות מסוג Spot במאמרי העזרה של Compute Engine.

היתרונות של מכונות וירטואליות במודל Spot

למכונות וירטואליות (VM) זמניות מסוג Spot ולמכונות וירטואליות (VM) שניתן להפסיק יש הרבה יתרונות משותפים, כולל:

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

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

איך פועלות מכונות וירטואליות מסוג Spot ב-GKE

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

כשמבקשים Spot Pods,‏ Autopilot מספק באופן אוטומטי מכונות וירטואליות מסוג Spot, מוסיף taints ו-tolerations ומנהל את ההרחבה האוטומטית ואת התזמון.

סיום וכיבוי מבוקר של מכונות וירטואליות במודל Spot

כש-Compute Engine צריך להחזיר את המשאבים שבהם נעשה שימוש במכונות וירטואליות מסוג Spot, נשלחת הודעת קדימות ל-GKE. אחרי שליחת ההודעה על ההפסקות, מערכת Compute Engine שולחת אות ACPI G2 Soft Off כדי להתחיל את תקופת ההשבתה של המכונה הווירטואלית.

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

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

  • מאגרי צמתים רגילים: כדי להגדיר את משך הזמן הזה למאגרי צמתים רגילים, מישור הבקרה של האשכול צריך להריץ את GKE בגרסה 1.35.0-gke.1171000 ואילך. אפשר להאריך את משך הזמן הזה על ידי התאמה אישית של הגדרות המערכת של הצומת, כדי להגדיר את הערכים של מאגרי צמתים רגילים ספציפיים. מידע נוסף זמין במאמר סיום תקין של מכונות וירטואליות מסוג Spot ב-GKE. השיטה הזו נתמכת רק במצב רגיל.
  • Custom ComputeClasses: כדי להגדיר את משך הזמן הזה למכונות Spot וירטואליות שמשויכות ל-custom ComputeClasses, צריך להשתמש בשדות shutdownGracePeriodSeconds ו-shutdownGracePeriodCriticalPodsSeconds באובייקט kubeletConfig במפרט ComputeClass. מישור הבקרה של האשכול צריך להריץ את GKE בגרסה 1.36.0-gke.3204000 ואילך.

כברירת מחדל, באשכולות נעשה שימוש בכיבוי הדרגתי של הצומת במשך תקופה של 30 שניות בין ההודעה על סיום הפעולה לבין הכיבוי. לפודים רגילים יש 15 שניות עד לכיבוי, ולאחר מכן לפודים של המערכת (עם priorityClasses‏ system-cluster-critical או system-node-critical) יש 15 שניות עד לכיבוי. אפשר להאריך את תקופת החסד באמצעות השדות הבאים:

  • ‫shutdownGracePeriodSeconds: הארכת תקופת החסד הכוללת של ה-Pods ל-120 שניות, או ל-0 שניות אם לא נדרש זמן לסיום תקין.
  • ‫shutdownGracePeriodCriticalPodsSeconds: הארכת תקופת החסד לסיום של פודים קריטיים במערכת. השדה הזה תקף רק אם מציינים גם את השדה shutdownGracePeriodSeconds. הערך בשדה הזה חייב להיות קטן מהערך בשדה shutdownGracePeriodSeconds. לדוגמה, אם מציינים את הערך 30 בשדה shutdownGracePeriodCriticalPodsSeconds ואת הערך 120 בשדה shutdownGracePeriodSeconds, ל-Pods רגילים יש 90 שניות לסיום ול-Pods של המערכת יש 30 שניות לסיום.

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

תזמון עומסי עבודה ב-VM במודל Spot

מערכת GKE מוסיפה אוטומטית את cloud.google.com/gke-spot=true ו-cloud.google.com/gke-provisioning=spot (לצמתים שמריצים GKE גרסה ‎1.25.5-gke.2500 ואילך) תוויות לצמתים שמשתמשים במכונות וירטואליות מסוג Spot. אפשר לתזמן פודים ספציפיים בצמתים שמשתמשים במכונות וירטואליות מסוג Spot באמצעות השדה nodeSelector במפרט הפוד. בדוגמאות הבאות נעשה שימוש בתווית cloud.google.com/gke-spot:

apiVersion: v1
kind: Pod
spec:
  nodeSelector:
    cloud.google.com/gke-spot: "true"

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

apiVersion: v1
kind: Pod
spec:
...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/gke-spot
            operator: In
            values:
            - "true"
...

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

שימוש בכתמי רעל ובהיתרים לתזמון

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

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

מידע על שימוש ב-node taint למכונות וירטואליות מסוג Spot זמין במאמר שימוש ב-taints וב-tolerations למכונות וירטואליות מסוג Spot.

שימוש במכונות וירטואליות מסוג Spot עם מאגרי צמתים של GPU

מכונות וירטואליות במודל Spot תומכות בשימוש ביחידות GPU. כשיוצרים מאגר צמתים חדש של GPU, ‏ GKE מוסיף באופן אוטומטי את ה-taint‏ nvidia.com/gpu=present:NoSchedule לצמתים החדשים. רק פודים עם הסבילות המתאימה יכולים לפעול בצמתים האלה. ‫GKE מוסיף אוטומטית את הסבילות הזו ל-Pods שמבקשים יחידות GPU.

כדי ליצור מאגר צמתים של GPU שמשתמש במכונות Spot VM, צריך שיהיה באשכול לפחות מאגר צמתים קיים אחד שאינו GPU ומשתמש במכונות VM רגילות. אם מאגר צמתים של ה-GPU באשכול שלכם כולל רק מכונות וירטואליות מסוג Spot, ‏ GKE לא מוסיף את ה-taint‏ nvidia.com/gpu=present:NoSchedule לצמתים האלה. כתוצאה מכך, יכול להיות ש-GKE יתזמן עומסי עבודה של מערכת במאגרי צמתים של GPU עם מכונות וירטואליות מסוג Spot, מה שעלול לגרום לשיבושים בגלל המכונות הווירטואליות מסוג Spot ולהגדיל את צריכת המשאבים, כי צמתים של GPU יקרים יותר מצמתים ללא GPU.

מידרוג אוטומטי של אשכול והקצאת צמתים אוטומטית (NAP)

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

מכונות וירטואליות במודל Spot והקצאת צמתים אוטומטית (NAP)

הקצאת צמתים אוטומטית (NAP) יוצרת ומוחקת באופן אוטומטי מאגרי צמתים באשכול כדי לענות על הדרישות של עומסי העבודה. כשמתזמנים עומסי עבודה שדורשים מכונות וירטואליות מסוג Spot באמצעות nodeSelector או באמצעות הצמדה לצומת, התכונה 'הקצאת צמתים אוטומטית (NAP)' יוצרת מאגרי צמתים חדשים כדי להכיל את ה-Pods של עומסי העבודה. ‫GKE מוסיף אוטומטית את ה-taint‏ cloud.google.com/gke-spot=true:NoSchedule לצמתים במאגרי הצמתים החדשים. רק פודים עם הטולרנטיות המתאימה יכולים לפעול בצמתים במאגרי הצמתים האלה. כדי לאפשר ל-GKE למקם את ה-Pods במכונות וירטואליות מסוג Spot, צריך להוסיף את ה-toleration המתאים לפריסות:

   tolerations:
   - key: cloud.google.com/gke-spot
     operator: Equal
     value: "true"
     effect: NoSchedule

כדי לוודא ש-GKE מתזמן את ה-Pods שלכם רק במכונות וירטואליות מסוג Spot, צריך להשתמש גם ב-toleration וגם במסנן של מכונות וירטואליות מסוג Spot באמצעות nodeSelector או כלל של node affinity.

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

מכונות Spot ומידרוג אוטומטי של אשכולות

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

מדיניות ברירת המחדל

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

שדרוג מאגרי צמתים רגילים באמצעות מכונות וירטואליות מסוג Spot

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

שינויים בהתנהגות של Kubernetes

השימוש ב-Spot VMs ב-GKE משנה כמה מההתחייבויות והמגבלות ש-Kubernetes מספקת, כמו אלה:

  • החזרת מכונות וירטואליות במודל Spot היא לא רצונית ולא נכללת בהתחייבויות של PodDisruptionBudgets. יכול להיות שתיתקלו בבעיות זמינות חמורות יותר מהערך PodDisruptionBudget שהגדרתם.

שיטות מומלצות לשימוש במכונות וירטואליות מסוג Spot

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

  • אין התחייבות לזמינות של מכונות וירטואליות מסוג Spot. כשמתכננים את המערכות, צריך להניח ש-GKE עשוי לבטל את ההקצאה של כל מכונות ה-Spot או חלק מהן בכל שלב, בלי להבטיח מתי מופעלים מופעים חדשים.
  • לפני שיוצרים מכונות וירטואליות מסוג Spot, מומלץ לבצע את הפעולות הבאות. הפעולות האלה עוזרות לוודא שסוג המכונה שבו אתם רוצים להשתמש במכונות הווירטואליות מסוג Spot זמין, ושהוא מתאים לעומס העבודה ולצרכים שלכם מבחינת עלות.
  • כדי לוודא שעומסי העבודה והמשימות שלכם יעובדו גם כשאין מכונות Spot VM זמינות, צריך לוודא שבאשכולות יש שילוב של מאגרי צמתים שמשתמשים במכונות Spot VM ומאגרי צמתים שמשתמשים במכונות VM רגילות של Compute Engine.
  • לפני שמוסיפים מאגר צמתים של GPU שמשתמש במכונות Spot VM, צריך לוודא שיש באשכול לפחות מאגר צמתים אחד שאינו GPU ומשתמש במכונות VM רגילות.
  • למרות שבדרך כלל שמות הצמתים לא משתנים כשיוצרים מחדש צמתים, כתובות ה-IP הפנימיות והחיצוניות שבהן נעשה שימוש במכונות וירטואליות מסוג Spot עשויות להשתנות אחרי היצירה מחדש.
  • כדי לוודא ש-Pods קריטיים לא מתוזמנים למאגרי צמתים שמשתמשים במכונות וירטואליות מסוג Spot, צריך להשתמש ב-taints וב-tolerations של צמתים.
  • כדי להריץ עומסי עבודה עם שמירת מצב במכונות וירטואליות מסוג Spot, צריך לבצע בדיקה כדי לוודא שעומסי העבודה יכולים להסתיים בצורה תקינה תוך 25 שניות מסגירת המכונה, וכך לצמצם את הסיכון להשחתת נתונים בנפח אחסון קבוע.
  • פועלים לפי השיטות המומלצות לסיום של Kubernetes Pod.

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