שיטות מומלצות להרצה של עומסי עבודה באצווה ב-GKE

בדף הזה מוצגות שיטות מומלצות לבנייה ולאופטימיזציה של פלטפורמות לעיבוד באצווה באמצעות Google Kubernetes Engine‏ (GKE), כולל שיטות מומלצות בנושאים הבאים:

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

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

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

איך עומסי עבודה של אצווה פועלים

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

ניהול קבוצות בפלטפורמה

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

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

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

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

הכנת ארכיטקטורת פלטפורמת האצווה ב-GKE

סביבת GKE מורכבת מצמתים, שהם מכונות וירטואליות (VM) של Compute Engine, שמקובצות יחד ליצירת אשכול.

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

המלצה משאבים
בחירת מצב פעולה של GKE

ב-GKE יש את מצבי הפעולה הבאים:

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

השוואה כללית בין מצב אוטומטי למצב רגיל
בחירת סוג המכונה לצמתים

‫GKE תומך בסדרות הבאות של מכונות וירטואליות ב-Compute Engine:

  • אופטימיזציה של העלויות, כמו E2
  • מאוזן, כמו N2,‏ N2D או N1
  • אופטימיזציה להרחבת קנה מידה, כמו Tau T2D או Tau T2A
  • מותאמת לצריכת זיכרון גבוהה (memory-optimized), כמו M2 או M1
  • מותאמת לצריכת מעבד גבוהה (compute-optimized), כמו C2 או C2D
  • אופטימיזציה למאיץ, כמו A4 עם מעבדי NVIDIA B200

כל סדרת מכונות משויכת לפלטפורמת מעבד אחת או יותר, כמו מעבדי Arm ומעבדי x86 מבית Intel ו-AMD.

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

אפשר גם להשתמש במאיצי חומרה כמו יחידות עיבוד גרפי (GPU) ויחידות עיבוד טנסור (TPU) ב-GKE. כדאי לשקול שימוש בשיטת חלוקת זמן של GPU, שמאפשרת לכמה קונטיינרים לחלוק זמן באותו GPU פיזי. הגישה הזו שימושית לעומסי עבודה (workloads) של GPU עם תנודות ועם מאפיינים הומוגניים, שכוללים מספר נמוך של בקשות. ‫Multi-instance GPUs (כרטיסי GPU עם כמה מופעים) כדי לחלק כרטיסי GPU כך שמשאב GPU יחיד ישותף בין כמה קונטיינרים בו-זמנית.
הפעלת המידרוג האוטומטי באשכולות רגילים

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

מומלץ להגדיר את התוסף Cluster Autoscaler עם ההגדרה הבאה:

  • אפשר להשתמש בפרופיל optimize-utilization כדי להסיר צמתים שלא נמצאים בשימוש עד פי שלושה יותר מהר מאשר בפרופיל balanced. מידע נוסף על פרופילים של שינוי גודל אוטומטי
  • הגדרת מדיניות המיקום ל-ANY. הכלי GKE cluster autoscaler נותן עדיפות לניצול של הזמנות לא בשימוש ויוצר צמתים בכל אזור זמין באזורים. מידע נוסף זמין במאמר מדיניות בנושא מיקום.
  • הפעלת הקצאת משאבים אוטומטית של צמתים לניהול אוטומטי של התשתית ולהתאמת קנה המידה שלה. אחרי שיוצרים מאגר צמתים באמצעות הקצאת הרשאות אוטומטית, אפשר לשנות את הגודל של מאגר הצמתים באופן דינמי באמצעות Cluster Autoscaler. מידע נוסף על הקצאת משאבים אוטומטית של צמתים

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

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

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

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

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

ניהול מחזור החיים של המשרה

ב-Kubernetes, מריצים את עומסי העבודה (workload) בסט של Pods. ‫Pods הם קבוצות של קונטיינרים בודדים או מרובים, עם נפח אחסון משותף ומשאבי רשת. קבוצות ה-Pod מוגדרות על ידי מפרט Kubernetes.

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

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

