מאגרי קיבולת עוזרים לכם להפחית את זמן האחזור של הפעלת ה-Pod בעומסי העבודה שלכם ב-Google Kubernetes Engine (GKE). הם מאפשרים לכם להצהיר באופן יזום על רמות של מאגרי קיבולת פעילים או במצב המתנה באשכול. הצהרה מראש על קיבולת פנויה מאפשרת להפעיל עומסי עבודה מהר יותר בצורה חסכונית.
במאמר הזה מוסבר איך פועלים מאגרי קיבולת. במאמר הגדרת מאגרי קיבולת מוסבר איך להפעיל מאגרי קיבולת ואיך להשתמש בהם.
מתי כדאי להשתמש במרווחי ביטחון לקיבולת
משתמשים במאגרי קיבולת לאפליקציות שרגישות לזמן האחזור של ההפעלה וצריכות להתרחב במהירות. כשחווים עלייה פתאומית בתנועת הגולשים, מאגר פעיל מספק קיבולת שהוקצתה מראש ומיועדת להרחבה עם השהיה נמוכה. כשחווים עלייה מתמשכת בנפח התנועה, מאגר המתנה מספק תזמון של יחידות Pod בעלות משתלמת יותר מאשר הקצאה מראש.
היתרונות של מאגרי קיבולת:
- מזעור זמן האחזור של שינוי הגודל: מאגרי נתונים פעילים מספקים צמתים פועלים, שעוזרים למזער את זמן האחזור. מאגרי המתנה חוזרים לפעולה במהירות, ומספקים זמינות מהירה יותר של קיבולת בהשוואה לצמתים חדשים, ובעלות נמוכה יותר בהשוואה למאגרים פעילים.
- הקצאת יתר חסכונית: מאגרי קיבולת עוזרים לכם לשמור על רשת ביטחון. לעומת שיטות אחרות להקצאת יתר, כמו הורדת יעדי הניצול של כלי לשינוי גודל אוטומטי של Pod אופקי (HPA), שעלולה להגדיל את הקיבולת הפנויה באופן לינארי ככל שהאשכול גדל, הגישה הזו לרוב חסכונית יותר עבור עומסי עבודה בקנה מידה גדול.
- עמידה בדרישות של עומס העבודה: יש לכם שליטה מלאה על הגדרת מאגר הקיבולת. האפשרויות כוללות שילוב של daemonsets בהתאמה אישית כדי לטעון מראש תמונות, שיפור זמן ההפעלה ושליטה בגדלי המאגר כדי להתאים לצרכים שלכם.
מומלץ להשתמש במאגרי קיבולת לעומסי עבודה שרגישים לזמן האחזור ודורשים הגדלה מהירה של הקיבולת, כמו סוכני AI, הסקת מסקנות מ-AI, אפליקציות קמעונאיות במהלך אירועי מכירות או שרתי משחקים במהלך פעילות שיא של שחקנים.
איך פועלים מאגרי קיבולת
כדי להטמיע מאגר קיבולת, משתמשים במשאב מותאם אישית של Kubernetes CapacityBuffer כדי להגדיר מאגר של קיבולת פנויה. הכלי להתאמה אוטומטית לעומס באשכול GKE עוקב אחרי משאבי CapacityBuffer ומתייחס אליהם כאל ביקוש בהמתנה, כדי לוודא שיש קיבולת פנויה. אם באשכול אין מספיק קיבולת כדי לעמוד בבקשות למשאבים שמוגדרות במאגר, האשכול יקצה עוד צמתים באופן אוטומטי.
כשעומס עבודה בעדיפות גבוהה עובר קנה מידה, GKE מתזמן את עומס העבודה על הקיבולת הזמינה במאגר באופן מיידי. התזמון המיידי הזה חל על מספר הרפליקות או על כמות המשאבים שמוקצים במאגר, וכך נמנע העיכוב האופייני שקשור להקצאת צמתים. כשעומס עבודה משתמש ביחידת מאגר, הכלי לשינוי גודל האוטומטי של האשכול מקצה צומת חדש כדי למלא מחדש את המאגר.
אסטרטגיות של שטח אחסון זמני
אפשר להגדיר מאגרי קיבולת באמצעות אסטרטגיות שונות להקצאת משאבים, בהתאם לדרישות שלכם לגבי זמן האחזור והעלות.
הפסקה בין פגישות
מאגר פעיל מספק צמתים פעילים להרחבת עומסי עבודה (workloads) בזמן אחזור קצר, בהתאם לקיבולת השמורה. הצמתים כבר פועלים, ולכן הם מספקים השהיה מינימלית לתביעת בעלות על יחידות Pod במהלך אירוע של הגדלת קיבולת.
הפסקה בין פגישות
מאגר המתנה מספק צמתים מושעים. אסטרטגיית ההמתנה חסכונית יותר מאסטרטגיית הפעולה, אבל היא גורמת לעיכוב קצר בהפעלה מחדש של הצומת לפני שהוא מקבל עומסי עבודה.
עלות ותמחור
מאגרי קיבולת מסופקים ללא עלות נוספת, בנוסף לעלויות הרגילות של מחשוב מבוסס-צמתים, שחלות על מאגרי צמתים רגילים ועל עומסי עבודה ב-Autopilot שבוחרים חומרה ספציפית. מאגרי קיבולת לא תומכים במודל החיוב מבוסס ה-Pod.
החיוב על הצמתים הבסיסיים משתנה בהתאם לסוג המאגר:
- מאגרי זיכרון פעילים: אתם מחויבים בתעריפי מחשוב רגילים על בסיס צמתים עבור המכונות הווירטואליות הפועלות ש-GKE מתחזק כדי לשמש כקיבולת של מאגר זיכרון פעיל.
- מאגרי המתנה: בזמן שהמכונות הווירטואליות מושעות, אתם לא משלמים על עלויות מחשוב (מעבד או זיכרון). תחויבו בעלויות אחסון קלות (למשל, דיסקים להפעלה של מכונות וירטואליות ומצב זיכרון מאוחסן) ובעלויות של משאבים משויכים כמו כתובות IP חיצוניות סטטיות. כש-GKE מפעיל מחדש את המכונות הווירטואליות במצב המתנה כדי לארח עומסי עבודה, חלים תעריפים רגילים לחישוב עלויות על בסיס צמתים. למידע נוסף, ראו תמחור של מופעים מושעים.
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.
- צמצום זמן הטעינה של הפעלה מההתחלה (cold startup) כשמשנים את קנה המידה של עומסי עבודה מאפס: משייכים עומסי עבודה שמשנים את קנה המידה שלהם לאפס ומאפס באמצעות HPA (
minReplicas: 0) עם מאגרי קיבולת. כשהביקוש גדל ועומס העבודה גדל מאפס, GKE מתזמן באופן מיידי את ה-Pods בצמתי מאגר מחוממים מראש, במקום לחכות להקצאה של צמתי מחשוב חדשים.
דרישות ומגבלות
יש דרישות ומגבלות לגבי מאגרי קיבולת:
- מאגרי קיבולת זמינים באשכולות GKE בגרסה 1.35.2-gke.1842000 ואילך למאגרים פעילים, ובגרסה 1.36.0-gke.2253000 למאגרי המתנה.
- מאגרי קיבולת תומכים רק בעומסי עבודה שמשתמשים במודל חיוב מבוסס-צמתים עבור מאגרי צמתים רגילים ומאגרי צמתים של Autopilot שבהם נבחר חומרה ספציפית. מאגרי קיבולת לא תומכים בעומסי עבודה שמשתמשים במודל החיוב מבוסס-ה-Pod.
- בקטגוריית Standard clusters, מומלץ להפעיל את התכונה node auto-provisioning. הקצאת צמתים אוטומטית מאפשרת לכלי להתאמה אוטומטית של גודל האשכול ליצור מאגרי צמתים חדשים על סמך בקשות המשאבים ב-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.
- משך תהליך ההשעיה הוא ביחס לגודל הזיכרון.
- ההפעלה מחדש תלויה בזמינות של משאבי הבסיס שנדרשים להפעלה מחדש.
המאמרים הבאים
- במאמר הגדרת מאגרי קיבולת מוסבר איך להטמיע מאגר קיבולת.