שיטות מומלצות לשימוש ב-ComputeClasses

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

עיצוב ComputeClass

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

עיצוב כל ComputeClass על סמך אסטרטגיה

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

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

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

שיפור הביצועים של התזמון וכוונון מדויק של הצמתים

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

האסטרטגיה ההיברידית כוללת את סוגי מאגרי הצמתים הבאים לפי סדר העדיפות ב-ComputeClass:

  1. מאגרי צמתים שנוצרו באופן ידני: במאגרי הצמתים האלה יש את המפרטים המדויקים שאתם רוצים שרוב ה-Pods יפעלו לפיהם. אפשר להגדיר את מאגרי הצמתים האלה עם תוויות צמתים ספציפיות, צבעי צמתים, הזמנות של קיבולת או הגדרות מיוחדות כמו פרמטרים של kubelet. יוצרים את מאגרי הצמתים האלה עם מספר הצמתים שנדרש ל-Pods לפי ההערכה. ב-ComputeClass, מקצים את העדיפות הכי גבוהה למאגרי הצמתים האלה.
  2. מאגרי צמתים שנוצרו אוטומטית: כאמצעי גיבוי, אפשר להשתמש ב-ComputeClass כדי לבקש מאגרי צמתים נוספים שעדיין מותאמים לאובייקטים מסוג Pod. הקצאת עדיפות נמוכה יותר למאגרי הצמתים שנוצרו אוטומטית מאשר למאגרי הצמתים שנוצרו באופן ידני.

בדוגמה הבאה של ComputeClass נעשה שימוש באסטרטגיה היברידית:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: hybrid-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - nodepools: ['manual-pool1']
  - machineFamily: n4
    minCores: 16
    minMemoryGb: 64
  whenUnsatisfiable: DoNotScaleUp

כשפורסים עומס עבודה שמשתמש ב-ComputeClass הזה, ‏ GKE ממקם את ה-Pods בצמתים זמינים ב-manual-pool1. ‫GKE יוצר מאגרי צמתים חדשים רק כשאין קיבולת זמינה במאגר הצמתים שנוצר באופן ידני. החביון של התזמון יורד ככל שמספר הצמתים הקיימים במאגר הצמתים שנוצר באופן ידני עולה, כי GKE לא צריך ליצור צמתים חדשים בתדירות גבוהה.

הגדרה מפורשת של התנהגות ההתאמה לעומס במקרה של כשל

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

  • עומסי עבודה לשימוש כללי: אם עומסי העבודה יכולים לפעול בכל סדרת מכונות, צריך לציין ערך של ScaleUpAnyway. אם צמתים שתואמים לכלל עדיפות ב-ComputeClass לא זמינים, GKE מרחיב את הצמתים שמשתמשים בסדרת המכונות שמוגדרת כברירת מחדל באשכול.
  • עומסי עבודה שזקוקים לחומרה ייעודית: כדי להשתמש במאיצים או בעומסי עבודה של מחשוב בעל ביצועים גבוהים (HPC) שמסתמכים על חומרה ספציפית, כמו מעבדים גרפיים או סדרות מסוימות של מכונות Compute Engine, צריך לציין ערך של DoNotScaleUp. אם הצמתים שתואמים לכלל העדיפות ב-ComputeClass לא זמינים, ה-Pods נשארים במצב Pending עד שהמשאבים יהיו זמינים. הגישה הזו מונעת הפעלה של Pods בחומרה לא תואמת.

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

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

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

הגדרת ComputeClasses כברירת מחדל למרחבי שמות כדי להפריד בין דיירים

בנוסף ל-ComputeClass שמוגדר כברירת מחדל ברמת האשכול, אפשר להגדיר ComputeClass כברירת מחדל למרחבי שמות ספציפיים. אם יש לכם סביבות מרובות דיירים או שאתם רוצים להפריד בין עומסי עבודה שפועלים על חומרה ייעודית, אתם צריכים להגדיר ComputeClasses כברירת מחדל למרחבי השמות האלה. כדי למנוע הפעלה של Pods של המערכת בחומרה ייעודית כמו צמתי GPU, מוסיפים ComputeClass לשימוש כללי כ-ComputeClass ברירת המחדל למרחבי שמות של המערכת.

הרצת עומסי עבודה עם אינטראקציה נמוכה במצב אוטומטי

