יצירת אשכול GKE שעבר אופטימיזציה ל-AI באמצעות Cluster Toolkit

במאמר הזה מוסבר איך ליצור אשכול Google Kubernetes Engine ‏ (GKE) שעבר אופטימיזציה ל-AI, שמשתמש במופעי Compute Engine מסוג A4X, ‏ A4, ‏ A3 Ultra, ‏ A3 Mega ו-A3 High (8 יחידות GPU) כדי לתמוך בעומסי העבודה של AI ו-ML.

סדרות המכונות A4X,‏ A4,‏ A3 Ultra,‏ A3 Mega ו-A3 High (עם 8 GPUs) מיועדות להפעלה של אשכולות AI/ML בקנה מידה גדול, עם תכונות כמו מיקום ממוקד של עומסי עבודה, אמצעי בקרה מתקדמים לתחזוקת אשכולות ותזמון מודע-טופולוגיה. מידע נוסף מופיע במאמר סקירה כללית על ניהול אשכולות.

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

בחירת אופן היצירה של אשכול GKE שעבר אופטימיזציה באמצעות AI

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

לפני שמתחילים

לפני שמתחילים, חשוב לוודא שביצעתם את המשימות הבאות:

  • מפעילים את ממשק ה-API של Google Kubernetes Engine.
  • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • מוודאים שיש לכם את ההרשאות הנדרשות ליצירה ולניהול של אשכול GKE וחשבונות השירות המשויכים:
    • אדמין ב-Kubernetes Engine‏ (roles/container.admin)
    • אדמין של Compute ‏ (roles/compute.admin)
    • אדמין לניהול נפח האחסון (roles/storage.admin)
    • אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin)
    • אדמין בחשבון שירות (roles/iam.serviceAccountAdmin)
    • משתמש בחשבון שירות (roles/iam.serviceAccountUser)
    • Service Usage Consumer (roles/serviceusage.serviceUsageConsumer)
    • אדמין לניהול תפקידים (roles/iam.roleAdmin)
    • Secret Manager מנהל גרסאות סודות (roles/secretmanager.secretVersionManager)
    • כדי להשתמש במקום שמור שמשויך לפרויקט יחיד: Compute Instance Admin ‏ (v1) (roles/compute.instanceAdmin.v1) בפרויקט
    • כדי לצרוך מקום שמור משותף: Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1) בפרויקט הבעלים ובכל פרויקט צרכן שבו רוצים לצרוך את המקום השמור.

בחירת אפשרות צריכה וקבלת קיבולת

  1. בחירת אפשרות צריכה. הבחירה צריכה להתבסס על האופן שבו רוצים לקבל ולהשתמש במשאבי GPU. מידע נוסף זמין במאמר בנושא בחירת אפשרות צריכה.

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

  2. קבלת נפח אחסון. התהליך להשגת קיבולת שונה בכל אפשרות צריכה.

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

