תכנון להשגת משאבים ב-GKE באמצעות Gemini

במאמר הזה מוסבר איך לתכנן אשכולות עמידים של Google Kubernetes Engine ‏ (GKE) ואסטרטגיות לתזמון עומסי עבודה שיעזרו לכם להשיג משאבים כמו יחידות GPU, יחידות TPU ומעבדי CPU בעלי ביצועים גבוהים. בעזרת Gemini ב-Google Cloud וב-Compute Advisor (גרסת Preview), אתם יכולים למנוע את ההמתנה של Pod ולשפר את התזמון המהימן של עומסי עבודה של AI.

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

סקירה כללית על זמינות משאבים ב-GKE

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

  • יצירה אוטומטית של מאגר צמתים: יצירה דינמית של מאגר צמתים עם כמה משפחות.
  • מעברים אוטומטיים ברמת עומס העבודה: סבילות ובוררי צמתים שהוגדרו לקבלת חומרה חלופית.
  • תזמון גיאוגרפי ואזורי: יכולות של GKE multi-zonal ו-multi-regional.
  • ניהול מקומות שמורים: שימוש בקיבולת שנרכשה מראש לפני בקשת משאבים על פי דרישה.

שיטות מומלצות לזמינות של משאבים ב-GKE

בקטע הזה מפורטות המלצות להגדלת הזמינות של הקיבולת כשמתזמנים עומסי עבודה ב-GKE. השיטות המומלצות האלה כוללות אסטרטגיות כמו תכנון דרישות חומרה גמישות, הגדרה של יצירה אוטומטית של מאגר צמתים ושימוש בפיזור גיאוגרפי כדי להתאים למגבלות משאבים. יצירה אוטומטית של מאגר צמתים מנהלת באופן אוטומטי מאגרי צמתים על סמך מפרטים של Pod. במקום להגדיר מראש מאגרי צמתים, אפשר לציין את דרישות המשאבים במניפסטים של ה-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 or 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 שפועלים במכונות וירטואליות מסוג Spot: כדי להריץ עומסי עבודה שניתן להפריע להם במכונות וירטואליות מסוג Spot, מוסיפים tolerations ומנחים את GKE לחלק את הקיבולת העודפת באזורים שונים.

שיטות מומלצות נוספות לזמינות של GKE

בנוסף לגיוון החומרה, כדאי להשתמש בשיטות המומלצות הבאות ל-GKE כדי לשפר את הצלחת ההרחבה של האשכול:

  • הטמעה של הקצאת יתר של Pod (מאגרי קיבולת): פריסה של Pods עם עדיפות נמוכה שמושהים ומשריינים מראש קיבולת של צומת. כשמוגשות עומסי עבודה של AI בעדיפות גבוהה והקיבולת האזורית מוגבלת, Kubernetes מבצעת באופן מיידי דחיקה של ה-Pods של ההשהיה, ומאפשרת למאגרי הנתונים להתחיל לפעול בלי לחכות להקצאת צמתים חדשים. מידע נוסף זמין במאמר מידע כללי על מאגרי קיבולת.
  • שימוש ב-Flex-start עם הקצאת משאבים בתור: למשימות אימון של מודלים של AI ולמשימות גדולות של עיבוד באצווה, אפשר להשתמש ב-Flex-start עם הקצאת משאבים בתור. האפשרות הזו משולבת עם Kueue ועם Dynamic Workload Scheduler. הקצאת צמתים אטומית מסוג 'הגדלה אוטומטית עם הקצאת משאבים בתור' שמונעת כשלים בהגדלת אשכולות חלקיים. מידע נוסף זמין במאמר הפעלת עומס עבודה בהיקף גדול עם הפעלה גמישה והקצאת משאבים בתור.
  • הפעלת סטרימינג של קובצי אימג' וטעינה מראש של קובצי אימג' של קונטיינרים: לקובצי אימג' גדולים של קונטיינרים של AI (כמו קובצי אימג' של PyTorch או TensorFlow שגודלם עולה על 10 GB), מפעילים סטרימינג של קובצי אימג' של GKE או משתמשים בדיסקים משניים של אתחול לטעינה מראש של קובצי אימג'. ההגדרה הזו מקצרת את זמן החימום של הצומת, וכך צמתים חדשים שהוקצו יכולים להתחיל להריץ עומסי עבודה תוך שניות. מידע נוסף זמין במאמרים שימוש בסטרימינג של תמונות כדי לשלוף תמונות של קונטיינרים ושימוש בדיסקים משניים לאתחול כדי לטעון מראש נתונים או תמונות של קונטיינרים.
  • הגדרת מדיניות המיקום של התכונה 'שינוי גודל אוטומטי של אשכולות' ל-ANY: הגדרת מאגרי צמתים (במיוחד למכונות Spot או למכונות עם הפעלה גמישה) עם מדיניות המיקום ANY. ההגדרה הזו מורה לכלי לשינוי גודל האשכול לחפש קיבולת נדרשת בכל האזורים שצוינו. המידרוג האוטומטי של האשכול מוצא קיבולת על ידי איזון מספר הצמתים. מידע נוסף זמין במאמר בנושא סקירה כללית על שינוי גודל אוטומטי של אשכולות.
  • אופטימיזציה של ניצול המאיץ באמצעות שיתוף GPU: לעומסי עבודה שלא דורשים GPU ייעודי, אפשר להשתמש בשיתוף זמן של GPU, ב-GPU מרובה מופעים (MIG) או ב-NVIDIA MPS כדי לאפשר לכמה קונטיינרים לשתף מאיץ יחיד. הגישה הזו מאפשרת לבצע אופטימיזציה של הקיבולת האפקטיבית במאגרי הצמתים. מידע נוסף זמין במאמר בנושא שיטות לשיתוף GPU ב-GKE.