אם יש לכם עומסי עבודה שלא דורשים אינטראקציה או ניהול ידניים, אתם יכולים להריץ אותם במצב אוטומטי באמצעות ComputeClasses. אפשר להפעיל את מצב אוטומטי בכל ComputeClass, גם אם יש לכם אשכול Standard. ‫GKE מריץ את עומסי העבודה שבוחרים ComputeClass של Autopilot בצמתים מנוהלים באופן מלא שמיישמים את תכונות האבטחה, ההתאמה לעומס והחיוב של GKE Autopilot. מידע נוסף זמין במאמר מידע על עומסי עבודה במצב אוטומטי ב-GKE Standard.

עומסי עבודה עם שמירת מצב

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

השבתת העברה פעילה

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

שיפור המהימנות של התזמון באמצעות StorageClasses

אפשר להשתמש ב-StorageClasses כדי לשפר את מהימנות התזמון של עומסי עבודה עם שמירת מצב בדרכים הבאות:

  • יצירת אמצעי אחסון רק אחרי יצירת ה-Pod: אם משתמשים בהקצאה דינמית של אמצעי אחסון, צריך לציין ערך של WaitForFirstConsumer בשדה volumeBindingMode ב-StorageClass. מצב האיגוד הזה של נפח האחסון מונע את היצירה של PersistentVolume עד ש-GKE יוצר Pod שמשתמש ב-PersistentVolumeClaim התואם. ‫GKE מקצה את PersistentVolume באותו אזור כמו הצומת שמריץ את ה-Pod.
  • שימוש ב-StorageClasses שמודעים לטופולוגיה: אם ComputeClass משתרע על כמה דורות של סדרת מכונות (לדוגמה, C4 ו-C3), צריך להשתמש ב-StorageClass שמופעל בו בחירה אוטומטית של סוג הדיסק ושמבצע תזמון רק בצמתים שתומכים בסוגי הדיסקים שצוינו. אפשר להשתמש ב-StorageClass המובנה dynamic-rwo או ב-StorageClass בהתאמה אישית. עומסי העבודה עם שמירת מצב יכולים לפעול בכמה דורות של מכונות וירטואליות ב-Compute Engine, כי הכלי לשינוי גודל האשכול בוחר באופן דינמי סוג דיסק תואם.

תכנון התשתית כך שתהיה גמישה, יעילה וזמינה לקיבולת מחשוב

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

בקשה של סדרת מכונות במקום סוגי מכונות

אפשר לבקש סדרת מכונות של Compute Engine או סוגים ספציפיים של מכונות בכללי העדיפות של ComputeClass. אלא אם יש לכם תלות מחמירה בסוג מכונה ספציפי, כדאי לבחור סדרת מכונות באמצעות השדה machineFamily. במהלך פעולת שינוי גודל, GKE יכול ליצור צמתים שמשתמשים בכל סוג מכונה מתאים בסדרת המכונות הזו, מה שמגדיל את הסיכוי שה-Pods יפעלו בהגדרת הצומת המועדפת ביותר.

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

אם עומסי העבודה שלכם מסתמכים על חומרה מבוקשת, כמו TPU או GPU עם ביצועים גבוהים, כדאי ליצור הזמנות קיבולת ב-Compute Engine עבור החומרה ולהשתמש בהזמנות האלה ב-ComputeClasses. הזמנות של קיבולת משפרות את הסיכוי שהחומרה תהיה זמינה באזור או בתחום שלכם, וכך תוכלו להגדיל את הגמישות, היעילות והזמינות של קיבולת המחשוב. כדי להשתמש בהזמנה ב-ComputeClass בלי להשפיע על התנהגות הגיבוי, משתמשים בהזמנה עם זיקה ל-Specific או ל-AnyThenFail. אם אתם משתמשים בהעדפה AnyBestEffort או Automatic ואין קיבולת שמורה זמינה, יכול להיות שמערכת Compute Engine תעקוף את כללי העדיפות של ComputeClass ותחזור לחומרה לפי דרישה. מידע נוסף מופיע במאמר בנושא שימוש במשאבים שמורים של תחום מוגדר.

לא להשתמש בהזמנות חדשות למשך שעה לפחות

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

אבטחה

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

הגבלת הגישה ל-API להגדרות של ComputeClass

עומסי עבודה יכולים להשתמש ב-ComputeClasses כדי ליצור צמתים שמריצים חומרה ייעודית, כולל מעבדי GPU ו-TPU. הגבלת הגישה ליצירה, לשינוי ולמחיקה של ComputeClasses לאותם גורמים ראשיים שיכולים ליצור, לשנות ולמחוק צמתים באשכולות. כדי לשלוט בגישה ל-ComputeClasses, משתמשים במדיניות RBAC.

