עיצוב לגמישות ויעילות של הקיבולת ב-GKE באמצעות Gemini

במאמר הזה מוסבר איך לתכנן אשכולות של Google Kubernetes Engine (GKE)‎ ואסטרטגיות לתזמון עומסי עבודה, כדי שתוכלו להשיג משאבים כמו GPUs,‏ TPUs ומעבדים עם ביצועים גבוהים. בעזרת Gemini ב-Cloud de Confiance by S3NS ו-Compute Advisor (תצוגה מקדימה), אתם יכולים למנוע פודים בהמתנה ולשפר את התזמון של עומסי עבודה של AI.

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

סקירה כללית על הגמישות, היעילות והזמינות של קיבולת המחשוב ב-GKE

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

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

שיטות מומלצות לגמישות, ליעילות ולזמינות של קיבולת המחשוב ב-GKE

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

אתם יכולים גם להשתמש ב-Compute Advisor (גרסת טרום-השקה) כדי לגלות וליישם את השיטות המומלצות הבאות. מידע נוסף מופיע במאמר שימוש ב-Compute Advisor.

אפשרויות להגדלת הזמינות של קיבולת המחשוב

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

  • מאגרי צמתים של מעבדים (CPU) לשימוש כללי:

    • דוגמה עיקרית: N4 (למטרות כלליות, מבוסס-Intel).
    • דוגמאות לחלופות: N4D (למטרות כלליות של AMD EPYC), ‏ C4 או C3 (למטרות כלליות של Intel), או C4D או C3D (למטרות כלליות של AMD EPYC).
    • תבנית הטמעה: מגדירים את מפרטי ה-Pod עם ComputeClass בהתאמה אישית או כללי זיקה של צמתים שמאפשרים תזמון בכמה תוויות של משפחות מכונות, למשל cloud.google.com/machine-family ב-["n4", "n4d", "c4", "c4d"]. ההגדרה הזו מאפשרת ל-GKE להקצות את המאגר שיש בו קיבולת זמינה.

  • מאגרי צמתים של GPU:

    • דוגמה עיקרית: סדרה A3 (מעבדי GPU מסוג NVIDIA H100) או סדרה A4 (מעבדי GPU מסוג NVIDIA B200).
    • חלופות לדוגמה: סדרת G2 (מעבדי GPU מסוג NVIDIA L4) או רמות חלופיות של מאיצים.
    • תבנית הטמעה: מגדירים מאגרי צמתים נפרדים או ComputeClasses לרמות שונות של GPU. בעומסי עבודה של הסקה או הצגה שיכולים לפעול בדורות שונים של מאיצים, אפשר לאפשר לפודים לחזור ל-G2‏ (L4) או למאגרי GPU חלופיים אם הקצאת המאיץ הראשי מוגבלת.

  • מאגרי צומתי TPU:

    • דוגמה עיקרית: TPU Ironwood (TPU7x).
    • חלופות לדוגמה: TPU v6 (Trillium) או TPU v5 (v5e או v5p).
    • דפוס הטמעה: הקצאת פרוסות TPU יכולה להיות מוגבלת מאוד. תכננו עומסי עבודה לאימון עם גמישות ברמת המסגרת (לדוגמה, הגדרות של JAX או PyTorch שתומכות בטופולוגיות של פרוסות משתנות) כדי לפרוס בפרוסות v6 או v5 כשקיבולת TPU Ironwood (TPU7x) לא זמינה.

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

סוג עומס העבודה דוגמה לבחירה ראשית אפשרויות לדוגמה שיקולים ארכיטקטוניים
עומסי עבודה של המערכת או עומסי עבודה בסיסיים N4 N4D, C4, C4D, C3, C3D הוא כולל מאגרי חומרה מודרניים של Intel ו-AMD ליצירה אוטומטית של מאגרי צמתים.
הסקה ועיבוד של GPU ‫A3 (H100) או A4 (B200) G2 (L4) מטרגט באופן גמיש מאגרי צמתים של GPU בעלות נמוכה יותר או בזמינות גבוהה יותר.
אימון מודלים של TPU ‫TPU Ironwood‏ (TPU7x) ‫TPU v6, ‏ TPU v5 (v5e או v5p) שימוש בטופולוגיות גמישות לתזמון מבוסס-פרוסות.