שימוש ב-Compute Advisor

‫Compute Advisor הוא ממשק מבוסס-AI בGoogle Cloud מסוף, שמבוסס על Gemini, ועוזר לכם לעצב ארכיטקטורות עמידות ל-GKE. הכלי Compute Advisor מספק הנחיות לגבי הזמינות של מכונות וירטואליות מסוג Flex-start ומכונות וירטואליות מסוג Spot כמעט בזמן אמת, תוך אימות של מדיניות הארגון ומכסות המשאבים לפני הפריסה. ‫Compute Advisor לא מספק הנחיות לגבי זמינות של עומסי עבודה שדורשים משאבים על פי דרישה.

כדי לגשת אל Gemini במסוף Google Cloud :

  1. במסוף Google Cloud , נכנסים לדף Overview.

    לסקירה הכללית

  2. בקטע תכנון התשתית באמצעות Compute Advisor, שולחים הנחיה. ‫Gemini מתחיל ליצור תשובה.

  3. כדי ליצור המלצות לארכיטקטורה, מריצים אחת מההנחיות לדוגמה הבאות ב-Compute Advisor. כשלוחצים על הלחצנים Run prompt in Compute Advisor, יכול להיות שיחלפו יותר מ-15 שניות עד ש Google Cloud המסוף ייטען:

    • אסטרטגיה כללית להאצת הצמיחה:

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

      Configure a GKE cluster to improve chances of obtaining scarce GPU or TPU capacity.

      הפעלת פרומפט ב-Compute Advisor

    • גמישות גיאוגרפית ומעברים אוטומטיים לגיבוי:

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

      Configure multi-region fallbacks and geographic scheduling on GKE to increase GPU availability.

      הפעלת פרומפט ב-Compute Advisor

    • צריכת הזמנות בעדיפות גבוהה:

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

      Configure GKE autoscaling rules and Pod specs to prioritize consuming active reservations before scaling into on-demand pools.

      הפעלת פרומפט ב-Compute Advisor

    • ComputeClasses for fallback prioritization:

      תרחיש לדוגמה: שימוש בהנחיה הזו כדי ליצור את מניפסט ה-YAML עבור ComputeClass CustomResourceDefinition שנותן עדיפות ליחידות GPU עם ביצועים גבוהים, אבל כולל חלופות ברמה נמוכה יותר כדי להבטיח תזמון של עומסי עבודה.

      Define a ComputeClass manifest for GKE to prioritize A2 GPU nodes with automatic fallbacks to L4 or T4 GPUs.

      הפעלת פרומפט ב-Compute Advisor

    • יצירה אוטומטית של מאגר צמתים לצורך גיוון:

      תרחיש לדוגמה: אפשר להשתמש בהנחיה הזו כדי לכתוב את מניפסט ה-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.

      הפעלת פרומפט ב-Compute Advisor

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