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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניהול של Multi-tenancy

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

אנחנו ממליצים להשתמש בהגדרות הבאות של Persistent Disks ב-Compute Engine:
שימוש באחסון ברשת (NAS)

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

  • כדי לאפשר לכל צמתי העובדים ב-Pod לגשת לאותו מרחב שמות של אחסון ולהגדיל את הקיבולת, צריך להשתמש ב-Filestore.
  • משתמשים ב-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‏ (gVNIC), ממשק רשת וירטואלי שנועד במיוחד ל-Compute Engine ומומלץ לאפליקציות עם ביצועים גבוהים.
  • מציינים את מספר השרשורים לכל ליבה כדי להשבית את ריבוי הליכי המשנה בו-זמנית.
אופטימיזציה של זמן האחזור והרשת של עומסי העבודה ‫GKE תומך במדיניות מיקום קומפקטי למאגרי צמתים, שמציינת שהצמתים האלה (ולכן עומסי העבודה שפועלים בהם) צריכים להיות ממוקמים בקרבה פיזית זה לזה בתוך אזור. האפשרות הזו שימושית במיוחד לעומסי עבודה עם צימוד חזק וביצועים גבוהים, שבהם זמן טעינה קצר בין תהליכים שונים שמרכיבים את עומס העבודה הוא בעל חשיבות רבה. מידע נוסף מופיע במאמר בנושא מיקום מודעות קומפקטי.
שימוש ב-VM במודל Spot

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

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

  • מגדירים מאגרי צמתים של מכונות VM מסוג Spot עם התאמה אוטומטית לעומס (autoscaling) בשילוב עם location_policy= "ANY" . המדיניות הזו מפחיתה את הסיכון להפסקה זמנית של VM במודל 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

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