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

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

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

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

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

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

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

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

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

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

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

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

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

כשיוצרים אשכול או מאגר צמתים עם מכונות וירטואליות מסוג Spot, ‏ GKE יוצר מכונות וירטואליות מסוג Spot ב-Compute Engine שמתנהגות כמו קבוצת מופעי מכונה מנוהלים (MIG). צמתים שמשתמשים במכונות וירטואליות מסוג Spot מתנהגים כמו צמתים רגילים של 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 בהתאמה אישית, באופן הבא:

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

    אפשר להגדיר את משך הזמן הזה באחת מהדרכים הבאות:

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

כברירת מחדל, באשכולות נעשה שימוש בכיבוי חלק של הצומת במשך תקופה של 30 שניות בין ההודעה על סיום הפעולה לבין הכיבוי. ל-Pods רגילים יש 15 שניות להיסגר, ולאחר מכן ל-Pods של המערכת (עם 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 שניות.

תזמון עומסי עבודה במכונות וירטואליות במודל 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 בצמתים קיימים שמתאימים לשימוש במכונות וירטואליות רגילות במקום זאת.

שימוש ב-taints וב-tolerations לתזמון

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

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

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

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

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

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

התאמה אוטומטית לעומס (autoscaling) באשכולות והקצאת צמתים אוטומטית

אתם יכולים להשתמש במידרוג אוטומטי של אשכולות ובהקצאת צמתים אוטומטית כדי לשנות את הגודל של האשכולות ושל מאגרי הצמתים באופן אוטומטי בהתאם לדרישות של עומסי העבודה. המידרוג האוטומטי של האשכול והקצאת צמתים אוטומטית (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 או במכונות וירטואליות רגילות קיימות עם קיבולת. אם אתם צריכים לתזמן עומס עבודה במכונות וירטואליות מסוג 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 שהגדרתם.

שיטות מומלצות לשימוש ב-VMs במודל Spot

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

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

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