עיצוב והגדרה של אשכולות GKE לאופטימיזציה של עלויות

במאמר הזה מוסבר איך לעיין במסמכי התיעוד של Google Kubernetes Engine ‏ (GKE) כדי למצוא הנחיות והמלצות לאופטימיזציה של עלויות. ‫GKE מציע יכולות נרחבות של שינוי גודל אוטומטי ותזמון, שבעזרתן אפשר לצמצם את עלות האשכול תוך שמירה על יציבות האפליקציה.

סקירה מרוכזת של כל השיטות המומלצות ל-GKE זמינה במאמר שיטות מומלצות ל-GKE.

חשוב לוודא שאתם כבר מכירים את הנושאים הבאים:

סקירה כללית

כשמטמיעים את GKE, צריך לקחת בחשבון היבטים טכניים שונים כדי להתאים לדרישות של האפליקציה והעסק. בנוסף להגדרת הרשת, האבטחה, האחסון והיבטים טכניים אחרים, אתם צריכים להעריך את העלות והביצועים כדי לעמוד בדרישות העסקיות. במקום להתייחס לעלות ולביצועים כאל ישויות נפרדות, צריך לשלב אותם משלבי התכנון הראשוניים של התשתית כדי להגדיר קשר מאוחד שקובע גם את המהימנות וגם את ההוצאות על הענן. עלות נמוכה ומהימנות גבוהה הן תכונות צפויות, אבל ככל שההיקף גדל, כך גדלה המורכבות של ניהול האיזון הזה.

כדי להשיג עלות נמוכה ויציבות של האפליקציה, אפשר להגדיר או לשנות את ההגדרות של התכונות הבאות של GKE:

  • ההגדרות של GKE
  • הגדרות של עומס עבודה
  • עלות בסיסית ושקיפות

שימוש ב-GKE Autopilot

בסביבות ארגז חול או פיתוח קטנות, בוחרים באפשרות Autopilot clusters. ב-Autopilot,‏ GKE מנהל את הצמתים באופן דינמי, ואתם מחויבים רק על קיבולת ה-Pod המבוקשת. כך אתם יכולים להימנע מחיובים על מכונות וירטואליות, על מערכת ההפעלה של הצמתים ועל תקורה של המערכת.

מידע נוסף זמין במאמר סקירה כללית על GKE Autopilot.

איך פועל שינוי הגודל האוטומטי

בקרי ההתאמה האוטומטית לעומס ב-GKE משנים את המשאבים באופן דינמי בהתאם לשינויים בבקשות התנועה.

הוספה והסרה של Pods על סמך מדדי ניצול

‫HorizontalPodAutoscaler‏ (HPA) מוסיף ומסיר Pods על סמך מדדי CPU או מדדים מותאמים אישית.

כדי להבין ולהגדיר התאמה אופקית של קבוצות Pod לעומס, אפשר לעיין במסמכי GKE הבאים:

מגדירים סף ניצול יעד (לדוגמה, 70% או 80%) כדי לשמור על מאגר שיכול להתמודד עם עליות פתאומיות בנפח התנועה בזמן שמתחילים פודים נוספים של רפליקות.

הרחבת ה-Pods על סמך מדדי ניצול

להשתמש ב-VerticalPodAutoscaler ‏ (VPA) כדי לקבוע באופן דינמי את הגודל של בקשות המעבד והזיכרון של קונטיינרים לעומסי עבודה שלא נעשה בהם שימוש בהתאמה אופקית של קבוצות Pod לעומס, או כשעומסי העבודה המקסימליים לא ידועים.

כדי להבין ולהגדיר את התכונה 'התאמה אנכית של קבוצות Pod לעומס', אפשר לעיין במאמרי העזרה הבאים של GKE:

כדי לתעד דפוסי תנועה מייצגים, מומלץ להשאיר את VPA במצב Off (המלצה בלבד) למשך 24 שעות לפחות (רצוי למשך שבוע) בסביבות שדומות לסביבות ייצור. כדי למנוע שינויים לא צפויים בגודל, צריך לציין גבולות מינימליים ומקסימליים ברורים באובייקט VerticalPodAutoscaler לפני שמפעילים את המצבים Initial או Auto.

אוטומציה של שינוי גודל התשתית באמצעות Cluster Autoscaler

כדי לשנות את גודל הצמתים הבסיסיים של המחשוב על סמך סימולציה פעילה של תזמון ולא על סמך עומסי מדדים, צריך להפעיל את Cluster Autoscaler במאגרי הצמתים של GKE Standard. צריך לציין פרמטרים מינימליים של צומת כדי לתמוך בקיבולת בסיסית בלילה.