דרישות

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

  • ב-A4X Max, צריך להשתמש באחת מהגרסאות הבאות:

    • לגרסה 1.35 ואילך, צריך להשתמש בגרסה ‎1.35.0-gke.2745000 ואילך של GKE.
    • בגרסה 1.34, צריך להשתמש בגרסה ‎1.34.3-gke.1318000 ואילך של GKE.

    הגרסאות האלה עוזרות לוודא ש-A4X Max משתמש ב:

    • ‫R580.95.05, הגרסה המינימלית של מנהל התקן ה-GPU ל-A4X Max, שמופעלת כברירת מחדל.
    • ניהול זיכרון עקבי מבוסס-מנהלי התקנים (CDMM), שמופעל כברירת מחדל. ‫NVIDIA ממליצה להפעיל את המצב הזה באשכולות Kubernetes כדי לפתור בעיות של דיווח יתר על זיכרון. ‫CDMM מאפשר לנהל את זיכרון ה-GPU דרך הדרייבר במקום דרך מערכת ההפעלה (OS). הגישה הזו עוזרת לכם להימנע מהעברת זיכרון ה-GPU למצב אונליין במערכת ההפעלה, ומציגה את זיכרון ה-GPU כצומת Non-Uniform Memory Access‏ (NUMA) למערכת ההפעלה. לא ניתן להשתמש ב-GPU מרובה מופעים כשהתכונה CDMM מופעלת. מידע נוסף על CDMM זמין במאמר בנושא תמיכה בציוד ובתוכנה.
    • ‫GPUDirect RDMA ו-MNNVL, שמומלץ להפעיל כדי שמאגרי הצמתים של A4X Max יוכלו להשתמש ביכולות הרשת של A4X Max.
  • כדי להשתמש ב-A4X, צריך להשתמש באחת מהגרסאות הבאות:

    • בגרסה 1.33 ואילך, צריך להשתמש בגרסה ‎1.33.4-gke.1036000 ואילך של GKE.
    • בגרסה 1.32, צריך להשתמש בגרסה ‎1.32.8-gke.1108000 ואילך של GKE.

    הגרסאות האלה עוזרות לוודא ש-A4X משתמש ב:

    • ‫R580, הגרסה המינימלית של מנהל התקן ה-GPU ל-A4X, שמופעלת כברירת מחדל.
    • ניהול זיכרון עקבי מבוסס-מנהלי התקנים (CDMM), שמופעל כברירת מחדל. ‫NVIDIA ממליצה להפעיל את המצב הזה באשכולות Kubernetes כדי לפתור בעיות של דיווח יתר על זיכרון. ‫CDMM מאפשר לנהל את זיכרון ה-GPU דרך הדרייבר במקום דרך מערכת ההפעלה (OS). הגישה הזו עוזרת לכם להימנע מהעברת זיכרון GPU למצב אונליין במערכת ההפעלה, והיא חושפת את זיכרון ה-GPU כצומת Non-Uniform Memory Access‏ (NUMA) למערכת ההפעלה. לא ניתן להשתמש ב-GPU מרובה מופעים כשהתכונה CDMM מופעלת. מידע נוסף על CDMM זמין במאמר בנושא תמיכה בציוד ובתוכנה.
    • ‫GPUDirect RDMA ו-MNNVL, מומלץ להפעיל אותם כדי שמאגרי הצמתים של A4X יוכלו להשתמש ביכולות הרשת של A4X.
  • חשוב לוודא שאתם משתמשים בגרסת מנהל ההתקן המינימלית של ה-GPU, בהתאם לסוג המכונה:

    • ‫A4X Max: מעבדי ה-GPU מסוג GB300 במכונות Bare Metal מסוג A4X Max דורשים לפחות את מנהל ההתקן של ה-GPU בגרסה R580.95.05. אפשר לעיין בדרישות הגרסה שצוינו קודם.
    • ‫A4X: מעבדי ה-GPU מסוג GB200 במכונות וירטואליות (VM) מסוג A4X דורשים לפחות את גרסת מנהל ההתקן של GPU מסוג R580. צריך לעיין בדרישות לגבי הגרסה שצוינו קודם.
    • ‫A4: מעבדי ה-GPU מסוג B200 במכונות וירטואליות מסוג A4 דורשים לפחות את גרסת מנהל ההתקן של GPU מסוג R570. כברירת מחדל, GKE מתקין באופן אוטומטי את גרסת הדרייבר הזו בכל צמתי A4 שפועלת בהם הגרסה המינימלית הנדרשת ל-A4,‏ 1.32.1-gke.1729000 ואילך.
    • ‫A3 Ultra: כדי להשתמש במעבדי ה-GPU מסוג H200 במכונות וירטואליות מסוג A3 Ultra, צריך לפחות את גרסת מנהל ההתקן של GPU מסוג R550, שזמינה ב-GKE 1.31 כגרסה latest של מנהל ההתקן. ב-A3 Ultra, צריך להגדיר את gpu-driver-version=latest באמצעות GKE 1.31. ב-GKE גרסה ‎1.31.5-gke.1169000 ואילך,‏ GKE מתקין כברירת מחדל באופן אוטומטי גרסאות של מנהל התקן של GPU‏ R550 בצמתי A3 Ultra.
    • ‫A3 Mega ו-A3 High: כרטיסי ה-GPU מסוג H100 במכונות וירטואליות מסוג A3 High ו-A3 Mega נתמכים על ידי גרסת ברירת המחדל של מנהל התקן ה-GPU בכל הגרסאות הנתמכות של GKE. אפשר גם להגדיר את הערך gpu-driver-version=latest כדי לגשת לדרייברים חדשים יותר של סביבת הייצור שזמינים בגרסאות נתמכות של GKE.
  • במאגרי צמתים מסוג A3 Ultra, צריך להגדיר את סוג הדיסק ל-hyperdisk-balanced.

  • כדי להשתמש ב-GPUDirect RDMA, צריך להשתמש בגרסאות המינימליות הבאות בהתאם לסוג המכונה:

    • ‫A4X Max: אפשר לעיין בדרישות הגרסה שצוינו קודם.
    • ‫A4X: ראו את דרישות הגרסה שצוינו קודם.
    • ‫A4: שימוש בגרסה 1.32.2-gke.1475000 ואילך.
    • ‫A3 Ultra: שימוש בגרסה 1.31.4-gke.1183000 ואילך.
  • כדי להשתמש ב-GPUDirect-TCPXO (ל-A3 Mega) וב-GPUDirect-TCPX (ל-A3 High), צריך להשתמש בגרסאות GKE הבאות:

    • ‫A3 High: אפשר להשתמש בכל גרסה זמינה של GKE לפני גרסה 1.34.
    • ‫A3 Mega: אפשר להשתמש בכל גרסה זמינה של GKE.
  • כדי להשתמש ב-GPUDirect RDMA, הצמתים של GKE צריכים להשתמש בתמונת צומת של מערכת הפעלה שמותאמת לקונטיינרים. אין תמיכה בתמונות של צמתים ב-Ubuntu וב-Windows.

  • כדי ליצור אשכולות עם A4X Max ו-A4X, צריך להשתמש במודל הקצאת משאבים שמוגבל להזמנה. אין תמיכה במודלים אחרים של הקצאת הרשאות.

יצירת אשכול באמצעות Cluster Toolkit

כדי ליצור אשכול באמצעות Cluster Toolkit, פועלים לפי ההוראות הבאות. בקטע הזה מוסבר איך ליצור אשכול, ואיך לוודא שהפרויקט פועל בהתאם לשיטות המומלצות ועומד בדרישות לאשכול GKE שעבר אופטימיזציה ל-AI. בקטע הזה מוסבר גם איך להשתמש ב-Terraform כדי להקצות ולנהל את התשתית של הפריסה.