הטמעת יצירה אוטומטית של מאגרי צמתים ו-ComputeClasses

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

  • הגדרת ComputeClasses: יוצרים משאבי ComputeClass שמציינים רשימה בעדיפות גבוהה של משפחות מכונות, סוגי GPU או מודלים של הקצאה. ‫GKE מנסה להקצות צמתים באמצעות ההגדרה עם העדיפות הגבוהה ביותר שזמינה במחלקה. רשימת חלופות לפי סדר עדיפויות עוזרת מאוד להשיג את המשאבים שנדרשים לעומסי העבודה. לדוגמה, כדי למנוע מ-GKE לחזור למכונות לשימוש כללי כשמאי ייעודי מועדף לא זמין, מוסיפים את ההגדרה whenUnsatisfiable: DoNotScaleUp להגדרות של ComputeClass. מידע נוסף מופיע במאמר שליטה במאפייני צומת בהתאמה לעומס באמצעות ComputeClasses בהתאמה אישית.

  • הפעילו העברה פעילה (optimizeRulePriority: true) לעומסי עבודה ללא שמירת מצב (stateless) או עומסי עבודה שיכולים לסבול שיבושים: הגדירו העברה פעילה ב-ComputeClass כדי ש-GKE יבודד, ירוקן ויחליף באופן אוטומטי את צומתי הגיבוי בסדרת המכונות בעדיפות גבוהה יותר כשהקיבולת תתאושש במיקום הזה.

  • שימוש ב-StorageClasses דינמיים למעבר לדור קודם: ב-GKE בגרסה 1.35.3-gke.1290000 ואילך, כש-ComputeClass כולל סדרות Hyperdisk בלבד (כמו C4,‏ C4D ו-N4) וסדרות Persistent Disk (כמו N2 ו-N2D), צריך להגדיר עומסי עבודה עם שמירת מצב (stateful) כדי ש-GKE יבחר באופן דינמי סוג דיסק תואם. כדי לעשות את זה, משתמשים ב-StorageClass עם בחירה אוטומטית של סוג הדיסק (parameters.type: dynamic) וההגדרה volumeBindingMode: WaitForFirstConsumer.

  • הפניה ל-ComputeClasses במפרטי Pod: במפרטי ה-Pod של עומס העבודה, משתמשים בתווית cloud.google.com/compute-class כדי לטרגט את ה-ComputeClass בהתאמה אישית במקום משפחת מכונות או סוג GPU ספציפיים. מידע נוסף זמין במאמר בקשה ל-ComputeClass בעומס עבודה.

  • הגדרת כמה סבילות: אם אתם לא משתמשים ב-ComputeClasses, השתמשו בכללי שיוך (affinity) של צמתים במפרטי ה-Pod שמאפשרים מגוון של משפחות מכונות (כמו cloud.google.com/machine-family ב-["n4", "n4d", "c4", "c4d"]). מידע נוסף זמין במאמר הגדרת יצירה אוטומטית של מאגרי צמתים.

גמישות גיאוגרפית ובמספר אזורים ב-GKE

כדי להגדיל את זמינות הקיבולת, אפשר לפרוס אשכולות GKE שמתפרסים על פני כמה אזורים, או להריץ ארכיטקטורות של כמה אשכולות:

  • אשכולות בכמה אזורים: מוודאים שמאגרי הצמתים מוגדרים להתאמה אוטומטית לעומס (automatic scaling) בכל האזורים הזמינים.

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

  • פודים שפועלים ב-VM במודל Spot: מפעילים עומסי עבודה שניתנים להפרעה ב-VM במודל Spot, על ידי הוספת טולרנטיות והנחיה ל-GKE להפיץ את הקיבולת העודפת באזורים שונים.

שיטות מומלצות נוספות לגמישות, ליעילות ולזמינות של קיבולת המחשוב ב-GKE

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

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

שימוש ב-Compute Advisor

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

‫Compute Advisor מספק הנחיות לגבי הזמינות של Flex-start VM ו-VM במודל Spot כמעט בזמן אמת, ומאמת את המדיניות ואת מכסות המשאבים של הארגון לפני הפריסה. ‫Compute Advisor לא מספק הנחיות לגבי הזמינות של עומסי עבודה שדורשים משאבים על פי דרישה.

כדי לגשת ל-Gemini במסוף Cloud de Confiance :

  1. נכנסים לדף Overview במסוף Cloud de Confiance .

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

  2. בקטע Design your infrastructure with Compute Advisor, שולחים הנחיה. ‫Gemini מתחיל ליצור תשובה.

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

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

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

    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 וכללי התאמה לעומס (autoscaling) שמתעדפים את הקיבולת של ההזמנה.

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

    הפעלת הנחיה ב-Compute Advisor

  • ‫ComputeClasses לתעדוף חלופות:

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

    Define a ComputeClass manifest for GKE to prioritize A3 GPU nodes with automatic fallbacks to G2 (L4) 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

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