במאמר הזה מוסבר איך לתכנן אשכולות עמידים של Google Kubernetes Engine (GKE) ואסטרטגיות לתזמון עומסי עבודה שיעזרו לכם להשיג משאבים כמו יחידות GPU, יחידות TPU ומעבדי CPU בעלי ביצועים גבוהים. בעזרת Gemini ב-Google Cloud וב-Compute Advisor (גרסת Preview), אתם יכולים למנוע את ההמתנה של Pod ולשפר את התזמון האמין של עומסי עבודה של AI.
המסמך הזה מיועד לאדריכלי ענן, לאדמינים ולמפעילים של פלטפורמות שמנהלים את התשתית של GKE ורוצים לבצע אופטימיזציה של תכנון הקיבולת והתזמון.
סקירה כללית על הגמישות, היעילות והזמינות של קיבולת מחשוב ב-GKE
תזמון ב-Kubernetes מסתמך על בקשות משאבים מוצהרות. כשמתזמנים מאיצים בקנה מידה גדול, כמו GPU או TPU, בקשות משאבים מחמירות עלולות לגרום לכך שלא תהיה אפשרות להגדיל את קנה המידה של האשכולות אם חומרה ספציפית לא זמינה. כדי לבצע אופטימיזציה של זמינות הקיבולת ב-GKE, אפשר להשתמש בתכונות הבאות:
- יצירה אוטומטית של מאגר צמתים: יצירה דינמית של מאגר צמתים עם כמה משפחות.
- גיבויים ברמת עומס העבודה: סובלנות ובוררי צמתים שהוגדרו לקבל חומרה חלופית.
- תזמון גיאוגרפי ואזורי: יכולות של GKE multi-zonal ו-multi-regional.
- ניהול הזמנות: שימוש בקיבולת שנרכשה מראש לפני בקשת משאבים על פי דרישה.
שיטות מומלצות לשיפור הגמישות, היעילות והזמינות של קיבולת מחשוב ב-GKE
בקטע הזה מפורטות המלצות להגדלת הזמינות של הקיבולת כשמתזמנים עומסי עבודה ב-GKE. השיטות המומלצות האלה כוללות אסטרטגיות כמו תכנון דרישות גמישות לחומרה, הגדרה של יצירה אוטומטית של מאגר צמתים ושימוש בפיזור גיאוגרפי כדי להתאים למגבלות משאבים. יצירה אוטומטית של מאגר צמתים מנהלת באופן אוטומטי מאגרי צמתים על סמך מפרטי Pod. במקום להגדיר מראש מאגרי צמתים, אתם יכולים לציין את דרישות המשאבים במניפסטים של הפודים, ולאפשר ל-GKE ליצור צמתים באופן דינמי.
אתם יכולים גם להשתמש ב-Compute Advisor כדי לגלות את השיטות המומלצות הבאות וליישם אותן. מידע נוסף זמין במאמר בנושא שימוש ב-Compute Advisor.
אפשרויות להגדלת הזמינות של קיבולת מחשוב
כדי לשפר את הזמינות של הקיבולת, אתם יכולים להורות ל-GKE להימנע מקישור של עומסי עבודה למשפחת מכונות סטטית אחת או לסוג אחד של מאיץ. בדוגמאות הבאות אפשר לראות איך מגדירים מאגרי צמתים גמישים וכללי שיוך של Pod לסוגים שונים של עומסי עבודה. החלופות הספציפיות שתבחרו תלויות בדרישות המשאבים של האפליקציה:
מאגרי צמתים של מעבדים לשימוש כללי:
- דוגמה ראשית: N2 (למטרות כלליות, מבוסס-Intel).
- חלופות לדוגמה: N2D (AMD EPYC), C2 או C2D (מותאם לצריכת מעבד גבוהה) או E2 (מותאם לעלות).
- דפוס הטמעה: הגדרת מפרטי Pod עם זיקת צומת או עם סבילות שמאפשרות תזמון בכמה תוויות של משפחות מכונות, למשל
cloud.google.com/machine-familyב-["n2", "n2d", "c2d"]. ההגדרה הזו מאפשרת ל-GKE להקצות את המאגר שיש בו קיבולת זמינה.
מאגרי צמתים של GPU:
- דוגמה עיקרית: סדרת A2 (מעבדי GPU של NVIDIA A100).
- חלופות לדוגמה: L4 (Universal AI/ML) או T4 (Inference).
- דפוס הטמעה: הגדרת מאגרי צמתים נפרדים או ComputeClasses לרמות שונות של GPU. לעומסי עבודה שיכולים לפעול בלי תכונות ספציפיות ל-A100, אפשר לאפשר ל-Pods לעבור למאגרי L4 או T4 אם הקצאת A2 מוגבלת.
מאגרי צומתי TPU:
- דוגמה עיקרית: TPU Ironwood (TPU7x).
- דוגמאות לחלופות: TPU v6 (Trillium) או TPU v5 (v5e או v5p).
- דפוס הטמעה: הקצאת פרוסות TPU יכולה להיות מוגבלת מאוד. תכננו עומסי עבודה לאימון עם גמישות ברמת המסגרת (לדוגמה, הגדרות של JAX או PyTorch שתומכות בטופולוגיות של פרוסות משתנות) כדי לפרוס בפרוסות v6 או v5 כשקיבולת TPU Ironwood (TPU7x) לא זמינה.
בטבלה הבאה מפורטות האפשרויות העיקריות והחלופות לחומרה לסוגים שונים של עומסי עבודה:
| סוג עומס העבודה | דוגמה לבחירה ראשונית | חלופות לדוגמה | שיקולים ארכיטקטוניים |
|---|---|---|---|
| עומסי עבודה של המערכת או עומסי עבודה בסיסיים | N2 | N2D, C2D, E2 | מאגרי חומרה של Intel ו-AMD ליצירה אוטומטית של מאגרי צמתים. |
| הסקת מסקנות ועיבוד באמצעות GPU | A2 (A100) | L4, T4 | מטרגט באופן גמיש מאגרי צמתים של GPU בעלות נמוכה יותר או בזמינות גבוהה יותר. |
| אימון מודלים של TPU | TPU Ironwood (TPU7x) | TPU v6, TPU v5 (v5e או v5p) | שימוש בטופולוגיות גמישות לתזמון מבוסס-פרוסות. |
הטמעת יצירה אוטומטית של מאגרי צמתים ו-ComputeClasses
כדי לבצע אופטימיזציה של זמינות הקיבולת, אפשר לשלב יצירה אוטומטית של מאגר צמתים עם ComputeClasses. הרשימה הבאה כוללת שיטות מומלצות:
הגדרת ComputeClasses: יצירת משאבי ComputeClass שמציינים רשימה של משפחות מכונות, סוגי GPU או מודלים של הקצאת משאבים לפי סדר עדיפות. מערכת GKE מנסה להקצות צמתים באמצעות ההגדרה עם העדיפות הכי גבוהה שזמינה במחלקה. רשימת גיבוי מתועדפת עוזרת לכם מאוד להשיג את המשאבים שעומסי העבודה שלכם צריכים. לדוגמה, כדי למנוע מ-GKE לחזור למכונות למטרות כלליות כשמאיץ מיוחד מועדף לא זמין, מוסיפים את ההגדרה
whenUnsatisfiable: DoNotScaleUpלהגדרת ComputeClass. מידע נוסף מופיע במאמר שליטה במאפייני צמתים עם שינוי גודל אוטומטי באמצעות ComputeClasses בהתאמה אישית.הפניה ל-ComputeClasses במפרטי ה-Pod: במפרטים של ה-Pod של עומס העבודה, משתמשים בתווית
cloud.google.com/compute-classכדי לטרגט את ה-ComputeClass המותאם אישית במקום סוג ספציפי של משפחת מכונות או GPU. למידע נוסף, ראו בקשת ComputeClass בעומס עבודה.הגדרת כמה סבילות: אם לא משתמשים ב-ComputeClasses, משתמשים בכללי זיקה של צומת במפרטי ה-Pod שמאפשרים טווח של משפחות מכונות (כמו
cloud.google.com/machine-familyב-["n2", "n2d"]). מידע נוסף זמין במאמר הגדרת יצירה אוטומטית של מאגר צמתים.
גמישות גיאוגרפית וגמישות במספר אזורים ב-GKE
כדי להגדיל את זמינות הקיבולת, אפשר לפרוס אשכולות GKE שמשתרעים על כמה אזורים, או להפעיל ארכיטקטורות מרובות אשכולות:
אשכולות מרובי אזורים: מוודאים שמאגרי הצמתים מוגדרים להתאמה אוטומטית לעומס בכל התחומים הזמינים באזור.
איחוד אשכולות מרובי אזורים: לעבודות גדולות אסינכרוניות (כמו הסקה אופליין של אצווה או אימון מבוזר), אפשר לפרוס כלי לתזמור של מספר אשכולות (כמו Kueue או Cluster Director) כדי להוסיף עומסי עבודה לתור באופן גלובלי ולשלוח אותם לאזור עם קיבולת זמינה.
Pods שפועלים ב-VM במודל Spot: אפשר להריץ עומסי עבודה שניתנים להפרעה ב-VM במודל Spot על ידי הוספת טולרנטיות והנחיה ל-GKE לחלק את הקיבולת העודפת באזורים שונים.
שיטות מומלצות נוספות לגמישות, ליעילות ולזמינות של קיבולת המחשוב ב-GKE
בנוסף לגיוון החומרה, כדאי להשתמש בשיטות המומלצות הבאות ב-GKE כדי לבצע אופטימיזציה של התאמת קנה המידה של האשכולות:
- הטמעה של הקצאת יתר של Pod (מאגרי קיבולת): פריסה של Pod עם עדיפות נמוכה שמושהה ומשריין מראש קיבולת של צומת. כשמגישים עומסי עבודה של AI בעדיפות גבוהה והקיבולת האזורית מוגבלת, Kubernetes מיד מפקיע את הפודים המושהים, וכך מאפשר למאגרים להתחיל לפעול בלי לחכות להקצאת צמתים חדשים. מידע נוסף זמין במאמר בנושא מאגרי קיבולת.
- שימוש ב-Flex-start עם הקצאת משאבים בהמתנה: למשימות אימון של מודלי AI ולמשימות גדולות של עיבוד נתונים באצווה, אפשר להשתמש ב-Flex-start עם הקצאת משאבים בהמתנה. האפשרות הזו משולבת עם Kueue ועם Dynamic Workload Scheduler. התחלה גמישה (Flex-start) עם הקצאת משאבים בהמתנה, שבה כל הצמתים מוקצים או שאף אחד מהם לא מוקצה, כדי למנוע כשלים חלקיים בהרחבה אנכית של האשכול. מידע נוסף זמין במאמר הפעלת עומס עבודה בהיקף גדול עם התחלה גמישה והקצאת משאבים בהמתנה.
- הפעלת סטרימינג של תמונות וטעינה מראש של קובצי אימג' של קונטיינר: לקובצי אימג' גדולים של קונטיינר AI (כמו קובצי אימג' של PyTorch או TensorFlow שגודלן עולה על 10 GB), מפעילים סטרימינג של תמונות GKE או משתמשים בדיסקי אתחול משניים לטעינה מראש של קובצי אימג'. התצורה הזו מקצרת את זמן החימום של הצומת, וכך מאפשרת לצמתים חדשים שהוקצו להתחיל להריץ עומסי עבודה תוך שניות. מידע נוסף זמין במאמרים בנושא שימוש בסטרימינג של קובצי אימג' כדי לשלוף קובצי אימג' של קונטיינרים ושימוש בדיסקי אתחול משניים כדי לטעון מראש נתונים או קובצי אימג' של קונטיינרים.
- מגדירים את מדיניות המיקום של Cluster Autoscaler לערך
ANY: מגדירים מאגרי צמתים (בעיקר ל-VM במודל Spot או התחלה גמישה) עם מדיניות המיקוםANY. ההגדרה הזו מורה למידרוג האוטומטי של האשכול לחפש קיבולת נדרשת בכל התחומים שצוינו. המידרוג האוטומטי של האשכול מוצא קיבולת על פני מספר הצמתים לאיזון. מידע נוסף זמין במאמר בנושא סקירה כללית על מידרוג אוטומטי של אשכולות. - אופטימיזציה של ניצול המאיץ באמצעות שיתוף GPU: לעומסי עבודה שלא דורשים GPU ייעודי, אפשר להשתמש בשיתוף זמן של GPU, ב-GPU מרובה מופעים (MIG) או ב-NVIDIA MPS כדי לאפשר לכמה קונטיינרים לשתף מאיץ יחיד. הגישה הזו מאפשרת לבצע אופטימיזציה של הקיבולת האפקטיבית במאגרי הצמתים. מידע נוסף זמין במאמר בנושא שיטות לשיתוף GPU ב-GKE.
שימוש ב-Compute Advisor
Compute Advisor הוא ממשק מבוסס-AI במסוףGoogle Cloud , שפועל באמצעות Gemini ועוזר לכם לתכנן ארכיטקטורות גמישות וחסכוניות ל-GKE.
הכלי Compute Advisor מספק הנחיות לגבי זמינות של Flex-start VMs ו-VM במודל Spot כמעט בזמן אמת, תוך אימות המדיניות והמכסות של משאבי הארגון לפני הפריסה. הכלי Compute Advisor לא מספק הנחיות לגבי זמינות של עומסי עבודה שדורשים משאבים על פי דרישה.
כדי לגשת ל-Gemini במסוף Google Cloud :
-
נכנסים לדף Overview במסוף Google Cloud .
-
בקטע תכנון התשתית באמצעות Compute Advisor, שולחים הנחיה. Gemini מתחיל ליצור תשובה.
-
כדי ליצור המלצות לארכיטקטורה, מריצים את אחת מהנחיות לדוגמה הבאות ב-Compute Advisor. כשלוחצים על הלחצנים Run prompt in Compute Advisor, יכול להיות שיחלפו יותר מ-15 שניות עד שהמסוף Google Cloud ייטען:
אסטרטגיית מאיצים כללית:
תרחיש שימוש: אפשר להשתמש בהנחיה הזו כדי לנתח אותות של קיבולת אזורית ולקבל המלצות לגבי סוגי מכונות, אזורים ואסטרטגיות לגיבוי תזמון כשמתכננים הגדרות של אשכולות.
Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.גמישות גיאוגרפית ומעברים אוטומטיים:
תרחיש לדוגמה: אפשר להשתמש בהנחיה הזו כשמתכננים ארכיטקטורות מרובות אשכולות או מערכות גלובליות לתור משימות (לדוגמה, עם Kueue) כדי להעביר את הביצוע של עומסי עבודה בין אזורים בהתאם לזמינות המשאבים.
Configure multi-region fallbacks and geographic scheduling on GKE to increase GPU availability.צריכת הזמנות בעדיפות גבוהה:
תרחיש שימוש: אפשר להשתמש בפרומפט הזה כדי ליצור תבניות הגדרת YAML לכללי זיקה (affinity) של Pod וכללי התאמה אוטומטית לעומס (autoscaling) שמתעדפים את קיבולת המקום השמור.
Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.ComputeClasses לתעדוף חלופות:
תרחיש לדוגמה: שימוש בהנחיה הזו כדי ליצור את מניפסט ה-YAML של ComputeClass CustomResourceDefinition שמתעדף מעבדים גרפיים עם ביצועים גבוהים, אבל כולל אפשרויות חלופיות ברמה נמוכה יותר כדי להבטיח את תזמון עומסי העבודה.
Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.יצירה אוטומטית של מאגר צמתים לצורך גיוון:
תרחיש לדוגמה: אפשר להשתמש בהנחיה הזו כדי לכתוב את מניפסט ה-YAML למגבלות המשאבים של המידרוג האוטומטי של האשכול ב-GKE ולכללי הזיקה של Pod, שמאפשרים ל-NAP להקצות באופן אוטומטי צומתי GPU או CPU חלופיים.
Configure GKE node pool auto-creation to diversify machine families and prevent pending pods when regional accelerator capacity is constrained.
המאמרים הבאים
- תכנון ואופטימיזציה של אשכולות GKE באמצעות Compute Advisor
- הגדרת יצירה אוטומטית של מאגר צמתים
- פתרון בעיות בהתאמה אופקית של קבוצות Pod לעומס