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

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

עיצוב ComputeClass

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

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

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

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

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

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

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

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

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

בדוגמה הבאה של 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 לא צריך ליצור צמתים חדשים בתדירות גבוהה.

הגדרה מפורשת של התנהגות ההתאמה לעומס (autoscaling) כמוצא אחרון

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • יצירת אמצעי אחסון רק אחרי יצירת Pod: אם אתם משתמשים בהקצאת אמצעי אחסון דינמית, ציינו את הערך WaitForFirstConsumer בשדה volumeBindingMode ב-StorageClass. מצב הקישור הזה של אמצעי האחסון מונע את היצירה של PersistentVolume עד ש-GKE יוצר Pod שמשתמש ב-PersistentVolumeClaim התואם. ‫GKE מקצה את PersistentVolume באותו אזור שבו נמצא הצומת שמריץ את ה-Pod.
  • שימוש ב-StorageClasses עם מודעות לטופולוגיה: אם ה-ComputeClass שלכם כולל כמה דורות של סדרות מכונות, השתמשו ב-StorageClass שמופעלת בו בחירה אוטומטית של סוג הדיסק (parameters.type: dynamic) ומתזמן רק בצמתים שתומכים בסוגי הדיסקים שציינתם. לדוגמה, אם יש מגבלות קיבולת באזור, ComputeClass יכול לעבור מסדרות שמשתמשות רק ב-Hyperdisk, כמו C4,‏ C4D או N4, לסדרות שמשתמשות ב-Persistent Disk, כמו N2 או N2D. אפשר להשתמש ב-dynamic-rwo StorageClass המובנה או ב-StorageClass בהתאמה אישית. כך, עומסי העבודה עם שמירת המצב יכולים לעבור למצב של מעבר לגיבוי בעת כשל (failover) בין כמה דורות של מכונות Compute Engine, כי המנגנון להתאמה דינמית של מספר המכונות באשכול בוחר באופן דינמי סוג דיסק תואם (hyperdisk-balanced או pd-balanced) לכל צומת חלופי שמוקצה.

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

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

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

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

שימוש במקומות שמורים לקיבולת לחומרה מבוקשת

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

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

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

אבטחה

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

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

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

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

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

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

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

אמינות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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