תמיד מגדירים אובייקט PodDisruptionBudget ‏ (PDB) עבור מערכת ו-Pods של אפליקציות. ההגדרה הזו עוזרת לוודא שהכלי Cluster Autoscaler לא יגרום בטעות להפרעה בשירות כשמבצעים איחוד או הקטנה של מאגרי צמתים שלא נעשה בהם שימוש מלא.

כדי להבין את Cluster Autoscaler ולהגדיר אותו, אפשר לעיין במסמכי GKE הבאים:

פריסת מאגרי צמתים דינמיים באמצעות יצירה אוטומטית של מאגרי צמתים

אפשר להפעיל יצירה אוטומטית של מאגרי צמתים כדי ליצור באופן אוטומטי מאגרי צמתים מותאמים אישית של GKE, שהצורות, מספר ליבות ה-CPU או מגבלות הזיכרון שלהם מתאימים בדיוק לפרמטרים של תזמון של Pods בהמתנה. התכונה הזו מצמצמת את כמות המשאבים שנותרים בצמתים גדולים מדי.

כדי להבין את התכונה של יצירה אוטומטית של מאגר צמתים ולהגדיר אותה, אפשר לעיין במסמכי התיעוד הבאים של GKE:

רשימת משימות להתאמה אוטומטית לעומס

מאפייני התשתית

התאמה של חומרת האשכול, המיקום וכללי הרשת של הצמתים לסדרי העדיפויות של אופטימיזציה של העלויות.

בחירת סוגי המכונות המתאימים

בוחרים את סוגי המכונות המתאימים לאשכול על סמך המיקום של המשתמשים והמיקום של הנתונים שהאשכול צריך לגשת אליהם.

מידע נוסף זמין במאמר השוואה בין משפחות של מכונות ומשאבים.

פריסת עומסי עבודה (workloads) עמידים בכשלים במכונות וירטואליות במודל Spot

כדאי להשתמש ב-VM במודל Spot כדי להריץ עומסי עבודה באצווה, עומסי עבודה בלי שמירת מצב או עומסי עבודה עמידים בכשלים, בהנחה של עד 91% בהשוואה למכונות וירטואליות על פי דרישה.

מידע נוסף זמין במאמרי העזרה הבאים בנושא GKE:

מיפוי של משפחות מכונות יעילות והגדרות של מערכת ההפעלה

התאמה אישית של הגדרות המכונה של מאגר הצמתים באמצעות פרופילי מכונות חסכוניים (לדוגמה, ארכיטקטורות של מכונות וירטואליות מסוג E2).

מידע נוסף על שינוי הגודל של הצמתים, על הגדרת תזמונים של הפסקת השימוש ב-VM במודל Spot ועל הגדרת תצורות של ליבת מערכת ההפעלה זמין במאמר מידע על מאגרי צמתים.

בוחרים את האזור המתאים

אם זמן האחזור לא משפיע על המשתמשים, כדאי להריץ את עומסי העבודה של האשכול באזורים של Compute Engine עם עלויות תפעול נמוכות יותר.

מידע נוסף זמין במאמר בנושא שיטות מומלצות לבחירת אזורים ב-Compute Engine.

הרשמה להנחה תמורת התחייבות לשימוש

כדאי לרכוש הנחות תמורת התחייבות לשימוש (CUD) כדי לקבל הנחות משמעותיות (עד 70%) על משאבי מחשוב בסיסיים למשך שנה או שלוש שנים.

מידע נוסף זמין במאמר בנושא הנחות תמורת התחייבות לשימוש במשאבים.

כדאי לקחת בחשבון את עלויות הרשת

אשכולות GKE אזוריים ורב-אזוריים משפרים את מהימנות האפליקציה, אבל יכולים ליצור עלויות פנימיות של תעבורת נתונים יוצאת (egress) ברשת בין אזורים.

כדי לצמצם את עלויות הרשת ולשלוט בהן, מומלץ לשקול את האפשרויות הבאות:

  • העברות נתונים בין אזורים: למרות שקלאסטרים אזוריים מגדילים את הזמינות על ידי פיזור עומסי העבודה בין האזורים, יש עלויות שקשורות להעברת נתונים בין האזורים האלה.

מידע נוסף זמין במאמר בנושא כל המחירים של שירותי הרשת.

פריסת אשכולות של אזור יחיד בסביבות שאינן סביבות ייצור