המלצה משאבים
בחירת מצב השלמת העבודה מציינים את מצב ההשלמה כ-Indexed. ההגדרה הזו שימושית כשמקצים מחיצה של הנתונים לעיבוד על סמך האינדקס של ה-Pod. ל-Pods של Job משויך אינדקס השלמה. מחיקת עבודה מנקה את קבוצות ה-Pod שהיא יצרה. השעיה של Job מוחקת את ה-Pods הפעילים שלה עד שה-Job מופעל מחדש.
הגדרת משימות Cron לפעולות מתוזמנות קבועות אפשר להשתמש ב-CronJob ב-GKE כדי לבצע פעולות מתוזמנות באופן קבוע, כמו גיבויים, יצירת דוחות או אימון מתוזמן של מודלים של למידת מכונה.
ניהול כשלים בעבודה הגדרת מדיניות הכשל של Pod ב-Kubernetes ומגבלת הכשל של Pod backoff כדי לטפל בכשלים שניתן לנסות שוב ושלא ניתן לנסות שוב במשימה. ההגדרה הזו משפרת את צריכת המשאבים של האשכול על ידי מניעת ניסיונות חוזרים מיותרים של Pod ושל כשלים של Job בגלל שיבושים ב-Pod. לדוגמה, אפשר להגדיר הפסקה זמנית,‏ API-initiated eviction או taint-based eviction, שבהם מתבצעת הוצאה של Pods שלא מוגדרת להם טולרנטיות ל-NoExecute taint effect. איך מטפלים בכשלים של פודים שאפשר לנסות להפעיל מחדש ושאי אפשר לנסות להפעיל מחדש באמצעות מדיניות כשלים של פודים
ניהול כמה משרות כיחידה אחת אפשר להשתמש ב-JobSet API כדי לנהל כמה משימות כיחידה אחת, כדי לטפל בדפוסי עומס עבודה, כמו נהג אחד (או מתאם) וכמה עובדים (לדוגמה, MPIJob), תוך הגדרת ברירות מחדל של משימות שתואמות לדפוסים נפוצים על סמך תרחישי השימוש שלכם. לדוגמה, אפשר ליצור משימה עם אינדקס כברירת מחדל, ליצור שירות ללא ממשק משתמש (headless) כדי לקבל שמות דומיין שמוגדרים במלואם (FQDN) שניתן לחזות עבור Pods, ולהגדיר את מדיניות הכשל המשויכת של ה-Pod.
הארכת זמן הריצה של Pod שלא סובל הפעלות מחדש מגדירים את הערת ה-Kubernetes‏ cluster-autoscaler.kubernetes.io/safe-to-evict ל-false במפרט של ה-Pod. המידרוג האוטומטי באשכול מתחשב בכללי הפינוי שמוגדרים ב-Pods. ההגבלות האלה יכולות למנוע ממידרוג אוטומטי למחוק צומת אם הוא מכיל Pod עם ההערה cluster-autoscaler.kubernetes.io/safe-to-evict.

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

ניהול של ריבוי דיירים

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

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

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

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

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

בטבלה הבאה מפורטות ההמלצות העיקריות לניהול הגישה והאבטחה

המלצה משאבים
הגדרת איחוד זהויות של עומסי עבודה ל-GKE ‫GKE מאפשר לעומסי עבודה באשכול GKE להתחזות לחשבונות שירות לניהול זהויות והרשאות גישה (IAM) כדי לגשת ל Google Cloud שירותים. באמצעות איחוד זהויות של עומסי עבודה ל-GKE, עומסי עבודה יכולים לגשת בצורה מאובטחת לסודות שמאוחסנים מחוץ ל-GKE.

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

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

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

הוספה לתור ושיתוף הוגן

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

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

המלצה משאבים
שימוש ב-Kueue

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

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

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

מידע נוסף על Kueue זמין במאמר מושגים ב-Kueue.

אופטימיזציה של האחסון, הביצועים והיעילות מבחינת עלויות

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

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

המלצה משאבים
שימוש בדיסקים לאחסון מתמיד ב-Compute Engine

מומלץ להשתמש בהגדרות הבאות של דיסקים קשיחים קבועים ב-Compute Engine:
שימוש באחסון שמחובר לרשת

כדי להשיג ביצועים אופטימליים של אחסון, אפשר להשתמש באחסון ברשת (NAS) לצד Persistent Disk:

  • משתמשים ב-Filestore כדי לאפשר לכל צמתי העובדים ב-Pod לגשת לאותו מרחב שמות של אחסון ולהגדיל את הקיבולת.
  • משתמשים ב-Cloud Storage FUSE כדי לגשת ל-Cloud Storage ישירות מקונטיינר כטעינת POSIX מקומית.
הגדרה של Pub/Sub

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

מומלץ להשתמש בפתרונות האחסון הבאים:

  • כדי להשתמש באחסון אובייקטים מנוהל, צריך להשתמש ב-Cloud Storage.
  • לניהול אחסון קבצים ברשת, משתמשים ב-Filestore.
  • לעומסי עבודה שדורשים סמנטיקה של מערכת קבצים, משתמשים במנהל התקן ה-CSI של Cloud Storage FUSE. מנהל ההתקן הזה מאפשר לאפליקציות של Kubernetes לטעון קטגוריות של Cloud Storage כמערכות קבצים מקומיות.
