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

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

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

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

סקירה כללית

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

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

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

אפשר גם לגלות שיטות מומלצות לאופטימיזציה של עלויות וליישם אותן באמצעות Compute Advisor (גרסת Preview). מידע נוסף מופיע במאמר בנושא שימוש ב-Compute Advisor.

שימוש ב-GKE Autopilot

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

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

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

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

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

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

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

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

הרחבת ה-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 או מגבלות הזיכרון שלהם מתאימים בדיוק לפרמטרים של תזמון של פודים בהמתנה. התכונה הזו מצמצמת את כמות המשאבים שנותרים בצמתים גדולים מדי.

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

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

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

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

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

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

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

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

כדאי להשתמש במכונות 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.

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

למידע נוסף:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת PDBs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש ב-Compute Advisor

‫Compute Advisor הוא ממשק מבוסס-AI ב-Google Cloud Console, שמבוסס על Gemini, ועוזר לכם לתכנן ארכיטקטורות עמידות וחסכוניות ל-GKE.

הכלי Compute Advisor מספק הנחיות לגבי זמינות של מכונות וירטואליות (VM) עם הפעלה גמישה ומכונות וירטואליות מסוג Spot כמעט בזמן אמת, תוך אימות המדיניות והמכסות של משאבי הארגון לפני הפריסה. ‫Compute Advisor לא מספק הנחיות לגבי זמינות של עומסי עבודה שדורשים משאבים על פי דרישה.

כדי לגשת ל-Gemini במסוף Google Cloud :

  1. במסוף Google Cloud , נכנסים לדף Overview.

    לסקירה הכללית

  2. בקטע תכנון התשתית באמצעות Compute Advisor, שולחים הנחיה. ‫Gemini מתחיל ליצור תשובה.

  3. כדי ליצור המלצות לגבי ארכיטקטורה, מריצים אחת מההנחיות לדוגמה הבאות ב-Compute Advisor. כשלוחצים על הלחצנים Run prompt in Compute Advisor, יכול להיות שיחלפו יותר מ-15 שניות עד שהמסוף Google Cloud ייטען:

  • התאמה אוטומטית לעומס (autoscaling) וסידור בקונטיינרים (bin packing):

    תרחיש שימוש: כדי למקסם את סידור בקונטיינרים (bin packing) ולמזער את התקורה של מעבד (CPU) במצב בלי פעילות, משתמשים בפרומפט הזה כדי להגדיר אסטרטגיה להתאמה אוטומטית לעומס (automatic scaling) של אשכולות GKE ומאגרי צמתים.

      Configure a GKE cluster to use autoscaler and node pool strategy
  to maximize bin packing and minimize idle CPU overhead.

    הפעלת פרומפט ב-Compute Advisor

  • ניהול ריבוי דיירים:

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

      Draft a ResourceQuota policy for a multi-tenant GKE
  cluster to keep development namespaces within budget bounds.

    הפעלת פרומפט ב-Compute Advisor

  • אופטימיזציה של עומסי עבודה:

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

      Recommend whether to use GKE Autopilot or Standard mode for a batch processing workload with highly variable resource demands.

    הפעלת פרומפט ב-Compute Advisor

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

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