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

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

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

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

סקירה כללית

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

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

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

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

שימוש ב-GKE Autopilot

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

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

הבנת אופן הפעולה של התאמה אוטומטית לעומס

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

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

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

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

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

שינוי הגודל של ה-Pods על סמך מדדי הניצול

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פריסת עומסי עבודה עמידים בכשלים ב-VM במודל Spot

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

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

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

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

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

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

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

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

הרשמה ל-CUD

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

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

התחשבות בעלויות של רשתות

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

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

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

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

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

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

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

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

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

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

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

למידע נוסף:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת PDBs

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

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

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

כדי לוודא ש-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

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

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

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

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

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

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

שימוש ב-Compute Advisor

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

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

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

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

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

  2. בקטע Design your infrastructure with Compute Advisor, שולחים הנחיה. ‫Gemini מתחיל ליצור תשובה.

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

  • התאמה אוטומטית לעומס (autoscaling) ואריזה אופטימלית (bin packing):

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

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

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

  • ניהול ריבוי דיירים (multitenancy):

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

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

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

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

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

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

    הפעלת הנחיה ב-Compute Advisor

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

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