מאגרים זמניים למשאבי מחשוב עוזרים לכם לצמצם את זמן האחזור בהפעלת Pod בעומסי העבודה של Google Kubernetes Engine (GKE), בכך שהם מאפשרים לכם להצהיר באופן יזום על רמות של מאגרים זמניים פעילים או במצב המתנה למשאבי מחשוב באשכול. אם תצהירו על קיבולת פנויה מראש, תוכלו להפעיל עומסי עבודה מהר יותר ובצורה חסכונית.
במאמר הזה מוסבר איך פועלים מאגרים זמניים למשאבי מחשוב. במאמר הגדרת מאגרים זמניים למשאבי מחשוב מוסבר איך להפעיל את המאגרים הזמניים ולהשתמש בהם.
מתי כדאי להשתמש במאגרים זמניים למשאבי מחשוב
כדאי להשתמש במאגרים זמניים למשאבי מחשוב באפליקציות שרגישות לזמן האחזור בהפעלה וצריכות להתאים את עצמן לעומס במהירות. אם יש עלייה פתאומית בתנועה, מאגר פעיל מספק קיבולת שהוקצתה מראש ומיועדת להתאמה לעומס (scaling) עם זמן אחזור קצר. אם יש עלייה מתמשכת בתנועה, מאגר המתנה מספק תזמון Pod בעלות משתלמת יותר מאשר הקצאה מראש.
היתרונות של מאגרים זמניים למשאבי מחשוב:
- צמצום זמן האחזור של ההתאמה לעומס (scaling): מאגרים פעילים מספקים צמתים פועלים, שעוזרים לצמצם את זמן האחזור. מאגרים זמניים במצב המתנה מתחדשים במהירות, ומספקים זמינות קיבולת מהירה יותר מאשר צמתים חדשים, בעלות נמוכה יותר בהשוואה למאגרים זמניים פעילים.
- הקצאת יתר חסכונית: מאגרים זמניים למשאבי מחשוב עוזרים לכם לשמור על רשת ביטחון. בעומסי עבודה בקנה מידה גדול, הגישה הזו בדרך כלל חסכונית יותר משיטות אחרות של הקצאת יתר, כמו הורדת יעדי הניצול של Horizontal Pod Autoscaler (HPA), שיכולה להגדיל את הקיבולת הלא מנוצלת באופן ליניארי ככל שהאשכול גדל.
- עמידה בדרישות של עומסי העבודה: יש לכם שליטה מלאה על ההגדרות של המאגר הזמני למשאבי מחשוב. האפשרויות כוללות שילוב של daemonsets בהתאמה אישית כדי לטעון מראש תמונות, לכוונן את זמן ההפעלה ולשלוט בגודל של שטח אחסון זמני בהתאם לצרכים שלכם.
מומלץ להשתמש במאגרים זמניים למשאבי מחשוב בעומסי עבודה שרגישים לזמן אחזור ודורשים הרחבה מהירה, כמו סוכני AI, הסקת מסקנות של AI, אפליקציות קמעונאיות במהלך אירועי מכירות או שרתי גיימינג במהלך פעילות שיא של שחקנים.
איך פועלים מאגרים זמניים למשאבי מחשוב
כדי להטמיע מאגר זמני למשאבי מחשוב, משתמשים במשאב מותאם אישית של Kubernetes CapacityBuffer כדי להגדיר מאגר זמני של קיבולת פנויה. הכלי להתאמה אוטומטית לעומס (autoscaler) של אשכול GKE עוקב אחרי משאבי CapacityBuffer ומתייחס אליהם כאל ביקוש בהמתנה, כדי לוודא שיש קיבולת פנויה. אם באשכול אין מספיק קיבולת כדי לענות על הקצאות המשאבים שמוגדרות במאגר נתונים זמני, המידרוג האוטומטי של האשכול מקצה צמתים נוספים.
כשעומס העבודה גדל, GKE מתזמן Pods בהמתנה לפי הקיבולת הזמינה בסדר העדיפויות הבא:
- צמתים שפועלים במאגר נתונים פעיל
- צמתים שפועלים במאגר המתנה ועדיין לא הושעו
- צמתים מושהים במאגר המתנה
- צמתים שהוקצו לאחרונה
כדי לתזמן Pods בהמתנה במהירות האפשרית, GKE משתמש בקיבולת המאגר הזמינה לפני הקצאת צמתים חדשים. העדיפות הזו חלה גם אם כלל בעדיפות גבוהה יותר ב-ComputeClass בהתאמה אישית היה מקצה צומת חדש.
קיבולת המאגר לא מוגבלת לעומס העבודה שצוין בשדה scalableRef. כל Pod בהמתנה שאילוצי התזמון שלו, כמו בוררי צמתים, סבילות ובקשות למשאבים, תואמים להגדרות של צומת המאגר, יכול לתבוע את הקיבולת הזו. כדי להקצות מאגר זמני למשאבי מחשוב לעומס עבודה ספציפי, מגדירים הפרדה של עומסי עבודה על ידי הוספת טולרנטיות ובוררי צמתים (או זיקות צמתים) תואמים גם לעומס העבודה וגם למאגר הזמני למשאבי מחשוב. איך מקצים מאגר זמני למשאבי מחשוב לעומס עבודה ספציפי
כשעומס עבודה צורך קיבולת ממאגר פעיל, מידרוג אוטומטי של קבוצת אשכולות מחדש את המאגר הפעיל על ידי חידוש צומת ממאגר המתנה תואם, אם קיים, או על ידי הקצאת צומת חדש. כשעומס עבודה או מאגר פעיל צורכים צומת ממאגר המתנה, המידרוג האוטומטי של האשכול ממלא את מאגר ההמתנה על ידי הקצאה והשעיה של צומת חדש. כאשר עומס העבודה יורד והצמתים לא מנוצלים, המידרוג האוטומטי של האשכול מוחק את הצמתים העודפים שפועלים אחרי חלון הייצוב של צמצום קנה המידה, במקום להשעות אותם מחדש למאגר ההמתנה. כדי למלא את מאגר המאגרים במצב המתנה, GKE מקצה ומשעה צמתים חדשים בנפרד.
אסטרטגיות למאגר זמני למשאבי מחשוב
אתם יכולים להגדיר מאגרים זמניים למשאבי מחשוב באמצעות אסטרטגיות שונות של הקצאת משאבים, בהתאם לדרישות שלכם לגבי זמן האחזור והעלות.
מאגר זמני פעיל
מאגר פעיל מספק צמתים פועלים להרחבה של עומסי עבודה בזמן אחזור קצר, שמתאימים לקיבולת השמורה. מכיוון שהצמתים כבר פועלים, הם מספקים זמן אחזור מינימלי לתביעת Pods במהלך אירוע של הגדלת נפח.
מאגר זמני במצב המתנה
מאגר המתנה מספק צמתים מושעים. אסטרטגיית ההמתנה חסכונית יותר מאסטרטגיית הפעילות, אבל היא גורמת לעיכוב קצר בהפעלת הצומת מחדש לפני שהוא מקבל עומסי עבודה.
עלות ותמחור
המאגרים הזמניים למשאבי מחשוב ניתנים ללא תשלום נוסף, מעבר לעלויות המחשוב הרגילות שמבוססות על צמתים, שחלות על מאגרי צמתים רגילים ועל עומסי עבודה ב-Autopilot שבוחרים חומרה ספציפית. אי אפשר להשתמש במאגרים זמניים למשאבי מחשוב במודל החיוב שמבוסס על Pod.
החיוב על הצמתים הבסיסיים משתנה בהתאם לסוג המאגר:
- מאגרים פעילים: אתם מחויבים בתעריפי מחשוב רגילים שמבוססים על צמתים, עבור המכונות הווירטואליות הפועלות ש-GKE מתחזק כדי שישמשו כקיבולת מאגר פעילה.
- מאגרי המתנה: כשהמכונות הווירטואליות מושעות, אתם לא משלמים על עלויות המחשוב (מעבד או זיכרון). תחויבו בעלויות אחסון קטנות (למשל, דיסקים לאתחול של מכונות וירטואליות ומצב הזיכרון המאוחסן) ובעלויות של משאבים משויכים, כמו כתובות IP חיצוניות סטטיות. כש-GKE מפעיל מחדש את המכונות הווירטואליות במצב המתנה כדי לארח עומסי עבודה, חלים תעריפי המחשוב הרגילים שמבוססים על צמתים. למידע נוסף, ראו תמחור של מכונות מושעות.
CapacityBuffer CRD
כדי להגדיר מאגר זמני למשאבי מחשוב, יוצרים CapacityBuffer CustomResourceDefinition (CRD). אתם יכולים להגדיר את המאגר הזמני למשאבי מחשוב לפי קריטריונים שונים:
- Fixed replicas: מציינים מספר קבוע של פודים למאגר שרוצים ליצור, על סמך בקשות המשאבים של תבנית פוד שאליה מפנים. ההגדרה הזו היא הדרך הפשוטה ביותר ליצור מאגר נתונים בגודל ידוע.
- מגבלות משאבים: מציינים את הכמות הכוללת של המעבד (CPU) והזיכרון שהמאגר צריך לשמור. הבקר מחשב כמה פודים של מאגר זמני צריך ליצור על סמך בקשות המשאבים של תבנית פוד שאליה מפנים.
- מבוסס-אחוזים: מגדירים את גודל שטח האחסון הזמני כאחוז מאובייקט קיים שניתן להתאמה, שמגדיר משאב משני של התאמה (כמו Deployment, StatefulSet, ReplicaSet או Job). גודל שטח האחסון הזמני משתנה באופן דינמי בהתאם לעומס העבודה של קובץ העזר. מאגרים זמניים למשאבי מחשוב שמבוססים על אחוזים נתמכים רק באובייקטים שמטמיעים את משאב המשנה של קנה המידה ב-Kubernetes.
אפשר לשלב את האפשרויות האלה, למשל להגדיר גם את replicas וגם את percentage כדי ש-GKE ישתמש בערך הגדול יותר כרף מינימלי, ולהגדיר את limits כגבול עליון.
מידע נוסף זמין במאמרי העזרה של CapacityBuffer CRD.
שיטות מומלצות
כדי להגדיר מאגרים זמניים למשאבי מחשוב בצורה חסכונית ומהירה, מומלץ לפעול לפי ההנחיות הבאות:
- אסטרטגיה של עלות אופטימלית, קודם המתנה: תנו עדיפות למאגרי המתנה אם עומסי העבודה שלכם יכולים לסבול עיכוב קצר בהגדלת קנה המידה של כ-30 שניות. האסטרטגיה הזו מונעת הפעלה קרה של צומת במכונות וירטואליות חדשות, בלי לשלם את העלות המלאה של מכונות וירטואליות פעילות.
- שימוש במאגרים פעילים לעומסי עבודה שרגישים לזמן אחזור: השתמשו במאגרים פעילים לעומסי עבודה שלא יכולים לסבול את זמני החידוש של הצמתים, כשזמן התזמון של Pod צריך להיות קצר ככל האפשר.
- שימוש באסטרטגיה משולבת כדי לאזן בין ביצועים לעלות: שילוב של מאגר פעיל קטן עם מאגר המתנה גדול יותר, כדי ליצור הגדרה חסכונית. GKE נותן עדיפות למילוי מחדש של המאגר הפעיל על ידי חידוש הצמתים ממאגר ההמתנה (תהליך שנמשך כ-30 שניות), בזמן שצמתים חדשים מוקצים ברקע כדי למלא מחדש את מאגר ההמתנה. ההגדרה הזו סופגת את העליות החדות הראשוניות באמצעות קיבולת פעילה, ומתאימה לצמיחה מתמשכת באמצעות קיבולת המתנה בעלות נמוכה יותר.
- הגדרת גודל המאגרים הפעילים לעומסים ראשוניים: הגדירו את גודל המאגר הפעיל כך שיכסה את העליות הפתאומיות הראשוניות ברפליקות שאתם צופים שתיתקלו בהן, לפני שצומתי המאגרים במצב המתנה יוכלו להמשיך לפעול.
- הגדרת גודל למאגרי הנתונים הזמניים במצב המתנה לעומס מתמשך: הגדירו מאגרי נתונים זמניים במצב המתנה שמספיקים כדי לכסות את העומס המורחב שאתם צפויים להיתקל בו, כך שמאגרי הנתונים הזמניים יוכלו להתמלא מחדש ברקע מהפעלה קרה. מאגר המתנה בגודל מספיק יכול להפחית את זמן האחזור המקסימלי של תזמון Pod לזמן שלוקח להמשיך צומת, שהוא בערך 30 שניות. כשמתחילים להשתמש במאגר הזמני למשאבי מחשוב והוא מתמלא מחדש, צומתי מאגר חדשים עוברים למצב פעיל לפני ההשעיה. האסטרטגיה הזו עוזרת להגדיל את הקיבולת הפעילה בזמן עומס ממושך.
- שימוש בסימולטור שטח האחסון הזמני: התנסות בגדלים שונים של שטחי אחסון זמני פעילים ושל שטחי אחסון זמני במצב המתנה כדי לקבל את התוצאה הטובה ביותר לעומס העבודה הספציפי שלכם. כדי לכוונן את הכללים של גודל שטח האחסון הזמני ולהשיג את יעדי הביצועים, אתם יכולים להריץ סימולציות של התנהגות שינוי קנה המידה של עומס העבודה באמצעות סימולטור המאגרים של GKE בקוד פתוח בכתובת https://github.com/gke-labs/buffers-simulator.
- צמצום זמן האחזור של הפעלה במצב התחלתי (cold start) כשמגדילים עומסי עבודה מאפס: משלבים עומסי עבודה שמגדילים ומקטינים מאפס באמצעות HPA (
minReplicas: 0) עם מאגרים זמניים למשאבי מחשוב. כשהביקוש עולה ועומס העבודה גדל מאפס, GKE מתזמן מיד Pods בצומתי מאגר שחוממו מראש, במקום להמתין להקצאה של צומתי מחשוב חדשים. - שימו לב ל
optimize-utilizationפרופיל ההתאמה האוטומטית לעומס באשכולות רגילים: מכיוון שהמאגרים הזמניים למשאבי מחשוב כבר שומרים על מרווח פנוי, אתם יכולים להגדיר אתoptimize-utilizationפרופיל ההתאמה האוטומטית לעומס (--autoscaling-profile=optimize-utilization) כך שההתאמה האוטומטית לעומס באשכול תצמצם אנכית בהתאם לעומס (scale down) צמתים שלא מנוצלים מספיק, במהירות רבה יותר אחרי שהביקוש יורד. בפרופיל הזה גם מתבצעת דחיסה הדוקה יותר של Pods בצמתים, לכן לפני שמפעילים אותו, חשוב לבדוק אם סידור הדוק יותר בקונטיינרים (bin packing) מתאים לדרישות הזמינות של עומס העבודה.
חישוב גודל שטח אחסון זמני
כשמשלבים מאגר פעיל עם מאגר המתנה, אפשר להעריך את מספר הרפליקות של המאגר, או את מספר הפודים המדומים של המאגר, שנדרשים כדי לספוג עלייה חדה בתנועה. כדי לחשב את ההערכה הזו, צריך להשתמש בקצב הגדלת הנפח הצפוי ב-Pods לשנייה, בזמן האחזור של חידוש הפעולה של צומת במצב המתנה ובזמן האחזור של יצירת צומת במצב קר. זמני האחזור האלה משתנים בהתאם לסדרת המכונות הווירטואליות ולהגדרות הצומת. לדוגמה, זמן האחזור של חידוש הפעולה של צומת במצב המתנה הוא בדרך כלל 30 עד 35 שניות, וזמן האחזור של יצירת צומת חדש הוא בדרך כלל 60 עד 120 שניות, בהתאם לסדרת המכונות. כדי למדוד את זמני האחזור בפועל של האשכול, קראו את המאמר מעקב אחרי מדדי זמן האחזור בהפעלה.
חשבו את גודל שטח האחסון הזמני הפעיל כדי לכסות את ה-Pods שנוצרו בזמן שצומתי ההמתנה ממשיכים לפעול:
\[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]
מחשבים את גודל שטח האחסון הזמני במצב המתנה כדי לכסות את ה-Pods שנוצרו בזמן שהקצאת המשאבים לצמתים הקרים החדשים מסתיימת:
\[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]
לדוגמה, אם עומס העבודה גדל בקצב של 2 Pods לשנייה, לצמתים במצב המתנה נדרשות 30 שניות כדי לחזור לפעולה, ולצמתים חדשים במצב קר נדרשות 90 שניות להקצאה:
- המאגר הפעיל צריך \( 2 \times 30 = 60 \) רפליקות כדי לספוג את 30 השניות הראשונות של העלייה החדה.
- מאגר הנתונים הזמני במצב המתנה צריך \( (2 \times 90) - 60 = 120 \) רפליקות כדי לכסות את 60 השניות שנותרו, בזמן שההתאמה האוטומטית לעומס באשכול מקצה צמתים קרים חדשים ברקע כדי למלא מחדש את מאגרי הנתונים הזמניים. אם העלייה החדה נמשכת מעבר ל-90 שניות באותו קצב, הצמתים שנוספו מוכנים לשרת את ה-Pods הנכנסים ללא זמן המתנה.
כדי לבדוק את ההערכות האלה ביחס לדפוסי ההתאמה לעומס (scaling) של עומסי העבודה, אתם יכולים להריץ סימולציות באמצעות הסימולטור של מאגרי הנתונים הזמניים ב-GKE.
מדרגיות
אין מגבלות קשיחות על מאגרים זמניים למשאבי מחשוב, אבל חריגה מההיקף המומלץ עלולה להאט את הקצאת הצמתים ואת תזמון ה-Pods. רפליקות של מאגרים זמניים הן פודים מדומים של מאגרים זמניים שהמאגר הזמני שומר להם קיבולת, ולא צמתים. כדי שהאשכול יפעל בצורה אמינה, חשוב להקפיד על ההנחיות הבאות:
| סוג המאגר | סה"כ רפליקות של מאגר נתונים זמני לכל אשכול | מאגרי נתונים זמניים לכל אשכול |
|---|---|---|
| מאגרי נתונים זמניים פעילים | עד 7,000 | עד 100 |
| מאגרי נתונים זמניים בהמתנה | עד 5,000 | עד 25 |
גם במאגרים פעילים וגם במאגרים במצב המתנה, כדאי להימנע מיצירת הרבה מאגרים שכל אחד מהם דורש מאגר נפרד של צמתים, כמו מאגרים שמשתמשים בהגדרות שונות של ComputeClasses או של הפרדת עומסי עבודה. כשהמידרוג האוטומטי של האשכול מספק צמתים חדשים, הוא מרחיב אנכית מאגר צמתים אחד בכל פעם, ולכן לוקח יותר זמן למלא ולמלא מחדש את מאגרי הנתונים הזמניים בצמתים חדשים כשמוסיפים עוד מאגרי נתונים זמניים. המגבלה הזו לא חלה על חידוש הפעולה של צמתים מושהים במאגרי המתנה.
דרישות ומגבלות
אלה הדרישות והמגבלות של מאגרים זמניים למשאבי מחשוב:
- אפשר להשתמש במאגרים זמניים למשאבי מחשוב באשכולות GKE שפועלים בגרסה 1.37.1-gke.3020000 ואילך.
- מאגרים זמניים למשאבי מחשוב תומכים רק בעומסי עבודה שמשתמשים במודל חיוב שמבוסס על צמתים למאגרי צמתים רגילים ולמאגרי צמתים של Autopilot שבוחרים חומרה ספציפית. אי אפשר להשתמש במאגרים זמניים למשאבי מחשוב בעומסי עבודה שמשתמשים במודל החיוב שמבוסס על Pod.
- באשכולות Standard, מומלץ להפעיל את היצירה האוטומטית של מאגרי צמתים. התכונה "יצירה אוטומטית של מאגרי צמתים" מאפשרת למידרוג האוטומטי של האשכול ליצור מאגרי צמתים חדשים על סמך הקצאות המשאבים ב-CapacityBuffer. אם לא תפעילו את היצירה האוטומטית של מאגרי צמתים, המידרוג האוטומטי של האשכול יגדיל רק את מאגרי הצמתים הקיימים.
- מאגרים זמניים פעילים למשאבי מחשוב ומאגרים זמניים במצב המתנה למשאבי מחשוב צורכים מכסות באופן שונה:
- צמתים שפועלים במאגר פעיל נספרים כחלק מהמכסות של Compute Engine למעבדים וירטואליים, לזיכרון, לדיסק ולכתובות IP.
- צמתים מושעים במאגר המתנה לא נספרים במכסות הזיכרון או ה-vCPU של Compute Engine בזמן שהם מושעים. עם זאת, הן ממשיכות לצרוך מכסות של כתובות IP ומכסות דיסק, כולל המכסה של
Persistent disk standard (GB)שמשמשת לאחסון הזיכרון של המכונה הווירטואלית המושהית. - ב-Kubernetes, גם יחידות מאגר פעילות וגם יחידות מאגר מושעות נכללות במכסות המשאבים של Kubernetes במרחב השמות, כאילו הפודים של המאגר פועלים.
- אם התלות בהגדרת CapacityBuffer (לדוגמה, PodTemplate) בוחרת ComputeClass בהתאמה אישית, התלות חייבת להגדיר את כל הטולרנטיות, בוררי הצמתים או מחלקות זמן הריצה שנדרשות לתזמון בצמתים שהוקצו (לדוגמה, דרישות ל-GKE Sandbox). איך מגדירים ComputeClass בהתאמה אישית
למאגרי נתונים זמניים במצב המתנה יש את המגבלות הנוספות הבאות:
- הם נתמכים באשכולות Standard שמופעלת בהם יצירה אוטומטית של מאגרי צמתים.
- הם נתמכים באשכולות Autopilot עם ComputeClasses בהתאמה אישית.
- אין תמיכה בצמתים עם יחידות GPU או TPU מצורפות.
- אין תמיכה בכונני SSD מקומיים.
- למרות שמאגרי הנתונים הזמניים במצב המתנה תומכים במפתחות הצפנה בניהול הלקוח (CMEK) לאחסון של הצומת, הזיכרון של הצומת מוצפן באמצעות Google-owned and Google-managed encryption keys במהלך ההשעיה.
- אין תמיכה בצמתים של Google Kubernetes Engine Confidential.
- מאגרי הנתונים הזמניים במצב המתנה תומכים רק במערכת הפעלה שמותאמת לקונטיינרים של GKE ובקובצי אימג' של צומת Ubuntu. אין תמיכה בצמתים של Windows Server. אם אתם משתמשים במערכת הפעלה מותאמת אישית של צומת, אתם צריכים לוודא שמערכת ההפעלה תומכת בפעולות ההשהיה וההמשך של Compute Engine.
- חשוב להכיר את המגבלות שקשורות לפעולות ההשהיה וההמשך של Compute Engine.
הנה כמה מהמגבלות העיקריות:
- אין תמיכה בצמתים עם דיסקים שמוגנים באמצעות מפתחות הצפנה באספקת הלקוח (CSEK).
- אין תמיכה בצמתים עם זיכרון של יותר מ-208GB.
- אין תמיכה במכונות Bare Metal.
- מערכת ההפעלה של הצומת צריכה לתמוך באותות שינה של ACPI S3.
- משך תהליך ההשעיה הוא פרופורציונלי לגודל הזיכרון.