ציון פרמטרים של התאמה לעומס העבודה

מומלץ להשתמש בהגדרות הבאות:

  • התאמה אישית של הגדרות המערכת של הצומת לעומס העבודה. לדוגמה, מגדירים את הערכים המינימליים, ערכי ברירת המחדל והערכים המקסימליים של מאגר הקבלה של שקע TCP. משתמשים ב-node system configuration.
  • הפעלת בדיקת סטטוס פנוי באמצעות פרופילים ברשת. יכול להיות שיהיה שיפור בעומסי עבודה מסוימים שרגישים לזמן האחזור ברשת. שימוש בפרופילים של רשתות.
  • כדי להגדיל את רוחב הפס של הרשת בצמתים של GKE, אפשר להפעיל את Google Virtual NIC ‏(gVNIC), ממשק רשת וירטואלי שנועד במיוחד ל-Compute Engine ומומלץ לאפליקציות עם ביצועים גבוהים.
  • מציינים את מספר השרשורים לכל ליבה כדי להשבית את הריבוי המשולב של שרשורים.
אופטימיזציה של העומסים מבחינת רשת וזמן אחזור ‫GKE תומך במדיניות מיקום קומפקטי למאגרי צמתים, שמציינת שהצמתים האלה (ולכן עומסי העבודה שפועלים בהם) צריכים להיות ממוקמים בקרבה פיזית זה לזה באזור. האפשרות הזו שימושית במיוחד לעומסי עבודה עם צימוד הדוק וביצועים גבוהים, שבהם זמן טעינה קצר בין תהליכים שונים שמרכיבים את עומס העבודה הוא בעל חשיבות רבה. מידע נוסף זמין במאמר בנושא מיקום קומפקטי.
שימוש ב-VMs במודל Spot

מכונות Spot VM הן מכונות וירטואליות (VM) של Compute Engine שמחירן נמוך ממכונות וירטואליות רגילות של Compute Engine, ואין עליהן הבטחה לזמינות.

מומלץ להשתמש בפתרונות הבאים:

  • הגדרת מאגרי צמתים של מכונות Spot וירטואליות עם התאמה אוטומטית לעומס (autoscaling) בשילוב עם location_policy= "ANY" . המדיניות הזו מפחיתה את הסיכון להפסקת השימוש במכונות וירטואליות מסוג Spot. השילוב הזה שימושי במיוחד לעומסי עבודה שיכולים להמשיך להתקיים גם לאחר הפסקה זמנית של צמתי עובדים בודדים, כמו חישובים מקבילים.
  • אם עומס העבודה שלכם דורש כמות צפויה של משאבים, תוכלו לשלב בין Google Cloudהזמנות לבין הנחות תמורת התחייבות לשימוש כדי לחסוך משמעותית בעלויות. יוצרים מאגר צמתים עם גודל שמוגדר כמספר המקרים השמורים, ומתעדפים את ההגעה למצב של שימוש מלא במאגר הצמתים הזה כדי להפיק את המרב מהשימוש.
שימוש בהזרמת תמונות

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

מעקב אחרי אשכולות

‫GKE משולב עם כלי רישום וניטור שעוזרים לכם לעקוב אחרי האמינות והיעילות של האשכול. בטבלה הבאה מפורטות ההמלצות העיקריות להפעלה ולשימוש בכלי התצפית של GKE:

המלצה משאבים
שימוש ב-Prometheus

‫GKE משולב עם Google Cloud Observability. התאמה אישית של המדדים שרוצים ש-GKE ישלח ל-Cloud Logging ול-Cloud Monitoring

השירות המנוהל של Google Cloud ל-Prometheus מופעל כברירת מחדל באשכולות GKE. מומלץ להשתמש באוסף מנוהל כדי להימנע מהמורכבות של הגדרת שרתי Prometheus ותחזוקתם.

מידע נוסף זמין במאמר בנושא שירות מנוהל ל-Prometheus.
שימוש בלוחות בקרה של Cloud Monitoring

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

מידע נוסף זמין במאמר מעקב אחרי אשכולות GKE.
צפייה בעומסי העבודה של AI/ML במסוף Google Cloud

במסוף Google Cloud , עוברים אל Kubernetes Engine > AI/ML > Jobs כדי לראות את JobSets,‏ Jobs,‏ PyTorchJobs ו-RayJobs. אתם יכולים לגשת לפרטים כמו יומנים, אירועים והדמיות במרכזי בקרה של יכולת התבוננות.

כדי לראות משימות צאצא בתוך JobSet או עובדים ששייכים ל-RayJob, בממשק המשתמש, עוברים למשאב האב.

הצגת משימות במסוף Google Cloud

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