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

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

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

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

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

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

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

היתרונות של VMs במודל Spot

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

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

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

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

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

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

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

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

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

כשמספר ה-Pods שהופסקו מגיע לסף של 1,000 באשכולות עם פחות מ-100 צמתים או 5,000 באשכולות עם 100 צמתים או יותר, מתבצע איסוף אשפה כדי לנקות את ה-Pods.

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

  kubectl get pods --all-namespaces | grep -i NodeShutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n
  kubectl get pods --all-namespaces | grep -i Terminated | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n

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

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

כדי ליצור מאגר צמתים של 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) יוצרת ומוחקת באופן אוטומטי מאגרי צמתים באשכול כדי לענות על הדרישות של עומסי העבודה. כשמתזמנים עומסי עבודה שנדרשים להם VM במודל Spot באמצעות nodeSelector או באמצעות הצמדה לצומת, התכונה הקצאת צמתים אוטומטית (NAP) יוצרת מאגרי צמתים חדשים כדי להתאים את ה-Pod-ים של עומסי העבודה. ‫GKE מוסיף אוטומטית את cloud.google.com/gke-spot=true:NoSchedule taint לצמתים במאגרי הצמתים החדשים. רק Podים עם הטולרנטיות המתאימה יכולים לפעול בצמתים במאגרי הצמתים האלה. כדי לאפשר ל-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 או בהעדפת צומת בנוסף לטולרנס. מידע נוסף זמין במאמר בנושא תזמון עומסי עבודה במכונות וירטואליות מסוג Spot.

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

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

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

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

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

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

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

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

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

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

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

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

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