בסביבות שאינן סביבות ייצור, כדי להימנע מחיובים על רשתות חוצות אזורים ולהפחית את התקורה של מכונות וירטואליות, כדאי לפרוס אשכולות חד-אזוריים במקום אשכולות אזוריים או רב-אזוריים.

מידע נוסף זמין במאמר מידע על אפשרויות ההגדרה של אשכולים.

אופטימיזציה של נתיבי פענוח DNS באשכול ותעבורת נתונים נכנסת (ingress)

כדי לבצע אופטימיזציה של פענוח DNS של אשכול ותעבורת נתונים נכנסת (ingress), אפשר לפרוס NodeLocal DNSCache וקבוצות של נקודות קצה ברשת (NEGs).

כשמריצים עומסי עבודה שדורשים הרבה פעולות DNS, ‏ NodeLocal DNSCache מריץ דמון DNS מקומי בכל צומת. ההגדרה הזו מונעת ממטען שאילתות גבוה לרוקן את CoreDNS, וכך לא צריך להרחיב את CoreDNS ומקטינים את העלויות הכוללות של GKE.

לגבי תעבורת נתונים נכנסת (ingress), איזון עומסים שמקורו בקונטיינר דרך קבוצות נקודות קצה ברשת (NEGs) מעביר את התעבורה ישירות לכתובות ה-IP של ה-Pod במקום לקבוצות של מכונות. הניתוב הישיר הזה מאפשר הפניה אוטומטית חלקה של תנועת נתונים במהלך פעולות שינוי גודל של Pod.

למידע נוסף:

הגדרת מכסות משאבים לכל מרחב שמות

כדי להגביל את השימוש במעבד ובזיכרון, וכדי למנוע ממפתחים לתזמן עומסי עבודה שלא עומדים בדרישות וגורמים לחיובים לא צפויים על שימוש במחשוב, מומלץ לפרוס אובייקטים רגילים של ResourceQuota ב-Kubernetes לכל מרחב שמות באשכולות מרובי-דיירים.

מידע נוסף זמין במאמר בנושא Namespaces במסמכי התיעוד של Kubernetes.

הטמעה של ביקורות ב-Policy Controller

פורסים את Policy Controller כדי לבצע ביקורת דינמית ולאכוף את התאימות של האשכול לתקנים ארגוניים. ‫Policy Controller משתמש בבקרת כניסה כדי לדחות משאבים שהוגדרו בצורה שגויה.

למידע נוסף, קראו את המאמרים הבאים:

חסימת מניפסטים שלא עומדים בדרישות בצינורות עיבוד נתונים של CI/CD

כדאי לאמת את העמידה במדיניות העלויות בשלב מוקדם יותר במחזור החיים של הפיתוח. כדי לבדוק ולחסום מניפסטים שלא עומדים בדרישות לפני שהם מגיעים לאשכול, אפשר לשלב סקריפטים של אימות (כמו ניתוח של kpt) בבדיקות של בקשות משיכה או לפני ביצוע קומיט.

מידע נוסף זמין במאמר בנושא אימות אפליקציות בהתאם למדיניות החברה בצינור CI.

רשימת משימות לבדיקת התשתית

אופטימיזציה של אפליקציות ועומסי עבודה

הגדרת עומסי העבודה כך שישתמשו במשאבים בצורה יעילה ויפחיתו את התקורה התפעולית.

ציון של בקשות ומגבלות זיכרון תואמות

לפני הפריסה, מציינים בקשות מדויקות של CPU וזיכרון עבור המאגר. לגבי CPU, צריך להגדיר בקשות כדי לעמוד ביעדים למדידת רמת השירות (SLO), אבל להשאיר את המגבלות ללא הגבלה. לגבי זיכרון, מוודאים שההקצאה המבוקשת תואמת למגבלת הזיכרון.

מידע נוסף זמין במאמר שינוי הגודל של משאבי CPU וזיכרון שמוקצים לקונטיינרים במסמכי התיעוד של Kubernetes.

האצת זמני ההפעלה של קונטיינרים

כדאי ליצור תמונות קונטיינר קטנות ככל האפשר כדי לקצר את זמן ההורדה של התמונות.

הגדרת PDBs

אפשר לציין אובייקט PodDisruptionBudget ‏ (PDB) בשביל העתקים של אפליקציות כדי להגביל שיבושים רצוניים ולהבטיח יציבות כש-GKE מצמצם את קנה המידה או כשמתרחשים שדרוגים של צמתים.

מידע נוסף זמין במאמר בנושא הגדרת תקציב הפרעות לאפליקציה.

