מאגרי קיבולת עוזרים לכם להקטין את זמן האחזור של הפעלת Pod בעומסי העבודה של Google Kubernetes Engine (GKE). הם מאפשרים לכם להצהיר מראש על רמות של מאגרי קיבולת פעילים או במצב המתנה באשכול. הצהרה מראש על קיבולת פנויה מאפשרת להפעיל עומסי עבודה מהר יותר בצורה חסכונית.
במאמר הזה מוסבר איך פועלים מאגרי קיבולת. במאמר הגדרת מאגרי קיבולת מוסבר איך להפעיל מאגרי קיבולת ואיך להשתמש בהם.
מתי כדאי להשתמש במאגרי קיבולת
משתמשים במאגרי קיבולת לאפליקציות שרגישות לזמן האחזור של ההפעלה וצריכות להתרחב במהירות. כשחווים עלייה פתאומית בתנועת הגולשים, מאגר פעיל מספק קיבולת שהוקצתה מראש ומיועדת להרחבה עם השהיה נמוכה. אם יש עלייה מתמשכת בתנועה, מאגר המתנה מספק תזמון של יחידות Pod בעלות משתלמת יותר מאשר הקצאה מראש.
היתרונות של מאגרי קיבולת:
- מזעור זמן האחזור של שינוי הגודל: מאגרי נתונים פעילים מספקים צמתים פועלים, שעוזרים למזער את זמן האחזור. מאגרי המתנה חוזרים לפעולה במהירות, ומספקים זמינות מהירה יותר של קיבולת בהשוואה לצמתים חדשים, ובעלות נמוכה יותר בהשוואה למאגרים פעילים.
- הקצאת יתר חסכונית: מאגרי קיבולת עוזרים לכם לשמור על רשת ביטחון. בעומסי עבודה גדולים, הגישה הזו לרוב חסכונית יותר משיטות אחרות להקצאת יתר (לדוגמה, הורדת יעדי הניצול של HorizontalPodAutoscaler (HPA)), שיכולות להגדיל את הקיבולת הפנויה באופן לינארי ככל שהאשכול גדל.
- עמידה בדרישות של עומס העבודה: יש לכם שליטה מלאה בהגדרת מאגר הקיבולת. האפשרויות כוללות שילוב של daemonsets בהתאמה אישית כדי לטעון מראש תמונות, שיפור זמן ההפעלה ושליטה בגדלי המאגר כדי להתאים לצרכים שלכם.
מומלץ להשתמש במאגרי קיבולת לעומסי עבודה שרגישים לזמן האחזור ודורשים הגדלה מהירה של הקיבולת, כמו סוכני AI, הסקת מסקנות מ-AI, אפליקציות קמעונאיות במהלך אירועי מכירות או שרתי משחקים במהלך פעילות שיא של שחקנים.
איך פועלים מאגרי קיבולת
כדי להטמיע מאגר קיבולת, משתמשים במשאב מותאם אישית של Kubernetes CapacityBuffer כדי להגדיר מאגר של קיבולת פנויה. הכלי להתאמה אוטומטית לעומס ב-אשכול GKE עוקב אחרי משאבי CapacityBuffer ומתייחס אליהם כאל ביקוש בהמתנה, כדי לוודא שיש קיבולת פנויה. אם אין לאשכול מספיק קיבולת כדי לעמוד בבקשות למשאבים שהוגדרו במאגר, האשכול יקצה אוטומטית צמתים נוספים.
כשעומס עבודה בעדיפות גבוהה מתרחב, GKE מתזמן את עומס העבודה על הקיבולת הזמינה במאגר באופן מיידי. התזמון המיידי הזה חל על מספר העותקים או על כמות המשאבים שמוקצים במאגר, וכך נמנע העיכוב האופייני שקשור להקצאת צמתים. כשעומס עבודה משתמש ביחידת מאגר, הכלי לשינוי גודל האשכול באופן אוטומטי מקצה צומת חדש כדי למלא מחדש את המאגר.
אסטרטגיות של מאגר קיבולת
אפשר להגדיר מאגרי קיבולת באמצעות אסטרטגיות שונות להקצאת משאבים, בהתאם לדרישות שלכם לגבי זמן האחזור והעלות.
מאגר נתונים זמני פעיל
מאגר פעיל מספק צמתים פעילים להרחבת עומסי עבודה (workloads) עם זמן אחזור קצר, שמתאימים לקיבולת השמורה. הצמתים כבר פועלים, ולכן הם מספקים השהיה מינימלית לתביעת בעלות על יחידות Pod במהלך אירוע של הגדלת קיבולת.
מרווח המתנה
מאגר המתנה מספק צמתים מושעים. אסטרטגיית ההמתנה חסכונית יותר מאסטרטגיית הפעילות, אבל היא גורמת לעיכוב קצר בהפעלה מחדש של הצומת לפני שהוא מקבל עומסי עבודה.
עלות ותמחור
החיוב על מאגרי קיבולת משתנה בהתאם לסוג המאגר:
- מאגרי נתונים פעילים: אתם מחויבים לפי תעריפי מחשוב רגילים של GKE עבור המכונות הווירטואליות הפועלות ש-GKE מתחזק כדי לשמש כקיבולת מאגר נתונים פעיל. במצב אוטומטי, חלים תעריפי חיוב רגילים שמבוססים על Pod על הפעלת ה-Pods.
- מאגרי המתנה: בזמן שהמכונות הווירטואליות מושעות, אתם לא משלמים על עלויות מחשוב (מעבד או זיכרון). תחויבו בעלויות אחסון קלות (למשל, דיסקים להפעלה של מכונות וירטואליות) ובעלויות של משאבים משויכים כמו כתובות IP חיצוניות סטטיות. כש-GKE מפעיל מחדש את המכונות הווירטואליות במצב המתנה כדי לארח עומסי עבודה, חלים תעריפי חיוב רגילים של מחשוב או תעריפים שמבוססים על Pod.
CRD CapacityBuffer
כדי להגדיר מאגר קיבולת, יוצרים CapacityBuffer CustomResourceDefinition (CRD). אתם יכולים להגדיר את מאגר הקיבולת כך שיתאים לקריטריונים שונים:
- עותקים קבועים: מציינים מספר קבוע של תרמילי Pod של מאגר זמני שייווצרו על סמך בקשות המשאבים של תבנית Pod שמפנים אליה. ההגדרה הזו היא הדרך הכי פשוטה ליצור מאגר בגודל ידוע.
- מגבלות משאבים: מציינים את הכמות הכוללת של המעבד (CPU) והזיכרון שהמאגר צריך לשריין. הבקר מחשב כמה תרמילי Pod של מאגר צריך ליצור על סמך בקשות המשאבים של תבנית Pod שאליה יש הפניה.
- מבוסס על אחוזים: מגדירים את גודל שטח האחסון הזמני כאחוז מאובייקט קיים שניתן להרחבה ומגדיר משאב משנה של קנה מידה (כמו Deployment, StatefulSet, ReplicaSet או Job). גודל שטח האחסון הזמני משתנה באופן דינמי ככל שעומס העבודה של ההפניה גדל. אפשר להשתמש במאגרי קיבולת מבוססי-אחוזים רק באובייקטים שמטמיעים את משאב המשנה scale של Kubernetes.
מידע נוסף מופיע במאמרי העזרה בנושא CapacityBuffer CRD.
שיטות מומלצות
כדי לבצע אופטימיזציה של יעילות העלויות ושל הרספונסיביות כשמגדירים מאגרי קיבולת, מומלץ לפעול לפי ההמלצות הבאות:
- שימוש באסטרטגיה שמתמקדת בחיסכון בעלויות ובהמתנה: כדאי לתת עדיפות למאגרי המתנה אם עומסי העבודה יכולים לעמוד בעיכוב קצר בהרחבה של כ-30 שניות. האסטרטגיה הזו מאפשרת להימנע מהפעלה של צמתים קרים של מכונות VM חדשות, בלי לשלם את העלות המלאה של מכונות VM פעילות.
- שימוש במאגרי נתונים פעילים לעומסי עבודה שרגישים לזמן האחזור: שימוש במאגרי נתונים פעילים לעומסי עבודה שלא יכולים לסבול זמני הפעלה מחדש של צמתים, כשזמן התזמון של ה-Pod צריך להיות נמוך ככל האפשר.
- שימוש באסטרטגיה היברידית כדי לאזן בין ביצועים לעלות: שילוב של מאגר קטן פעיל עם מאגר גדול יותר במצב המתנה, כדי ליצור הגדרה חסכונית. מערכת GKE נותנת עדיפות למילוי מחדש של המאגר הפעיל על ידי הפעלה מחדש של צמתים מהמאגר במצב המתנה (התהליך נמשך כ-30 שניות), בזמן שצמתים חדשים מוקצים ברקע כדי למלא מחדש את המאגר במצב המתנה. ההגדרה הזו מאפשרת לספוג עליות ראשוניות באמצעות קיבולת פעילה, ומאפשרת צמיחה מתמשכת באמצעות קיבולת בהמתנה בעלות נמוכה יותר.
- הגדרת הגודל של מאגרי נתונים פעילים לפרצי נתונים ראשוניים: מגדירים את הגודל של מאגר הנתונים הפעיל כדי לכסות את העליות הפתאומיות הראשוניות של העותקים שצפויות להתרחש, לפני שצמתי מאגר הנתונים במצב המתנה יוכלו לחזור לפעולה.
- הגדרת גודל מאגרי נתונים זמניים למצב המתנה עבור עומס מתמשך: הגדרת מאגרי נתונים זמניים למצב המתנה שיספיקו לעומס המורחב שצפוי, כדי שמאגרי הנתונים הזמניים יוכלו להתמלא מחדש ברקע לאחר הפעלה במצב התחלתי (cold start). מאגר המתנה בגודל מספיק יכול להקטין את זמן האחזור המקסימלי של תזמון ה-Pod לזמן שנדרש להפעלת צומת, שהוא בערך 30 שניות. כשהמאגר של הקיבולת מתחיל לשמש ומתמלא מחדש, צמתים חדשים במאגר עוברים למצב פעיל לפני שהם מושעים. האסטרטגיה הזו עוזרת להגדיל את הקיבולת הפעילה במהלך עומס ממושך.
- שימוש בסימולטור של מאגר זמני: אפשר להתנסות בגדלים שונים של מאגר זמני פעיל ומאגר זמני בהמתנה כדי לקבל את התוצאה הטובה ביותר עבור עומס העבודה הספציפי שלכם. כדי לכוונן את כללי הגודל של המאגרים ולהשיג את יעדי הביצועים, אפשר להריץ סימולציות של התנהגות שינוי הגודל של עומסי העבודה באמצעות סימולטור המאגרים של GKE בקוד פתוח בכתובת https://github.com/gke-labs/buffers-simulator.
דרישות ומגבלות
אלה הדרישות והמגבלות שחלות על מאגרי קיבולת:
- מאגרי קיבולת זמינים באשכולות GKE שמריצים גרסה 1.35.2-gke.1842000 ואילך למאגרים פעילים, וגרסה 1.36.0-gke.2253000 למאגרי המתנה.
- מאגרי קיבולת תומכים רק בעומסי עבודה שמשתמשים במודל חיוב מבוסס-צמתים עבור מאגרי צמתים רגילים ומאגרי צמתים של Autopilot שבוחרים חומרה ספציפית. מאגרי קיבולת לא תומכים בעומסי עבודה שמשתמשים במודל החיוב מבוסס-ה-Pod.
- בקטגוריית Standard clusters, מומלץ להפעיל את התכונה node auto-provisioning. הקצאת צמתים אוטומטית (NAP) מאפשרת לכלי להתאמה אוטומטית של גודל האשכול ליצור מאגרי צמתים חדשים על סמך בקשות המשאבים ב-CapacityBuffer. אם לא מפעילים הקצאה אוטומטית של צמתים, המידרוג האוטומטי של האשכול מרחיב רק את מאגרי הצמתים הקיימים.
- גם מאגרי קיבולת פעילים וגם מאגרי קיבולת במצב המתנה נכללים במכסות של Compute Engine.
המאגרים במצב המתנה כפופים למגבלות הנוספות הבאות:
- הם נתמכים רק באשכולות Standard עם הקצאת משאבים אוטומטית של צמתים.
- אין תמיכה בצמתים עם יחידות GPU או TPU מצורפות.
- אין תמיכה בכונני SSD מקומיים.
- אין תמיכה במפתחות הצפנה בניהול הלקוח (CMEK).
- אין תמיכה בצמתים סודיים של Google Kubernetes Engine.
- חשוב להכיר את המגבלות שקשורות לפעולות השהיה והפעלה מחדש ב-Compute Engine.
אלה כמה מהמגבלות העיקריות:
- אין תמיכה בצמתים עם דיסקים שמוגנים באמצעות מפתחות הצפנה באספקת הלקוח (CSEK).
- אין תמיכה בצמתים עם זיכרון בנפח של יותר מ-208 GB.
- אין תמיכה במופעי Bare metal.
- מערכת ההפעלה של הצומת צריכה לתמוך באותות שינה ACPI S3.
- משך תהליך ההשעיה הוא ביחס לגודל הזיכרון.
- ההפעלה מחדש תלויה בזמינות של המשאבים הבסיסיים שנדרשים להפעלה מחדש.
המאמרים הבאים
- במאמר הגדרת מאגרי קיבולת מוסבר איך להטמיע מאגר קיבולת.