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

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

עיצוב ComputeClass

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

תכנון כל ComputeClass על סמך אסטרטגיה

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

שיפור הזמינות והפחתת העלויות התפעוליות

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

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

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

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

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

בדוגמה הבאה של 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 מגדיל את מספר הצמתים שמשתמשים בסדרת המכונות שמוגדרת כברירת מחדל באשכול.
  • עומסי עבודה שזקוקים לחומרה ייעודית: לעומסי עבודה של האצת ביצועים או מחשוב בעל ביצועים גבוהים שמסתמכים על חומרה ספציפית, כמו מעבדי GPU או סדרות מסוימות של מכונות Compute Engine, צריך לציין ערך של DoNotScaleUp. אם הצמתים שתואמים לכלל העדיפות ב-ComputeClass לא זמינים, ה-Pods נשארים במצב Pending עד שהמשאבים יהיו זמינים. הגישה הזו מונעת הפעלה של Pods בחומרה לא תואמת.

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

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

אם לרוב עומסי העבודה שלכם יש את אותן דרישות חומרה, כדאי להגדיר ComputeClass כברירת מחדל עבור האשכול. ‫GKE מחיל את ComputeClass שמוגדר כברירת מחדל על כל עומסי העבודה שלא נבחר עבורם ComputeClass באופן מפורש. הגדרת ComputeClass כברירת מחדל מאפשרת למפעילים של אפליקציות לא לשנות את בוררי הצמתים או לבקש באופן ידני מאגרי צמתים וציוד ספציפיים בפודים נפרדים. אם מגדירים ComputeClass כברירת מחדל ברמת האשכול, לא מוסיפים תוויות צמתים וכתמי צבע ל-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 משפיעים על המיקום של ה-Pods ב-GKE, ובמצב Autopilot או עם יצירה אוטומטית של מאגרי צמתים, עשויים להפעיל את היצירה של מאגרי צמתים חדשים באשכול. אם יש לכם Pods שבוחרים ComputeClass ומשתמשים בבוררי צמתים כדי לבקש צמתים שמתנגשים עם ההגדרה של ComputeClass, יכול להיות ש-GKE לא יתזמן את ה-Pods בכלל.

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

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

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

בדיקת עדכונים של 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 במהלך פעולות של שינוי גודל אוטומטי. אפשר להשתמש בהערה הזו כדי להגן על Pods שלא יכולים לסבול שיבושים, כמו עומסי עבודה של מצב עם מופע יחיד ועבודות אצווה (batch Jobs) שפועלות לזמן רב.

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

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

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