בדף הזה מוסבר מהן מכונות וירטואליות מסוג Spot ואיך הן פועלות ב-Google Kubernetes Engine (GKE). מידע נוסף על השימוש במכונות וירטואליות מסוג Spot זמין במאמר שימוש במכונות וירטואליות מסוג Spot.
סקירה כללית של מכונות וירטואליות מסוג Spot ב-GKE
מכונות Spot VM הן מכונות וירטואליות (VM) של Compute Engine שמחירן נמוך ממכונות VM רגילות של Compute Engine, ואין עליהן הבטחה לזמינות. מכונות VM זמניות מציעות את אותם סוגי מכונות ואפשרויות כמו מכונות VM רגילות.
אתם יכולים להשתמש ב-VM במודל Spot באשכולות ובמאגרי הצמתים כדי להריץ עומסי עבודה בלי שמירת מצב, באצווה או עמידים בכשלים, שיכולים לעמוד בשיבושים שנגרמים בגלל הארעיות של VM במודל Spot.
מכונות וירטואליות מסוג Spot נשארות זמינות עד ש-Compute Engine צריך את המשאבים למכונות וירטואליות רגילות.
מידע נוסף על מכונות וירטואליות מסוג Spot זמין במאמר מכונות וירטואליות מסוג Spot במאמרי העזרה של Compute Engine.
היתרונות של מכונות וירטואליות במודל Spot
למכונות וירטואליות (VM) זמניות מסוג Spot ולמכונות וירטואליות (VM) שניתן לקטוע יש הרבה יתרונות משותפים, כולל:
- מחירים נמוכים יותר ממכונות וירטואליות רגילות ב-Compute Engine.
- השימוש במכונות האלה מועיל לעומסי עבודה בלי שמירת מצב ועמידים בכשלים, שלא רגישים לאופי הארעי של מכונות ה-VM האלה.
- פועל עם המידרוג האוטומטי של האשכול ועם הקצאת משאבים אוטומטית של צמתים.
למכונות וירטואליות מסוג Spot יש גם את היתרונות הבאים:
- בניגוד למכונות וירטואליות שניתנות להפסקת פעולה, שתוקפן פג אחרי 24 שעות, למכונות וירטואליות מסוג Spot אין תוקף. המכונות הווירטואליות מסוג Spot נדחקות רק כש-Compute Engine צריך את המשאבים במקום אחר.
- בעזרת מכונות וירטואליות מסוג Spot, אתם יכולים לראות את הזמינות בזמן אמת ואת זמן הפעולה הצפוי, כדי לעזור לכם להחליט איפה ואיך להקצות משאבים. מידע נוסף זמין במאמר בנושא צפייה בזמינות של מכונות וירטואליות מסוג Spot.
איך פועלות מכונות וירטואליות מסוג Spot ב-GKE
כשיוצרים אשכול או מאגר צמתים עם מכונות וירטואליות מסוג Spot, GKE יוצר מכונות וירטואליות מסוג Spot ב-Compute Engine שמתנהגות כמו קבוצת מופעי מכונה מנוהלים (MIG). צמתים שמשתמשים במכונות וירטואליות מסוג Spot מתנהגים כמו צמתים רגילים של GKE, אבל אין עליהם הבטחה לזמינות. כשנדרשים המשאבים שבהם נעשה שימוש במכונות וירטואליות מסוג Spot להפעלת מכונות וירטואליות רגילות, מערכת Compute Engine מסיימת את הפעולה של המכונות הווירטואליות מסוג Spot כדי להשתמש במשאבים במקום אחר.
סיום וכיבוי מבוקר של מכונות וירטואליות במודל Spot
כש-Compute Engine צריך להחזיר את המשאבים שבהם נעשה שימוש במכונות וירטואליות מסוג Spot, נשלחת הודעת קדימות ל-GKE. אחרי שליחת ההודעה על ההפסקות, מערכת Compute Engine שולחת אות ACPI G2 Soft Off כדי להתחיל את תקופת ההשבתה של המכונה הווירטואלית.
כברירת מחדל, לאשכולות GKE יש תקופת סיום תקינה של 30 שניות ל-Pods כדי להיסגר אחרי קבלת ההודעה על ההדחה. התקופה הזו מחולקת ל-15 שניות להשבתת ה-Pods שלכם, ולאחר מכן ל-15 שניות להשבתת ה-Pods הקריטיים של המערכת.
אפשר גם להאריך את משך תקופת ההפסקות ההדרגתיות ל-120 שניות. ההגדרה של משך הזמן הזה נמצאת בתצוגה מקדימה, ומישור הבקרה של האשכול צריך להריץ את GKE בגרסה 1.35.0-gke.1171000 ואילך. אפשר להאריך את משך הזמן על ידי התאמה אישית של הגדרות מערכת הצמתים כדי להגדיר את הערכים של מאגרי צמתים רגילים ספציפיים. מידע נוסף זמין במאמר בנושא סיום תקין של מכונות וירטואליות מסוג Spot ב-GKE. השיטה הזו נתמכת רק במצב רגיל.
כברירת מחדל, באשכולות נעשה שימוש בכיבוי הדרגתי של הצומת במשך תקופה של 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 שניות.
תזמון עומסי עבודה במכונות וירטואליות במודל 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 VMs. כשמגדירים צמתים שמשתמשים במכונות וירטואליות מסוג Spot, מערכת GKE מתזמנת בצמתים האלה רק Pods עם toleration מתאים.
אם אתם משתמשים בכתמי צומת, ודאו שבאשכול יש גם לפחות מאגר צמתים אחד שמשתמש במכונות וירטואליות רגילות של Compute Engine. מאגרי צמתים שמשתמשים במכונות וירטואליות רגילות מספקים מקום אמין ל-GKE לתזמן רכיבי מערכת קריטיים כמו DNS.
מידע על שימוש ב-node taint למכונות וירטואליות מסוג Spot זמין במאמר שימוש ב-taints וב-tolerations למכונות וירטואליות מסוג Spot.
שימוש במכונות וירטואליות מסוג Spot עם מאגרי צמתים של GPU
מכונות וירטואליות במודל Spot תומכות בשימוש ביחידות GPU.
כשיוצרים מאגר צמתים חדש עם GPU, GKE מוסיף באופן אוטומטי את 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) יוצרת ומוחקת באופן אוטומטי מאגרי צמתים באשכול כדי לעמוד בדרישות של עומסי העבודה. כשמתזמנים עומסי עבודה שנדרשים להם מכונות וירטואליות מסוג VM במודל Spot באמצעות nodeSelector או באמצעות הצמדה לצומת, הקצאת צמתים אוטומטית (NAP) יוצרת מאגרי צמתים חדשים כדי להכיל את ה-Pod של עומסי העבודה. 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 או בהעדפת צומת בנוסף לטולרנס. מידע נוסף זמין במאמר בנושא תזמון עומסי עבודה במכונות וירטואליות מסוג Spot.
מכונות Spot ומידרוג אוטומטי של אשכולות
Cluster autoscaler מוסיף ומסיר צמתים במאגרי הצמתים באופן אוטומטי על סמך הביקוש. אפשר להגדיר את התכונה 'שינוי גודל אוטומטי של אשכולות' כך שיוספו צמתים חדשים עם העדפה למכונות וירטואליות מסוג Spot. מידע נוסף זמין במאמר בנושא מכונות וירטואליות מסוג Spot ושינוי גודל אוטומטי של אשכולות.
מדיניות ברירת המחדל
החל מגרסה 1.24.1-gke.800 של GKE, אפשר להגדיר את מדיניות המיקום של התאמה אוטומטית של גודל האשכול. הכלי לשינוי גודל האשכול מנסה להקצות מאגרי צמתים של מכונות וירטואליות מסוג Spot כשהמשאבים זמינים ומדיניות המיקום שמוגדרת כברירת מחדל היא ANY. המדיניות הזו מפחיתה את הסיכון להפסקת השימוש במכונות וירטואליות מסוג Spot. עבור סוגים אחרים של מכונות וירטואליות, מדיניות ברירת המחדל של איזון העומסים של האשכול היא BALANCED.
שדרוג מאגרי צמתים רגילים באמצעות מכונות וירטואליות מסוג Spot
אם מאגרי הצמתים באשכול Standard שמשתמשים במכונות וירטואליות מסוג Spot מוגדרים לשימוש בשדרוגים מצטברים, GKE יוצר צמתים מצטברים עם מכונות וירטואליות מסוג Spot. עם זאת, GKE לא ממתין שמכונות וירטואליות מסוג Spot יהיו מוכנות לפני שהוא מבודד את הצמתים הקיימים ומרוקן אותם, כי אין ערובה לזמינות של מכונות וירטואליות מסוג Spot. מידע נוסף זמין במאמר בנושא שדרוגים של Surge.
שינויים בהתנהגות של Kubernetes
השימוש במכונות וירטואליות מסוג Spot ב-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, צריך להשתמש ב-node taints וב-tolerations.
- כדי להריץ עומסי עבודה עם שמירת מצב במכונות וירטואליות מסוג Spot, צריך לבצע בדיקה כדי לוודא שעומסי העבודה יכולים להסתיים בצורה תקינה תוך 25 שניות מסגירת המכונה, וכך לצמצם את הסיכון להשחתת נתונים בנפח אחסון קבוע.
- פועלים לפי השיטות המומלצות לסיום של Kubernetes Pod.
המאמרים הבאים
- איך משתמשים במכונות וירטואליות זמניות במאגרי הצמתים
- מידע נוסף על התאמה אוטומטית לעומס של אשכולות
- איך משנים את גודל האפליקציות שפרסתם
- מידע נוסף על מכונות וירטואליות זמניות זמין במאמרי העזרה של Compute Engine.
- מדריך לפריסת עומס עבודה באצווה באמצעות מכונות וירטואליות מסוג Spot ב-GKE