בדף הזה מוצגות שיטות מומלצות לבנייה ולאופטימיזציה של פלטפורמות לעיבוד באצווה באמצעות Google Kubernetes Engine (GKE), כולל שיטות מומלצות בנושאים הבאים:
- ארכיטקטורה
- ניהול משרות
- ריבוי דיירים
- אבטחה
- הוספה לתור
- אחס��ן
- ביצועים
- עלות-תועלת
- מעקב
GKE מספק מסגרת עוצמתית לניהול עומסי עבודה (workload) של אצווה, כמו עיבוד נתונים, אימון מודלים של למידת מכונה, הפעלת סימולציות מדעיות ועומסי עבודה אחרים של מחשוב עתיר ביצועים.
השיטות המומלצות האלה מיועדות לאדמינים של פלטפורמות, למומחי Cloud Architect ולאנשי מקצוע בתחום התפעול שמעוניינים לפרוס עומסי עבודה באצווה ב-GKE. בארכיטקטורת ההפניה: פלטפורמה לעיבוד באצווה ב-GKE מוצגות רבות מהשיטות המומלצות ��מוסברות במדריך הזה, ואפשר לפרוס אותה בפרויקט Google Cloud שלכם.
סקירה מרוכזת של כל השיטות המומלצות ל-GKE זמינה במאמר שיטות מומלצות ל-GKE.איך עומסי עבודה של אצווה פועלים
עומס עבודה של אצווה הוא קבוצה של משימות שפועלות עד להשלמה ללא התערבות של המשתמש. כדי להגדיר משימות, משתמשים במשאב Jobs של Kubernetes. פלטפורמת אצווה מקבלת את המשימות ומכניסה אותן לתור לפי סדר קבלתן. התור בפלטפורמת העיבוד באצווה כולל לוגיקה של עיבוד, כמו עדיפות, מכסה ומשאבים שניתנים להקצאה. באמצעות תור והתאמה אישית של הפרמטרים של עיבוד אצווה, Kubernetes מאפשרת לכם לבצע אופטימיזציה של השימוש במשאבים הזמינים, לצמצם את זמן ההמתנה של משימות מתוזמנות ולמקסם את החיסכון בעלויות. בתרשים הבא מוצגים רכיבי GKE שיכולים להיות חלק מפלטפורמת אצווה.
ניהול קבוצות בפלטפורמה
באופן מסורתי, לפלטפורמות של עיבוד באצווה יש שני פרופילים עיקריים של משתמשים: מפתחים ואדמינים של הפלטפורמה:
- מפתח שולח משימה (Job) ומציין את התוכנית, את הנתונים לעיבוד ואת הדרישות של המשימה. לאחר מכן, המפתח מקבל אישור על שליחת המשימה ומזהה ייחודי. כשהעבודה תסתיים, המפתח יקבל הודעה עם כל הפלט או התוצאות של העבודה.
- אדמין של פלטפורמה מנהל ומספק למפתחים פלטפורמה יעילה ואמינה לעיבוד אצווה.
פלטפורמה לעיבוד אצווה צריכה לעמוד בדרישות הבאות:
- המשאבים של הפלטפורמה מוקצים בצורה נכונה כדי להבטיח שהעבודות יפעלו עם התערבות מינימלית של המשתמשים, אם בכלל.
- המשאבים בפלטפורמה מוגדרים בהתאם לשיטות המומלצות של הארגון בנושא אבטחה ויכולת צפייה.
- המשאבים של הפלטפורמה מנוצלים בצורה יעילה ככל האפשר. במקרה של תחרות על משאבים, העבודה החשובה ביותר מתבצעת קודם.
הכנת ארכיטקטורת פלטפורמת ה-Batch ב-GKE
סביבת GKE מורכבת מצמתים, שהם מכונות וירטואליות (VM) של Compute Engine, שמקובצות יחד ליצירת אשכול.
בטבלה הבאה מפורטות ההמלצות העיקריות לתכנון ולעיצו�� של ארכיטקטורת פלטפורמת אצווה:
| המלצה | משאבים |
|---|---|
| בחירת מצב פעולה של GKE |
אלה מצבי הפעולה שזמינים ב-GKE:
אפשר לעיין בהשוואה ברמה גבוהה בין מצב אוטומטי למצב רגיל. |
| בחירת סוג המכונה לצמתים |
GKE תומך בסדרות הבאות של מכונות וירטואליות ב-Compute Engine:
כל סדרת מכונות משויכת לפלטפורמת מעבד אחת או יותר, כמו מעבדי Arm ומעבדי x86 של Intel ו-AMD. |
| שימוש במאיצי חומרה לצמתים |
אפשר גם להשתמש במאיצי חומרה כמו יחידות עיבוד גרפי (GPU) ויחידות עיבוד טנסור (TPU) ב-GKE. כדאי לשקול שימוש בשיטת חלוקת זמן של GPU, שמאפשרת לכמה קונטיינרים לחלוק זמן באותו GPU פיזי. הגישה הזו שימושית לעומסי עבודה (workloads) של GPU הומוגניים עם יכולת התפרצות (burstable) ומספר נמוך של בקשות. Multi-instance GPUs (כרטיסי GPU עם כמה מופעים) כדי לחלק כרטיסי GPU כך שמשאב GPU יחיד ישותף בין כמה קונטיינרים בו-זמנית.
|
| הפעלת המידרוג האוטומטי באשכולות רגילים | GKE משנה באופן אוטומטי את הגודל של מספר הצמתים במאגר צמתים נתון על סמך הדרישות של עומסי העבודה. אתם לא צריכים להוסיף או להסיר צמתים באופן ידני או להקצו�� יותר מדי משאבים למאגרי הצמתים. במקום זאת, מציינים רק גודל מינימלי ומקסימלי למאגר הצמתים. מומלץ להגדיר את התוסף Cluster Autoscaler עם ההגדרה הבאה:
באשכולות Autopilot, אין צורך לדאוג להקצאת צמתים או לניהול מאגרי צמתים, כי מאגרי הצמתים מוקצים אוטומטית באמצעות הקצאה אוטומטית של צמתים, ומתבצעת התאמה אוטומטית של הגודל שלהם כדי לעמוד בדרישות של עומסי העבודה. |
| רישום האשכול לערוץ הפצה | GKE יכול לנהל באופן אוטומטי את גרסת האשכול והשדרוגים שלו. בהתאם למודל ההטמעה של הגרסה, אפשר לרשום את האשכול לערוצים הזמינים של GKE. מידע נוסף זמין במאמר איך בוחרים את ערוץ ההפצה הכי טוב לאשכולות |
| הגדרת היקף תחזוקה להחרגה באשכול | אם מגדירים חלון להחרגת היקף השדרוג, GKE לא יפריע לעומסי עבודה של אצווה שפועלים לאורך זמן לצורך תחזוקה עד שהם יסתיימו. מידע נוסף זמין במאמר בנושא הגדרת היקף התחזוקה להחרגה. |
ניהול מחזור החיים של משרה
ב-Kubernetes, מריצים את עומסי העבודה (workload) בקבוצה של Pods. Pods הם קבוצות של קונטיינרים בודדים או מרובים, עם אחסון משותף ומשאבי רשת. ה-Pods מוגדרים על ידי מפרט Kubernetes.
משימה יוצרת פוד אחד או יותר ומנסה להריץ אותם באופן רציף עד שמספר מסוים של פודים מסיימים את הפעולה בהצלחה. כשה-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 שלא מוגדרת להם טולרנטיות לאפקט של ה-דחייה (taint) NoExecute. איך מטפלים בכשלים של pods שאפשר לנסות להפעיל מחדש וכשלים של pods שאי אפשר לנסות להפעיל מחדש באמצעות מדיניות כשלים של pods
|
| ניהול כמה משרות כיחידה אחת | אפשר להשתמש ב-JobSet API כדי לנהל כמה משימות כיחידה אחת, כדי לטפל בדפוסי עומס עבודה, כמו נהג אחד (או מתאם) וכמה עובדים (לדוגמה, MPIJob), תוך הגדרת ברירות מחדל של משימות שתואמות לדפוסים נפוצים על סמך תרחישי השימוש שלכם. לדוגמה, אפשר ליצור משימה עם אינדקס כברירת מחדל, ליצור שירות ללא ממשק משתמש (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. |
ניהול של ריבוי דיירים
ריבוי דיירים באשכול 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 מקבלת את ההחלטות הבאות:
כדי ללמוד איך להטמיע מערכת לתזמון משימות, אפשר לעיין במאמר הטמעה של מערכת לתזמון משימות עם שיתוף מכסות בין מרחבי שמות ב-GKE. מידע נוסף על Kueue זמין במאמר מושגים של Kueue. |
אופטימיזציה של האחסון, הביצועים והיעילות מבחינת עלויות
שימוש יעיל במשאבי מחשוב ואחסון ב-GKE יכול להפחית את העלויות. אחת מהאסטרטגיות היא לבחור את הגודל הנכון של מופעי החישוב ולהגדיר אותם כך שיתאימו לצרכים של עיבוד אצווה, בלי להתפשר על הביצועים.
בטבלה הבאה מפורטות ההמלצות העיקריות לתכנון וניהול של אחסון ולאופטימיזציה של הביצועים:
| המלצה | משאבים |
|---|---|
| שימוש בדיסקים לאחסון מתמיד ב-Compute Engine | מומלץ להשתמש בהגדרות הבאות של דיסקים קשיחים קבועים ב-Compute Engine:
|
| שימוש באחסון שמחובר לרשת | כדי להשיג ביצועים אופטימליים של אחסון, מומלץ להשתמש באחסון ברשת (NAS) לצד Persistent Disk:
|
| הגדרה של Pub/Sub | יכול להיות שעומס העבודה של אצווה גם יקרא ויכתוב נתונים. לדוגמה, אפשר להשתמש ב-Pub/Sub ולכתוב את התוצאות במחסן נתונים כמו BigQuery, שממנו מתעדכנים הדוחות ולוחות הבקרה. מומלץ להשתמש בפתרונות האחסון הבאים:
|
| ציון פרמטרים של התאמה לעומס העבודה | מומלץ להשתמש בהגדרות הבאות:
|
| אופטימיזציה של הרשת וזמן האחזור של עומסי העבודה | GKE תומך במדיניות מיקום קומפקטי למאגרי צמתים, שמציינת שהצמתים האלה (ולכן עומסי העבודה שפועלים בהם) צריכים להיות ממ��קמים בקרבה פיזית זה לזה באזור. האפשרות הזו שימושית במיוחד לעומסי עבודה עם צימוד הדוק וביצועים גבוהים, שבהם זמן טעינה קצר בין תהליכים שונים שמרכיבים את עומס העבודה הוא בעל חשיבות רבה. מידע נוסף זמין במאמר בנושא מיקום קומפקטי. |
| שימוש ב-VMs במודל Spot | מכונות Spot VM הן מכונות וירטואליות (VM) של Compute Engine שמחירן נמוך ממכונות VM רגילות של Compute Engine, ואין עליהן ערבות זמינות. מומלץ להשתמש בפתרונות הבאים:
|
| שימוש בהזרמת תמונות | כדי לשלוף קובצי אימג' של קונטיינרים, משתמשים בהעברת תמונות בסטרימינג. 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, בממשק המשתמש, מנווטים למשאב האב. |
המאמרים הבאים
- איך פורסים מערכת אצווה באמצעות Kueue
- שיטות מומלצות להרצת אפליקציות Kubernetes שעברו אופטימיזציה של עלויות ב-GKE