הגדרת בדיקות תקינות (readiness probes) ובדיקות פעילות (liveness probes) משמעותיות

כדי לוודא ש-GKE מנתב תעבורה רק ל-Pods מוכנים ומפעיל מחדש מקרים שנכשלו, וכדי למנוע אובדן תעבורה במהלך שינוי גודל אוטומטי, צריך להגדיר בדיקות מוכנות ובדיקות פעילות לכל המאגדים.

מידע נוסף זמין במאמר הגדרת בדיקות של פעילות, מוכנות והפעלה.

הגדרת כיבוי מבוקר של אפליקציה

כדי להכין קונטיינרים לסיום תקין, צריך להאזין לאות SIGTERM, לסיים את הבקשות הפעילות לפני היציאה או להגדיר ווים של preStop.

מידע נוסף זמין במאמר בנושא סיום והשבתה מסודרת של מכונות וירטואליות שניתנות להפסקת פעולה.

הטמעה של ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

כדי לטפל בכשלים זמניים או בהפסקות פוטנציאליות של VM במודל Spot, כדאי להטמיע ניסיונות חוזרים עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff) ברמת האפליקציה או ברמת Service mesh.

מידע נוסף מופיע במאמר Retries (ניסיונות חוזרים) במסמכי Istio.

רשימת משימות לאופטימיזציה של אפליקציות ועומסי עבודה

עלות בסיסית ושקיפות

כדי לבצע אופטימיזציה של העלויות, קודם צריך לראות את ההוצאות ב-GKE ואת אופן ההקצאה שלהן. התובנות האלה עוזרות לכם לשייך עלויות לצוותים וליחידות העסקיות שנושאים בהן.

במסמכי GKE הבאים מוסבר איך לקבל תובנות מעמיקות לגבי החיוב ב-GKE, צריכת המשאבים ומדדי הבסיס.

הפעלת הקצאת עלויות ב-GKE

כדי לקבל תובנות לגבי בקשות למשאבי עומס עבודה (workload) והעלויות שמשויכות אליהן, צריך להפעיל את הקצאת העלויות ב-GKE. מאפייני הקצאת עלויות מאפשרים לקבץ עלויות לפי מרחבי שמות ותוויות Kubernetes של עומסי העבודה.

כדי לנתח את הנתונים בחיוב ב-Cloud, אפשר לייצא את הפרטים האלה ל-BigQuery. הניתוח הזה יעזור לכם לזהות אילו עומסי עבודה גורמים לעליות חדות בחיוב, לבצע החזרים כספיים ולבצע אופטימיזציה של בקשות משאבים.

מידע נוסף זמין במאמר קבלת תובנות חשובות לגבי ההוצאות על הקצאת משאבים ועלויות של אשכולות ב-GKE.

בדיקת נפחי ההעברה של יומנים ומדדים

הפעלת Cloud Logging ו-Cloud Monitoring באשכולות כרוכה בעלויות. הוספה של נפחים גדולים של יומנים ומדדים מותאמים אישית עלולה להוביל לחיובים לא צפויים. ביצוע ביקורת מרכזית על רמות היומן ומדדים מותאמים אישית שמועברים למערכת.

למידע נוסף על פתרון בעיות שקשורות לשימוש גבוה ב-API של רישום ביומן או לזמני קצובים לתפוגה של כתיבת יומן, אפשר לעיין במאמרים הבאים:

מעקב אחר תקינות שרת המדדים

חשוב לעקוב אחרי תקינות הפריסה של Metrics Server, כי בקרי ההתאמה האוטומטית המובנים של GKE מסתמכים עליו כדי לאחזר מדדים של CPU וזיכרון.

מידע נוסף זמין במאמר בנושא פתרון בעיות של התאמה אופקית של קבוצות Pod לעומס.

טיפוח תרבות של חיסכון בעלויות

לתת למפתחים גישה ללוחות בקרה של הוצאות בענן, וליצור הדרכה בנושא FinOps כדי להתאים את ההחלטות הארכיטקטוניות לתקציבי העלויות העסקיות.

מידע נוסף על תרבות של יעילות בעלויות בארגון זמין במאמר הפצת תרבות של חיסכון בעלויות.

רשימת משימות לבדיקה של נקודת ייחוס לעלות ושקיפות

המאמרים הבאים

מידע נוסף על העקרונות הארכיטקטוניים ועל התרבות הארגונית שנדרשים כדי להשיג יעילות בעלויות זמין במאמר שיטות מומלצות להרצת אפליקציות Kubernetes שעברו אופטימיזציה של עלויות ב-GKE.