A4X Max

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים לפעול לפי ההוראות להתקנת תלות כדי להכין סביבה אחרת.
  2. התקנת Cluster Toolkit

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

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.
  4. בexamples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml התוכנית המפורטת ממאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars בהתאם לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4x-max-bm.
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4X Max. שימו לב שאזור הזמינות הזה צריך להיות זהה לאזור הזמינות שבו המכונות זמינות בהזמנה.
    • ‫STATIC_NODE_COUNT: מספר הצמתים של A4X Max במאגר הצמתים של האשכול, שחייב להיות 18 צמתים או פחות. מומלץ להשתמש ב-18 צמתים כדי לקבל את טופולוגיית ה-GPU של 1x72 בתת-בלוק אחד באמצעות דומיין NVLink.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להתקשר ל-Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
    • בשדה reservation, משתמשים באחת מהאפשרויות הבאות, בהתאם לשאלה אם רוצים לטרגט בלוקים ספציפיים בהזמנה כשמבצעים הקצאה של מאגר הצמתים:

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

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

    • ‫RESERVATION_PROJECT_ID: מזהה הפרויקט Google Cloud שבו נמצאת ההזמנה. יכול להיות שההזמנה שלכם נמצאת בפרויקט אחר מ-PROJECT_ID.

    • ‫NUM_NODE_POOLS: מספר מאגרי הצמתים שרוצים להפעיל באשכול. אם אתם רוצים ליצור אשכול עם יותר מ-18 צמתים, אתם יכולים לציין כמה מאגרי צמתים. ערך ברירת המחדל הוא 1.

    כדי לשנות הגדרות מתקדמות, עורכים את הקובץ examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml.

  5. יוצרים Application Default Credentials ‏ (ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, אתם צריכים להיכנס ולהגדיר את פרטי הכניסה באמצעות ADC:

    gcloud auth application-default login
    
  6. משתמשים בפקודה gcluster deploy כדי לפרוס את תוכנית הבסיס ולהקצות את תשתית GKE באמצעות סוגי המכונות A4X Max:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a4x-max-bm/gke-a4x-max-bm-deployment.yaml \
    examples/gke-a4x-max-bm/gke-a4x-max-bm.yaml \
    --deployment DEPLOYMENT_NAME
    

    מחליפים את DEPLOYMENT_NAME בשם הפריסה.

  7. כשמופיעה בקשה, לוחצים על (A)pply (החלה) כדי לפרוס את תוכנית האב.

    • התוכנית יוצרת רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית האב, נוצרים משאבים שלGoogle Cloud buckets, אחסון ברשת ונפחים קבועים.

A4X

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים לפעול לפי ההוראות להתקנת תלות כדי להכין סביבה אחרת.
  2. התקנת Cluster Toolkit
  3. יוצרים קטגוריה של Cloud Storage עם ניהול גרסאות מופעל כדי לאחסן את המצב של פריסת Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.
  4. ב-examples/gke-a4x/gke-a4x-deployment.yaml blueprint ממאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars בהתאם לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4x.
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4X. חשוב לשים לב שאזור הזמינות הזה צריך להיות זהה לאזור הזמינות שבו המכונות זמינות בהזמנה שלכם.
    • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A4X במאגר הצמתים של האשכול, שחייב להיות 18 צמתים או פחות. מומלץ להשתמש ב-18 צמתים כדי לקבל את טופולוגיית ה-GPU של 1x72 בתת-בלוק אחד באמצעות דומיין NVLink.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להתקשר ל-Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
    • בשדה reservation, משתמשים באחת מהאפשרויות הבאות, בהתאם לשאלה אם רוצים לטרגט בלוקים ספציפיים בהזמנה כשמבצעים הקצאה של מאגר הצמתים:

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

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

    • ‫RESERVATION_PROJECT_ID: מזהה הפרויקט Google Cloud שבו נמצאת ההזמנה. יכול להיות שההזמנה שלכם נמצאת בפרויקט אחר מ-PROJECT_ID.

    • ‫NUM_NODE_POOLS: מספר מאגרי הצמתים שרוצים להפעיל באשכול. אם אתם רוצים ליצור אשכול עם יותר מ-18 צמתים, אתם יכולים לציין כמה מאגרי צמתים. ערך ברירת המחדל הוא 1.

    כדי לשנות הגדרות מתקדמות, עורכים את הקובץ examples/gke-a4x/gke-a4x.yaml.

  5. יוצרים Application Default Credentials ‏ (ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, אתם צריכים להיכנס ולהגדיר את פרטי הכניסה באמצעות ADC:

    gcloud auth application-default login
    
  6. פורסים את תוכנית ה-Blueprint כדי להקצות את התשתית של GKE באמצעות סוגי מכונות A4X:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a4x/gke-a4x-deployment.yaml \
    examples/gke-a4x/gke-a4x.yaml
    
  7. כשמופיעה בקשה, לוחצים על (A)pply (החלה) כדי לפרוס את תוכנית האב.

    • התוכנית יוצרת רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית האב, נוצרים משאבים שלGoogle Cloud buckets, אחסון ברשת ונפחים קבועים.

A4

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים לפעול לפי ההוראות להתקנת תלות כדי להכין סביבה אחרת.
  2. התקנת Cluster Toolkit

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

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.
  4. הקבצים שצריך לערוך כדי ליצור אשכול תלויים באפשרות הצריכה שבה אתם משתמשים לפריסה. בוחרים את הכרטיסייה שמתאימה למודל ההקצאה של אפשרות הצריכה.

    נדרשת הזמנה

    ב-examples/gke-a4/gke-a4-deployment.yaml blueprint מתוך מאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars בהתאם לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4.
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4. חשוב לשים לב שאזור הזמינות הזה צריך להיות זהה לאזור הזמינות שבו המכונות זמינות בהזמנה שלכם.
    • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A4 באשכול.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
    • בשדה reservation, משתמשים באחת מהאפשרויות הבאות, בהתאם לשאלה אם רוצים לטרגט בלוקים ספציפיים בהזמנה כשמבצעים הקצאה של מאגר הצמתים:

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

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

    כדי לשנות הגדרות מתקדמות, עורכים את examples/gke-a4/gke-a4.yaml.

    Flex-start

    1. ב-examples/gke-a4/gke-a4-deployment.yaml blueprint מתוך מאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars בהתאם לערכים הספציפיים של הפריסה:

      • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4.
      • ‫REGION: אזור המחשוב של האשכול.
      • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4.
      • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מסירים את השדה reservation ומחליפים אותו בשדה enable_flex_start: true. מוסיפים בשורה הבאה enable_queued_provisioning: true אם רוצים להשתמש גם בהקצאת הרשאות בתור. מידע נוסף זמין במאמר בנושא שימוש במאגרי צמתים עם flex-start עם הקצאת משאבים בתור.
      • הסרה של static_node_count.
    2. בתוכנית examples/gke-a4/gke-a4.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מסירים את static_node_count.
      • בבלוק vars, מוודאים שהמספר version_prefix הוא "1.32." ומעלה. כדי להשתמש בהתחלה גמישה ב-GKE, האשכול צריך להיות בגרסה 1.32.2-gke.1652000 ואילך.
      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-enable_flex_start: true, ואפשר גם ב-enable_queued_provisioning: true.
      • בבלוק vars, אם לא נדרשת הקצאת משאבים בהמתנה, מסירים את השורה הבאה: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • בקטע id: a4-pool, מסירים את השורה הבאה: static_node_count: $(vars.static_node_count).
      • בקטע id: a4-pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורות הבאות:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • להקצאת משאבים בהמתנה, אם רוצים להפעיל אותה, מוסיפים את השורות הבאות:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • בקטע id: workload-manager-install, מסירים את הבלוק הבא:

         kueue:
            install: true
            config_path: $(vars.kueue_configuration_path)
            config_template_vars:
               num_gpus: $(a3-ultragpu-pool.static_gpu_count)
               accelerator_type: $(vars.accelerator_type)
        
        • כדי להגדיר הקצאת משאבים בהמתנה עם התחלה גמישה:

          1. מוסיפים את gpu_nominal_quota: NOMINAL_QUOTA לבלוק vars. הערך gpu_nominal_quota משמש להגדרת nominalQuota של יחידות ה-GPU במפרט ClusterQueue (בשלב הבא מוסבר על הגדרת ClusterQueue). בדוגמה הזו, ClusterQueue מאפשר עומסי עבודה רק אם סכום בקשות ה-GPU קטן או שווה לערך NOMINAL_QUOTA. מידע נוסף על ClusterQueue זמין במסמך Kueue בנושא תור אשכול.

          2. מעדכנים את הבלוק kueue כך:

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. מחליפים את התוכן של הקובץ kueue-configuration.yaml.tftpl בתוכן הבא:

            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ResourceFlavor
            metadata:
               name: "default-flavor"
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: AdmissionCheck
            metadata:
               name: dws-prov
            spec:
               controllerName: kueue.x-k8s.io/provisioning-request
               parameters:
                  apiGroup: kueue.x-k8s.io
                  kind: ProvisioningRequestConfig
                  name: dws-config
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ProvisioningRequestConfig
            metadata:
               name: dws-config
            spec:
               provisioningClassName: queued-provisioning.gke.io
               managedResources:
               - nvidia.com/gpu
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ClusterQueue
            metadata:
               name: "dws-cluster-queue"
            spec:
               namespaceSelector: {}
               resourceGroups:
               - coveredResources: ["nvidia.com/gpu"]
                  flavors:
                  - name: "default-flavor"
                  resources:
                  - name: "nvidia.com/gpu"
                     nominalQuota: ${num_gpus}
               admissionChecks:
               - dws-prov
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: LocalQueue
            metadata:
               namespace: "default"
               name: "dws-local-queue"
            spec:
               clusterQueue: "dws-cluster-queue"
            ---
            
      • בקטע id: job-template, מחליפים את המשתנה node_count ב-2.

    Spot

    1. ב-examples/gke-a4/gke-a4-deployment.yaml blueprint מתוך מאגר GitHub, ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars בהתאם לערכים הספציפיים של הפריסה:

      • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת. ערך ברירת המחדל הוא gke-a4.
      • ‫REGION: אזור המחשוב של האשכול.
      • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A4.
      • ‫STATIC_NODE_COUNT: מספר צמתי A4 באשכול.
      • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מחליפים את כל בלוק reservation (כולל השורה reservation עצמה) ב-spot: true.
    2. בתוכנית examples/gke-a4/gke-a4.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.
      • בקטע id: a4-pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורה הבאה:

        • spot: $(vars.spot)
  5. יוצרים Application Default Credentials ‏ (ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, אתם צריכים להיכנס ולהגדיר את פרטי הכניסה באמצעות ADC:

    gcloud auth application-default login
    
  6. פורסים את תוכנית ה-blueprint כדי להקצות את התשתית של GKE באמצעות סוגי מכונות A4:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a4/gke-a4-deployment.yaml \
    examples/gke-a4/gke-a4.yaml
    
  7. כשמופיעה בקשה, לוחצים על (A)pply (החלה) כדי לפרוס את תוכנית האב.

    • התוכנית יוצרת רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית האב, נוצרים משאבים שלGoogle Cloud buckets, אחסון ברשת ונפחים קבועים.

A3 Ultra

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים לפעול לפי ההוראות להתקנת תלות כדי להכין סביבה אחרת.
  2. התקנת Cluster Toolkit

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

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.
  4. הקבצים שצריך לערוך כדי ליצור אשכול תלויים באפשרות הצריכה שבה אתם משתמשים לפריסה. בוחרים את הכרטיסייה שמתאימה למודל ההקצאה של אפשרות הצריכה.

    נדרשת הזמנה

    ב-examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml blueprint ממאגר GitHub, מחליפים את המשתנים הבאים בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

    • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
    • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra. חשוב לשים לב שאזור הזמינות הזה צריך להיות זהה לאזור הזמינות שבו המכונות זמינות בהזמנה שלכם.

    • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.

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

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

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

    • ‫NODE_COUNT: מספר הצמתים של A3 Ultra באשכול.

    כדי לשנות הגדרות מתקדמות, עורכים את examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml.

    Flex-start

    1. ב-examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml blueprint ממאגר GitHub, מחליפים את המשתנים הבאים בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra.
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
      • מסירים את השדה reservation ומחליפים אותו בשדה enable_flex_start: true. מוסיפים בשורה הבאה enable_queued_provisioning: true אם רוצים להשתמש גם בהקצאת הרשאות בתור. מידע נוסף זמין במאמר בנושא שימוש במאגרי צמתים עם flex-start עם הקצאת משאבים בתור.
      • הסרה של static_node_count.
    2. ב-examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml תוכנית האב ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מסירים את static_node_count.
      • בבלוק vars, מעדכנים את המספר version_prefix ל-"1.32." ומעלה. כדי להשתמש בהתחלה גמישה ב-GKE, האשכול צריך להיות בגרסה 1.32.2-gke.1652000 ואילך.
      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-enable_flex_start: true, ואפשר גם ב-enable_queued_provisioning: true.
      • בבלוק vars, מסירים את השורה הבאה: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • בקטע id: a3-ultragpu-pool, מסירים את השורה הבאה: static_node_count: $(vars.static_node_count).
      • בקטע id: a3-ultragpu-pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורות הבאות:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • להקצאת משאבים בהמתנה, אם רוצים להפעיל אותה, מוסיפים את השורות הבאות:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • בקטע id: workload-manager-install, מסירים את הבלוק הבא:

        config_path: $(vars.kueue_configuration_path)
        config_template_vars:
          num_gpus: $(a4-pool.static_gpu_count)
          accelerator_type: $(vars.accelerator_type)
        
        • כדי להגדיר התחלה גמישה עם הקצאת משאבים בהמתנה, פועלים לפי שלושת השלבים הבאים:

          1. מוסיפים את gpu_nominal_quota: NOMINAL_QUOTA לבלוק vars. הערך gpu_nominal_quota משמש להגדרת nominalQuota של מעבדים גרפיים במפרט ClusterQueue. בדוגמה הזו, ClusterQueue מאפשר רק עומסי עבודה אם סכום הבקשות ל-GPU קטן מהערך NOMINAL_QUOTA או שווה לו. מידע נוסף על ClusterQueue זמין במסמך Kueue בנושא תור אשכול.

          2. מעדכנים את הבלוק kueue כך:

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. מחליפים את התוכן של הקובץ kueue-configuration.yaml.tftpl בתוכן הבא:

            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ResourceFlavor
            metadata:
               name: "default-flavor"
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: AdmissionCheck
            metadata:
               name: dws-prov
            spec:
               controllerName: kueue.x-k8s.io/provisioning-request
               parameters:
                  apiGroup: kueue.x-k8s.io
                  kind: ProvisioningRequestConfig
                  name: dws-config
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ProvisioningRequestConfig
            metadata:
               name: dws-config
            spec:
               provisioningClassName: queued-provisioning.gke.io
               managedResources:
               - nvidia.com/gpu
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ClusterQueue
            metadata:
               name: "dws-cluster-queue"
            spec:
               namespaceSelector: {}
               resourceGroups:
               - coveredResources: ["nvidia.com/gpu"]
                  flavors:
                  - name: "default-flavor"
                  resources:
                  - name: "nvidia.com/gpu"
                     nominalQuota: ${num_gpus}
               admissionChecks:
               - dws-prov
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: LocalQueue
            metadata:
               namespace: "default"
               name: "dws-local-queue"
            spec:
               clusterQueue: "dws-cluster-queue"
            ---
            
        • בשדה id: job-template, מחליפים את המשתנה node_count ב-2.

    Spot

    1. בקטע examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml blueprint from the GitHub repo (תוכנית בסיסית ממאגר GitHub), ממלאים את ההגדרות הבאות בקטעים terraform_backend_defaults ו-vars בהתאם לערכים הספציפיים של הפריסה:

      • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫COMPUTE_REGION: אזור המחשוב של האשכול.
      • ‫COMPUTE_ZONE: אזור החישוב של מאגר הצמתים של מכונות A3 Ultra.
      • ‫IP_ADDRESS/SUFFIX: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מחליפים את כל בלוק reservation (כולל השורה reservation עצמה) ב-spot: true.
      • ‫NODE_COUNT: מספר הצמתים של A3 Ultra באשכול.
    2. בתוכנית examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מחליפים את כל המשתנה reservation ב-spot: true.
      • בקטע id: a3-ultragpu-pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורה הבאה:

        • spot: $(vars.spot)
  5. יוצרים Application Default Credentials ‏(ADC) כדי לספק גישה ל-Terraform. אם אתם משתמשים ב-Cloud Shell, אתם צריכים להיכנס ולהגדיר את פרטי הכניסה באמצעות ADC:

    gcloud auth application-default login
    
  6. פריסת התוכנית ליצירת תשתית GKE באמצעות סוגי מכונות A3 Ultra:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a3-ultragpu/gke-a3-ultragpu-deployment.yaml \
    examples/gke-a3-ultragpu/gke-a3-ultragpu.yaml
    
  7. כשמופיעה בקשה, לוחצים על (A)pply (החלה) כדי לפרוס את תוכנית האב.

    • התוכנית יוצרת רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית האב, נוצרים משאבים שלGoogle Cloud buckets, אחסון ברשת ונפחים קבועים.

A3 Mega

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת תלות.
  2. התקנת Cluster Toolkit

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

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של הקטגוריה החדשה ב-Cloud Storage, שצריך לעמוד בדרישות למתן שמות לקטגוריות.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.
  4. הקבצים שצריך לערוך כדי ליצור אשכול תלויים באפשרות הצריכה שבה אתם משתמשים לפריסה. בוחרים את הכרטיסייה שמתאימה למודל ההקצאה של אפשרות הצריכה.

    נדרשת הזמנה

    ב-examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml blueprint ממאגר GitHub, מחליפים את המשתנים הבאים בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Mega. שימו לב שאזור הזמינות הזה צריך להיות זהה לאזור הזמינות שבו המכונות זמינות בהזמנה שלכם.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
    • בשדה reservation, משתמשים באחת מהאפשרויות הבאות, בהתאם לשאלה אם רוצים לטרגט בלוקים ספציפיים בהזמנה כשמבצעים הקצאה של מאגר הצמתים:

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

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

    • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A3 Mega באשכול.

    כדי לשנות הגדרות מתקדמות, עורכים את examples/gke-a3-megagpu/gke-a3-megagpu.yaml.

    Flex-start

    1. ב-examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yaml blueprint ממאגר GitHub, מחליפים את המשתנים הבאים בקטעים vars כך שיתאימו לערכים הספציפיים של הפריסה:

      • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫REGION: אזור המחשוב של האשכול.
      • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Mega.
      • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
      • מסירים את השדה reservation ומחליפים אותו בשדה enable_flex_start: true. אם רוצים להשתמש גם בהקצאת הרשאות בתור, מוסיפים את enable_queued_provisioning: true לשורה הבאה. מידע נוסף זמין במאמר בנושא שימוש במאגרי צמתים עם flex-start עם הקצאת משאבים בתור.
      • הסרה של static_node_count.
    2. בתוכנית הבסיסית examples/gke-a3-megagpu/gke-a3-megagpu.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מסירים את static_node_count.
      • בבלוק vars, מעדכנים את המספר version_prefix ל-"1.32." ומעלה. כדי להשתמש בהתחלה גמישה ב-GKE, האשכול צריך להיות בגרסה 1.32.2-gke.1652000 ואילך.
      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-enable_flex_start: true, ואפשר גם ב-enable_queued_provisioning: true.
      • בבלוק vars, מסירים את השורה הבאה: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • בקטע id: a3_megagpu_pool, מסירים את השורה הבאה: static_node_count: $(vars.static_node_count).
      • בקטע id: a3_megagpu_pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורות הבאות:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • להקצאת משאבים בהמתנה, אם רוצים להפעיל אותה, מוסיפים את השורות הבאות:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • בקטע id: workload_manager_install, מסירים את הבלוק הבא:

        config_path: $(vars.kueue_configuration_path)
        config_template_vars:
          num_gpus: $(a3_megagpu_pool.static_gpu_count)
          accelerator_type: $(vars.accelerator_type)
        
        • כדי להגדיר התחלה גמישה עם הקצאת משאבים בהמתנה, פועלים לפי שלושת השלבים הבאים:

          1. מוסיפים את gpu_nominal_quota: NOMINAL_QUOTA לבלוק vars. הערך gpu_nominal_quota משמש להגדרת nominalQuota של מעבדים גרפיים במפרט ClusterQueue. בדוגמה הזו, ClusterQueue מאפשר רק עומסי עבודה אם סכום הבקשות ל-GPU קטן מהערך NOMINAL_QUOTA או שווה לו. מידע נוסף על ClusterQueue זמין במסמך Kueue בנושא תור אשכול.

          2. מעדכנים את הבלוק kueue כך:

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. מחליפים את התוכן של הקובץ kueue-configuration.yaml.tftpl בתוכן הבא:

            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ResourceFlavor
            metadata:
               name: "default-flavor"
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: AdmissionCheck
            metadata:
               name: dws-prov
            spec:
               controllerName: kueue.x-k8s.io/provisioning-request
               parameters:
                  apiGroup: kueue.x-k8s.io
                  kind: ProvisioningRequestConfig
                  name: dws-config
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ProvisioningRequestConfig
            metadata:
               name: dws-config
            spec:
               provisioningClassName: queued-provisioning.gke.io
               managedResources:
               - nvidia.com/gpu
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ClusterQueue
            metadata:
               name: "dws-cluster-queue"
            spec:
               namespaceSelector: {}
               resourceGroups:
               - coveredResources: ["nvidia.com/gpu"]
                  flavors:
                  - name: "default-flavor"
                  resources:
                  - name: "nvidia.com/gpu"
                     nominalQuota: ${num_gpus}
               admissionChecks:
               - dws-prov
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: LocalQueue
            metadata:
               namespace: "default"
               name: "dws-local-queue"
            spec:
               clusterQueue: "dws-cluster-queue"
            ---
            
        • בשדה id: job-template, מחליפים את הערך של המשתנה node_count ב-2.

    Spot

    1. ב-examples/gke-a3-megagpu/gke-a3-megagpu-deployment.yamlblueprint ממאגר GitHub, מעדכנים את המשתנים הבאים כך שיתאימו לערכים הספציפיים של הפריסה:

      • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫REGION: אזור המחשוב של האשכול.
      • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 Mega.
      • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מחליפים את כל בלוק reservation (כולל השורה reservation עצמה) ב-provisioning_model: SPOT.
      • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A3 Mega באשכול.
    2. בתוכנית examples/gke-a3-megagpu/gke-a3-megagpu.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.
      • בקטע id: a3_megagpu_pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורה הבאה:

        • spot: $(vars.spot)
  5. יוצרים Application Default Credentials ‏(ADC) כדי לספק גישה ל-Terraform. אם משתמשים ב-Cloud Shell, אפשר להריץ את הפקודה הבאה:

    gcloud auth application-default login
    
  6. פורסים את תוכנית ה-Blueprint כדי להקצות את התשתית של GKE באמצעות סוגי מכונות A3 Mega:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a3-megagpu/gke-a3-megagpu.yaml
    
  7. כשמופיעה בקשה, לוחצים על (A)pply (החלה) כדי לפרוס את תוכנית האב.

    • תוכנית האב יוצרת רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית האב, נוצרים משאבים שלGoogle Cloud buckets, אחסון ברשת ונפחים קבועים.

A3 High

  1. מפעילים את Cloud Shell. אפשר להשתמש בסביבה אחרת, אבל מומלץ להשתמש ב-Cloud Shell כי יחסי התלות כבר מותקנים מראש ב-Cluster Toolkit. אם אתם לא רוצים להשתמש ב-Cloud Shell, אתם יכולים להכין סביבה אחרת לפי ההוראות להתקנת תלות.
  2. התקנת Cluster Toolkit

  3. יוצרים קטגוריה של Cloud Storage לאחסון המצב של פריסת Terraform:

    gcloud storage buckets create gs://BUCKET_NAME \
        --default-storage-class=STANDARD \
        --project=PROJECT_ID \
        --location=COMPUTE_REGION_TERRAFORM_STATE \
        --uniform-bucket-level-access
    gcloud storage buckets update gs://BUCKET_NAME --versioning
    

    מחליפים את המשתנים הבאים:

    • ‫BUCKET_NAME: השם של קטגוריית Cloud Storage החדשה.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫COMPUTE_REGION_TERRAFORM_STATE: האזור של Compute שבו רוצים לאחסן את המצב של פריסת Terraform.
  4. הקבצים שצריך לערוך כדי ליצור אשכול תלויים באפשרות הצריכה שבה אתם משתמשים לפריסה. בוחרים את הכרטיסייה שמתאימה למודל ההקצאה של אפשרות הצריכה.

    נדרשת הזמנה

    ב-examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml blueprint ממאגר GitHub, מחליפים את המשתנים הבאים בקטעים terraform_backend_defaults ו-vars כך שיתאימו לערכים הספציפיים של הפריסה:

    • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
    • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
    • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • ‫REGION: אזור המחשוב של האשכול.
    • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 High. שימו לב שאזור הזמינות הזה צריך להיות זהה לאזור הזמינות שבו המכונות זמינות בהזמנה שלכם.
    • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה צריך לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
    • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A3 High באשכול.
    • בשדה reservation, משתמשים באחת מהאפשרויות הבאות, בהתאם לשאלה אם רוצים לטרגט בלוקים ספציפיים בהזמנה כשמבצעים הקצאה של מאגר הצמתים:

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

        RESERVATION_NAME/reservationBlocks/BLOCK_NAME
        

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

    כדי לשנות הגדרות מתקדמות, עורכים את examples/gke-a3-highgpu/gke-a3-highgpu.yaml.

    Flex-start

    1. בקובץ examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml ממאגר GitHub, מחליפים את המשתנים הבאים בקטעים vars כך שיתאימו לערכים הספציפיים של הפריסה:

      • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫REGION: אזור המחשוב של האשכול.
      • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 High.
      • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך רשתות מורשות פועלות.
      • מסירים את השדה reservation ומחליפים אותו בשדה enable_flex_start: true. אם רוצים להשתמש גם בהקצאת הרשאות בתור, מוסיפים את enable_queued_provisioning: true לשורה הבאה. מידע נוסף זמין במאמר בנושא שימוש במאגרי צמתים עם flex-start עם הקצאת משאבים בתור.
      • הסרה של static_node_count.
    2. בתוכנית הבסיסית examples/gke-a3-highgpu/gke-a3-highgpu.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מסירים את static_node_count.
      • בבלוק vars, מעדכנים את המספר version_prefix ל-"1.32." ומעלה. כדי להשתמש בהתחלה גמישה ב-GKE, האשכול צריך להיות בגרסה 1.32.2-gke.1652000 ואילך.
      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-enable_flex_start: true, ואפשר גם ב-enable_queued_provisioning: true.
      • בבלוק vars, מסירים את השורה הבאה: kueue_configuration_path: $(ghpc_stage("./kueue-configuration.yaml.tftpl")).
      • בקטע id: a3_highgpu_pool, מסירים את השורה הבאה: static_node_count: $(vars.static_node_count).
      • בקטע id: a3_highgpu_pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורות הבאות:

        • enable_flex_start: $(vars.enable_flex_start)
        • auto_repair: false
        • להקצאת משאבים בהמתנה, אם רוצים להפעיל אותה, מוסיפים את השורות הנוספות הבאות:
          • enable_queued_provisioning: $(vars.enable_queued_provisioning)
          • autoscaling_total_min_nodes: 0
      • בקטע id: workload_component_install, מסירים את הבלוק הבא:

        config_path: $(vars.kueue_configuration_path)
        config_template_vars:
          num_gpus: $(a3_highgpu_pool.static_gpu_count)
          accelerator_type: $(vars.accelerator_type)
        
        • כדי להגדיר התחלה גמישה עם הקצאת משאבים בהמתנה, פועלים לפי שלושת השלבים הבאים:

          1. מוסיפים את gpu_nominal_quota: NOMINAL_QUOTA לבלוק vars. הערך gpu_nominal_quota משמש להגדרת nominalQuota של מעבדים גרפיים במפרט ClusterQueue. בדוגמה הזו, ClusterQueue מאפשר רק עומסי עבודה אם סכום הבקשות ל-GPU קטן מהערך NOMINAL_QUOTA או שווה לו. מידע נוסף על ClusterQueue זמין במסמך Kueue בנושא תור אשכול.

          2. מעדכנים את הבלוק kueue כך:

            kueue:
               install: true
               config_path: $(vars.kueue_configuration_path)
               config_template_vars:
                  num_gpus: $(vars.gpu_nominal_quota)
            
          3. מחליפים את התוכן של הקובץ kueue-configuration.yaml.tftpl בתוכן הבא:

            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ResourceFlavor
            metadata:
               name: "default-flavor"
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: AdmissionCheck
            metadata:
               name: dws-prov
            spec:
               controllerName: kueue.x-k8s.io/provisioning-request
               parameters:
                  apiGroup: kueue.x-k8s.io
                  kind: ProvisioningRequestConfig
                  name: dws-config
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ProvisioningRequestConfig
            metadata:
               name: dws-config
            spec:
               provisioningClassName: queued-provisioning.gke.io
               managedResources:
               - nvidia.com/gpu
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: ClusterQueue
            metadata:
               name: "dws-cluster-queue"
            spec:
               namespaceSelector: {}
               resourceGroups:
               - coveredResources: ["nvidia.com/gpu"]
                  flavors:
                  - name: "default-flavor"
                  resources:
                  - name: "nvidia.com/gpu"
                     nominalQuota: ${num_gpus}
               admissionChecks:
               - dws-prov
            ---
            apiVersion: kueue.x-k8s.io/v1beta1
            kind: LocalQueue
            metadata:
               namespace: "default"
               name: "dws-local-queue"
            spec:
               clusterQueue: "dws-cluster-queue"
            ---
            
        • בשדה id: job-template, מחליפים את הערך של המשתנה node_count ב-2.

    Spot

    1. ב-examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml blueprint ממאגר GitHub, מעדכנים את המשתנים הבאים כך שיתאימו לערכים הספציפיים של הפריסה:

      • ‫BUCKET: השם של קטגוריית Cloud Storage שיצרתם בשלב הקודם.
      • ‫DEPLOYMENT_NAME: שם ייחודי לפריסה, באורך של 6 עד 30 תווים. אם שם הפריסה לא ייחודי בפרויקט, יצירת האשכול נכשלת.
      • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • ‫REGION: אזור המחשוב של האשכול.
      • ‫ZONE: אזור המחשוב של מאגר הצמתים של מכונות A3 High.
      • ‫AUTHORIZED_CIDR: טווח כתובות ה-IP שרוצים לאפשר להתחבר לאשכול. בלוק ה-CIDR הזה חייב לכלול את כתובת ה-IP של המכונה שבה רוצים להשתמש כדי להפעיל את Terraform. מידע נוסף זמין במאמר בנושא איך פועלות רשתות מורשות.
      • מחליפים את השורה reservation: בשורה provisioning_model: SPOT.
      • ‫STATIC_NODE_COUNT: מספר הצמתים מסוג A3 High באשכול.
    2. בתוכנית examples/gke-a3-highgpu/gke-a3-highgpu.yaml ממאגר GitHub, מבצעים את השינויים הבאים:

      • בבלוק vars, מחליפים את כל הבלוק reservation (כולל השורה reservation עצמה) ב-spot: true.
      • בקטע id: a3_highgpu_pool, מסירים את הבלוק reservation_affinity. מחליפים את הבלוק הזה בשורה הבאה:

        • spot: $(vars.spot)
  5. יוצרים Application Default Credentials ‏(ADC) כדי לספק גישה ל-Terraform. אם משתמשים ב-Cloud Shell, אפשר להריץ את הפקודה הבאה:

    gcloud auth application-default login
    
  6. פורסים את תוכנית ה-Blueprint כדי להקצות את התשתית של GKE באמצעות סוגי מכונות A3 High:

    cd ~/cluster-toolkit
    ./gcluster deploy -d \
    examples/gke-a3-highgpu/gke-a3-highgpu-deployment.yaml \
    examples/gke-a3-highgpu/gke-a3-highgpu.yaml
    
  7. כשמופיעה בקשה, לוחצים על (A)pply (החלה) כדי לפרוס את תוכנית האב.

    • תוכנית האב יוצרת רשתות VPC, רשת VPC של GPU RDMA, חשבונות שירות, אשכול ומאגר צמתים.
    • כדי לתמוך בתבנית של משימת fio-bench-job-template בתוכנית האב, נוצרים משאבים שלGoogle Cloud buckets, אחסון ברשת ונפחים קבועים.

בדיקת ביצועי הרשת

מומלץ לאמת את הפונקציונליות של אשכולות שהוקצו. כדי לעשות זאת, משתמשים בבדיקות NCCL, שהן בדיקות של NVIDIA Collective Communications Library (ספריית תקשורת קולקטיבית של NVIDIA‏, NCCL) שעברו אופטימיזציה לסביבת Google.

הרצת בדיקות השוואה שניתנות לשחזור

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

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

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

כדי לראות את כל המתכונים שזמינים לאימון ולסוגים אחרים של עומסי עבודה, אפשר לעיין במאגר מתכוני GPU ב-GitHub.

מחיקת משאבים שנוצרו על ידי Cluster Toolkit

כדי להימנע מחיובים חוזרים על המשאבים שבהם השתמשתם בדף הזה, מריצים את הפקודה gcluster destroy כדי למחוק את המשאבים שהוקצו על ידי Cluster Toolkit, כולל רשתות ה-VPC ואשכול GKE:

   cd ~/cluster-toolkit
   ./gcluster destroy CLUSTER_NAME/

מחליפים את CLUSTER_NAME בשם האשכול. בשביל אשכולות שנוצרו באמצעות Cluster Toolkit, שם האשכול מבוסס על DEPLOYMENT_NAME.

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