הגבלת הזמינות של ComputeClass לפי מרחב שמות

לקוחות GKE מפרידים לעיתים קרובות בין צוותים שונים או בין סוגים שונים של עומסי עבודה באמצעות מרחב שמות של Kubernetes. ‫ComputeClasses הם משאבים בהיקף אשכול, כלומר כל עומס עבודה בכל מרחב שמות יכול לבחור כל ComputeClass כברירת מחדל. כדי למנוע שימוש לרעה מכוון או לא מכוון, כדאי להשתמש ב-ValidatingAdmissionPolicies כדי לשלוט בקבוצת ה-ComputeClasses שעומדות לרשות עומסי העבודה בכל מרחב שמות. לדוגמה, יכול להיות שתרצו למנוע מ-Pods במרחב השמות של קצה קדמי באינטרנט לבחור ComputeClasses שיוצרים מאיצים. מוודאים שהבדיקה של ValidatingAdmissionPolicies בודקת את ההגדרות הנפוצות הבאות:

  • בודקים את כל שדות הבחירה: עומס עבודה יכול לבחור ComputeClass באמצעות השדות nodeSelector,‏ nodeAffinity או tolerations במפרט של ה-Pod. כדי להימנע מבחירה לא מכוונת של ComputeClass, צריך לבדוק את כל השדות האלה בביטויים של ValidatingAdmissionPolicy.
  • בודקים אם יש עקיפות של טולרנטיות של תווים כלליים: חוסמים באופן מפורש טולרנטיות של תווים כלליים או מאמתים אותן (לדוגמה, את הטולרנטיות operator: Exists ללא מפתח). בוררי התווים הכלליים האלה יכולים לכלול את רוב ההכתמות של הצמתים, כולל הכתמות של ComputeClass.
  • בודקים את כל בקרי עומסי העבודה: מגדירים את matchConstraints של המדיניות כך שיכסה את כל המשאבים של בקרי עומסי העבודה (כמו Deployment, StatefulSet, DaemonSet, Job ו-CronJob). לא מצמצמים את היקף הבדיקות רק למשאבי Pod.

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

אמינות

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

איך מונעים שימוש בבוררי צמתים סותרים

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

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

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

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

בדיקת עדכונים של ComputeClass CRD לפני שדרוגי אשכולות

‫GKE מעדכן באופן קבוע את ComputeClass CustomResourceDefinition (CRD) כדי להוסיף שדות, לשנות את אופן הפעולה של השדות ולפתור בעיות. בדרך כלל, תוספות ושינויים בשדות נכנסים לתוקף בגרסאות ספציפיות של GKE. לפני שמשדרגים את אשכולות הייצור לגרסאות משניות חדשות או לגרסאות תיקון, כדאי לבדוק אם שינויים ב-CRD גורמים לבעיות בעומסי העבודה. לשם כך, אפשר להיעזר בהנחיות הבאות:

שימוש ב-PodDisruptionBudgets כדי לשפר את זמינות עומס העבודה

פעולות של ComputeClass שגורמות להוצאת Pod, כמו העברה פעילה, מתבצעות בהתאם לכל PodDisruptionBudgets שהוגדר. לדוגמה, אפשר להגדיר פריסת הסקה עם PodDisruptionBudget שדורש זמינות של יותר מ-70% מה-Pods. במהלך העברה פעילה, אם פינוי של Pod חורג מהתקציב הזה, GKE לא מפנה את ה-Pod. מציינים את התקציבים להפרעות ב-Pod לעומסי עבודה כמו אלה:

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

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

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

אם יש לכם עומסי עבודה שבהם כל Pod חייב לפעול עד הסוף לפני שהוא מסתיים, אתם צריכים להוסיף את ההערה cluster-autoscaler.kubernetes.io/safe-to-evict: "false" למפרט של ה-Pod. ההערה הזו מונעת מ-GKE להוציא Pods במהלך פעולות של שינוי גודל אוטומטי. אפשר להשתמש בהערה הזו כדי להגן על פודים שלא יכולים לסבול שיבושים, כמו עומסי עבודה של מצב עם מופע יחיד ועבודות אצווה (batch) שפועלות לאורך זמן.

סיכום השיטות המומלצות

במסמך הזה מפורטות השיטות המומלצות הבאות לשימוש ב-ComputeClasses:

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