מאגרי קיבולת עוזרים לכם להקטין את זמן האחזור של הפעלת 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 שמפנים אליה. ההגדרה הזו היא הדרך הכי פשוטה ליצור מאגר בגודל ידוע.
- מגבלות משאבים: מציינים את הכמות הכוללת של המעבד (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.
- אם התלות בהגדרת CapacityBuffer (לדוגמה, PodTemplate) בוחרת ComputeClass מותאם אישית, התלות חייבת להגדיר את כל הסבילות, בוררי הצמתים או מחלקות זמן הריצה שנדרשים לתזמון בצמתים שהוקצו (לדוגמה, דרישות ל-GKE Sandbox). הוראות מפורטות זמינות במסמכי התיעוד של ComputeClass בהתאמה אישית.
ההגבלות הנוספות שחלות על מאגרי זמן המתנה:
- הם נתמכים באשכולות רגילים שבהם מופעלת הקצאת משאבים אוטומטית של צמתים.
- הם נתמכים באשכולות Autopilot שפועלת בהם גרסה 1.36.0-gke.2853000 ואילך.
- אין תמיכה בצמתים עם יחידות GPU או TPU מצורפות.
- אין תמיכה בכונני SSD מקומיים.
- אין תמיכה בצמתים סודיים של Google Kubernetes Engine.
- חשוב להכיר את המגבלות שקשורות לפעולות השהיה והפעלה מחדש ב-Compute Engine.
אלה כמה מהמגבלות העיקריות:
- אין תמיכה בצמתים עם דיסקים שמוגנים באמצעות מפתחות הצפנה באספקת הלקוח (CSEK).
- אין תמיכה בצמתים עם זיכרון בנפח של יותר מ-208 GB.
- אין תמיכה במופעי Bare metal.
- מערכת ההפעלה של הצומת צריכה לתמוך באותות שינה ACPI S3.
- משך תהליך ההשעיה הוא ביחס לגודל הזיכרון.
- ההפעלה מחדש תלויה בזמינות של המשאבים הבסיסיים שנדרשים להפעלה מחדש.
המאמרים הבאים
- במאמר הגדרת מאגרי קיבולת מוסבר איך להטמיע מאגר קיבולת.