יצירת אשכול GKE מותאם אישית ל-AI שמשתמש ב-A4X

במאמר הזה נסביר איך ליצור אשכול Google Kubernetes Engine ‏ (GKE) שעבר אופטימיזציה ל-AI, ומשתמש במכונות וירטואליות (VM) מסוג A4X כדי לתמוך בעומסי העבודה של AI ו-ML.

סדרת מכונות A4X מאפשרת להריץ אשכולות AI/ML בקנה מידה גדול באמצעות מערכת NVIDIA Multi-Node NVLink (MNNVL), פתרון בקנה מידה של מתלה שמאפשר עוצמה וביצועים גבוהים יותר של GPU. מידע נוסף מופיע במאמר יכולות ניהול האשכול.

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

במסמך הזה תלמדו איך ליצור אשכול GKE באמצעות Google Cloud CLI, כדי להגדיר את האשכול בצורה הכי גמישה בהתאם לצרכים של עומס העבודה. אפשר גם להשתמש ב-Cluster Toolkit כדי לפרוס במהירות את האשכול עם הגדרות ברירת מחדל שמשקפות שיטות מומלצות לתרחישי שימוש רבים. למידע נוסף, אפשר לקרוא את המאמר בנושא יצירת אשכול GKE שעבר אופטימיזציה ל-AI עם הגדרת ברירת מחדל. כדי ליצור אשכול שמשתמש ב-A4 או ב-A3 Ultra – שאפשר להשתמש בו להרצת עומסי עבודה עם GPUDirect RDMA או בלי – אפשר לעיין במאמר יצירת אשכול GKE מותאם אישית ל-AI שמשתמש ב-A4 או ב-A3 Ultra.

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

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

  • מפעילים את ממשק Google Kubernetes Engine API.
  • הפעלת Google Kubernetes Engine API
  • כדי להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את gcloud CLI. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות ליצירה ולניהול של אשכול GKE, צריך לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים בפרויקט:

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

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

קבלת קיבולת

כדי לקבל קיבולת למכונות וירטואליות מסוג A4X, אפשר ליצור שריון מקום שמור לעתיד. מידע נוסף על הזמנות עתידיות אפשר למצוא בעמודה Future reservations in AI Hypercomputer בטבלה שבמאמר Choose a consumption option.

כדי לקבל קיבולת באמצעות מקום שמור לעתיד, אפשר לעיין בשורה מקום שמור לעתיד ב-AI Hypercomputer בטבלה שבמאמר איך מקבלים קיבולת.

דרישות

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

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

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

    הגרסאות האלה עוזרות לוודא ש-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.
  • הצמתים של GKE צריכים להשתמש בתמונת צומת של מערכת הפעלה שמותאמת לקונטיינרים. אין תמיכה בתמונות של צמתים ב-Ubuntu וב-Windows.

  • עומס העבודה ב-GKE צריך להשתמש בכל יחידות ה-GPU הזמינות, וה-Pod צריך להשתמש בכל כרטיסי ה-NIC המשניים הזמינים בצומת GKE יחיד. אי אפשר לשתף RDMA בין כמה Pods באותו צומת GKE.

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

  • ‫GPUDirect RDMA לא תואם ל-NCCL Fast Socket או ל-GPUDirect TCPX/TCPXO. אל תפעילו את NCCL Fast Socket ואל תתקינו את הפלאגין TCPX/TCPXO באשכולות שמשתמשים ב-GPUDirect RDMA.

שיקולים ליצירת אשכול

כשיוצרים אשכול, חשוב לקחת בחשבון את המידע הבא:

  • בוחרים מיקום של אשכול:
    • מוודאים שאתם משתמשים במיקום שבו יש זמינות לסוג המכונה שבחרתם. מידע נוסף זמין במאמר בנושא מיקומי GPU.
    • כדי להזמין כמות גדולה של מכונות, אפשר ליצור אשכול אזורי. במקרה כזה, מחליפים את הדגל --region בדגל --zone=COMPUTE_ZONE, כאשר COMPUTE_ZONE הוא התחום של מישור הבקרה.
    • כשיוצרים מאגרי צמתים באשכול אזורי, אפשר להשתמש בדגל --node-locations כדי לציין את האזורים לצמתים של GKE.
  • בוחרים גרסת מנהל התקן:
    • גרסת הדרייבר יכולה להיות אחת מהאפשרויות הבאות:
      • default: התקנת גרסת ברירת המחדל של הדרייבר לגרסת הצומת של GKE. מידע נוסף על הדרישות לגבי גרסאות ברירת מחדל של מנהלי התקנים זמין בקטע דרישות.
      • latest: התקנת הגרסה האחרונה של מנהל ההתקן שזמינה לגרסת GKE שלכם. האפשרות הזו זמינה רק לצמתים שמשתמשים במערכת הפעלה שמותאמת לקונטיינרים.
      • disabled: דילוג על התקנה אוטומטית של מנהל התקן. צריך להתקין מנהל התקן באופן ידני אחרי שיוצרים את מאגר הצמתים.
    • מידע נוסף על גרסאות ברירת המחדל והגרסאות האחרונות של מנהלי ההתקנים (דרייברים) של GPU עבור גרסאות של צומתי GKE זמין בטבלה שבקטע התקנה ידנית של מנהלי התקנים של NVIDIA GPU.
  • בחירת שיוך להזמנה:

    • תוכלו למצוא מידע על ההזמנה, כמו שם ההזמנה או שם של בלוק ספציפי בהזמנה. כדי לראות את הערכים האלה, אפשר לעיין במאמר בנושא הצגת בקשות לשמירת מקום לעתיד.
    • הדגל --reservation-affinity יכול לקבל את הערכים specific או any. עם זאת, כדי להשיג ביצועים גבוהים בעומסי עבודה מבוזרים של AI, מומלץ להשתמש בהזמנה ספציפית.
    • כשמשתמשים בהזמנה ספציפית, כולל הזמנות משותפות, צריך לציין את הערך של הדגל --reservation בפורמט הבא:

      projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME
      

      מחליפים את הערכים הבאים:

      • PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
      • RESERVATION_NAME: השם של ההזמנה.
      • BLOCK_NAME: השם של בלוק ספציפי בהזמנה.

      כדי להשתמש בהזמנה של תת-בלוק ממוקד כך שמכונות וירטואליות יוצבו בתת-בלוק יחיד בתוך BLOCK_NAME, מוסיפים את המחרוזת הבאה לסוף הנתיב:

      /reservationSubBlocks/SUB_BLOCK_NAME
      

      מחליפים את SUB_BLOCK_NAME בשם של תת-הבלוק.

יצירת אשכול GKE שעבר אופטימיזציה ל-AI ומשתמש ב-A4X וב-GPUDirect RDMA

במקרים של עומסי עבודה מבוזרים של AI, לעיתים קרובות מקשרים בין כמה צמתים של GPU כדי שיפעלו כמחשב אחד. ‫A4X היא פלטפורמה בקנה מידה אקסאסקייל שמבוססת על ארכיטקטורת NVIDIA GB200 NVL72 בקנה מידה של מתלה. סוג המכונה הזה מאפשר התאמה לעומס (scaling) ושיתוף פעולה בין כמה יחידות GPU, ומספק חוויית ענן עם ביצועים גבוהים לעומסי עבודה של AI. מידע נוסף על ארכיטקטורת הרשת של A4X, כולל רוחב הפס של הרשת והסידור של כרטיסי ה-NIC, זמין במאמר בנושא סוגי מכונות A4X.

כדי ליצור את אשכולות GKE Standard עם A4X ועם GPUDirect RDMA, צריך לבצע את השלבים הבאים, שמתוארים בקטעים הבאים:

  1. יצירת רשתות VPC ותת-רשתות
  2. יצירת אשכול GKE עם רישות מרובה
  3. יצירת אובייקטים של רשת GKE
  4. יצירת מדיניות של עומס עבודה
  5. יצירת מאגר צמתים עם A4X
  6. התקנה של קובץ ה-RDMA הבינארי והגדרה של NCCL
  7. התקנת ה-CRD של NVIDIA Compute Domain והדרייבר של DRA

יצירת רשתות VPC ורשתות משנה

מכונות וירטואליות מסוג A4X כוללות את ההגדרה הבאה:

  • ארבעה מעבדי GPU מסוג NVIDIA B200 לכל מכונה וירטואלית שמחוברים באמצעות NVLink
  • שני מעבדי NVIDIA Grace מבוססי-Arm
  • ארבעה כרטיסי רשת (NIC) מסוג CX-7‏ במהירות 400 Gbps לרשת GPU-to-GPU
  • שני כרטיסי ממשק רשת (NIC) של Google Titanium‏ במהירות 200 Gbps לשירותים חיצוניים

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

אחד מממשקי הרשת של Google Titanium שמשויך למעבד משתמש ברשת שמוגדרת כברירת מחדל ב-GKE, כך שלא צריך ליצור VPC חדש לממשק הרשת הזה, כל עוד יש מספיק טווחי כתובות IP לרשת שמוגדרת כברירת מחדל.

אפשר ליצור VPC אחד עבור כרטיס הרשת השני של Titanium (gVNIC) ו-VPC נוסף עבור ארבעת כרטיסי הרשת של CX-7 RDMA באמצעות הפקודות הבאות.

כדי למקסם את רוחב הפס של הרשת, הפקודה ליצירת VPC עבור קבוצות ה-GVNIC הנוספות מגדירה את יחידת השידור המקסימלית (MTU) ל-8896. ערך ברירת המחדל של RDMA VPC הוא 8896, שהוא הערך המומלץ. מידע נוסף זמין במאמר הגדרות MTU וסוגי מכונות GPU.

  1. מגדירים משתני סביבה בהתאם לפריסה:

    export REGION="COMPUTE_REGION"
    export ZONE="COMPUTE_ZONE"
    export PROJECT="PROJECT_ID"
    export GVNIC_NETWORK_PREFIX="GVNIC_NETWORK_PREFIX"
    export RDMA_NETWORK_PREFIX="RDMA_NETWORK_PREFIX"
    

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

    • COMPUTE_REGION: האזור של האשכול.
    • COMPUTE_ZONE: האזור של מאגר הצמתים.
    • PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
    • GVNIC_NETWORK_PREFIX: קידומת הרשת של GVNIC (לדוגמה, a4x-gvnic).
    • RDMA_NETWORK_PREFIX: הקידומת של רשת RDMA (לדוגמה, a4x-rdma).
  2. יוצרים שתי רשתות VPC:

    # Create a VPC for the additional GVNIC
    gcloud compute --project=${PROJECT} \
      networks create \
      GVNIC_NETWORK_PREFIX-net \
      --subnet-mode=custom \
      --mtu=8896
    
    gcloud compute --project=${PROJECT} \
      networks subnets create \
      GVNIC_NETWORK_PREFIX-sub \
      --network=GVNIC_NETWORK_PREFIX-net \
      --region=${REGION} \
      --range=192.168.0.0/24
    
    gcloud compute --project=${PROJECT} \
      firewall-rules create \
      GVNIC_NETWORK_PREFIX-internal \
      --network=GVNIC_NETWORK_PREFIX-net \
      --action=ALLOW \
      --rules=tcp:0-65535,udp:0-65535,icmp \
      --source-ranges=192.168.0.0/16
    
    # Create HPC VPC for the RDMA NICs with 4 subnets.
    gcloud compute --project=${PROJECT} \
      networks create RDMA_NETWORK_PREFIX-net \
      --network-profile=${ZONE}-vpc-roce \
      --subnet-mode=custom
    
    # Create subnets for the HPC VPC.
    for N in $(seq 0 3); do
      gcloud compute --project=${PROJECT} \
        networks subnets create \
        RDMA_NETWORK_PREFIX-sub-$N \
        --network=RDMA_NETWORK_PREFIX-net \
        --region=${REGION} \
        --range=192.168.$((N+1)).0/24 &  # offset to avoid overlap with gvnics
    done
    

יצירת אשכול GKE עם ריבוי רשתות

  1. יצירת אשכול GKE Standard עם רשתות מרובות:

    gcloud container clusters create CLUSTER_NAME \
        --enable-dataplane-v2 --enable-ip-alias --location=COMPUTE_REGION \
        --enable-multi-networking --cluster-version=CLUSTER_VERSION \
        --enable-kubernetes-unstable-apis=resource.k8s.io/v1beta1/deviceclasses,resource.k8s.io/v1beta1/resourceclaims,resource.k8s.io/v1beta1/resourceclaimtemplates,resource.k8s.io/v1beta1/resourceslices \
        [--services-ipv4-cidr=SERVICE_CIDR \
        --cluster-ipv4-cidr=POD_CIDR]
    

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

    • מסירים את הדגל --enable-kubernetes-unstable-apis, שמשמש להפעלת DRA, כשיוצרים אשכול שמריץ GKE בגרסה 1.34 ואילך. הדגל הזה נדרש רק כשיוצרים אשכול שמריץ גרסה 1.32 או 1.33. כשמפעילים ממשק API בגרסת בטא, צריך בסופו של דבר לעבור מממשק ה-API בגרסת הבטא כשממשק ה-API הזה יוצא משימוש ומוסר בגרסאות משניות מאוחרות יותר של Kubernetes. מידע נוסף מופיע במאמר הוצאה משימוש של ממשקי API בגרסת בטא.
    • מחליפים את מה שכתוב בשדות הבאים:

      • CLUSTER_NAME: השם של האשכול.
      • CLUSTER_VERSION: הגרסה של האשכול החדש. מידע נוסף על הגרסה של GKE שתומכת בהגדרה שלכם מופיע בקטע דרישות במסמך הזה.
      • COMPUTE_REGION: השם של אזור ה-Compute.
    • אופציונלי: אפשר לציין במפורש את טווחי ה-CIDR המשניים לשירותים ול-Pods. אם משתמשים בדגלים האופציונליים האלה, צריך להחליף את המשתנים הבאים:

      • SERVICE_CIDR: טווח ה-CIDR המשני לשירותים.
      • POD_CIDR: טווח ה-CIDR המשני של ה-Pods.

      כשמשתמשים בדגלים האלה, צריך לוודא שטווח ה-CIDR לא חופף לטווח של רשתות משנה ברשתות צמתים נוספות. לדוגמה, נניח שיש שני משתמשים, SERVICE_CIDR=10.65.0.0/19 ו-POD_CIDR=10.64.0.0/19. מידע נוסף מופיע במאמר בנושא הוספת טווחי כתובות IPv4 של Pod.

  2. כדי להריץ את הפקודות kubectl בקטעים הבאים, צריך להתחבר לאשכול:

    gcloud container clusters get-credentials CLUSTER_NAME --location=COMPUTE_REGION
    

    מחליפים את מה שכתוב בשדות הבאים:

    • CLUSTER_NAME: השם של האשכול.
    • COMPUTE_REGION: השם של אזור ה-Compute.

    מידע נוסף מופיע במאמר התקנה של kubectl והגדרת גישה לאשכול.

יצירת אובייקטים של רשת GKE

צריך להגדיר את רשתות ה-VPC שנוצרו בקטע הקודם באמצעות קבוצות של פרמטרים של רשת GKE. ספציפית, צריך להגדיר את ה-CPU השני, כרטיס ה-NIC של Titanium ‏ (gVNIC), במצב NetDevice, ואת כל אחד מארבעת כרטיסי ה-NIC של CX-7 RDMA במצב RDMA.

הפקודה הזו משתמשת בשמות הבאים:

  • רשת ה-VPC של כרטיס ה-NIC של Titanium CPU‏ (gVNIC) נקראת GVNIC_NETWORK_PREFIX-net ורשת המשנה נקראת GVNIC_NETWORK_PREFIX-sub
  • רשת ה-VPC של כרטיסי ה-NIC מסוג CX-7 RDMA נקראת RDMA_NETWORK_PREFIX-net ותת-הרשתות נקראות RDMA_NETWORK_PREFIX-sub-[0…3]

כדי ליצור את אובייקטי הרשת של GKE, מריצים את הפקודה הבאה:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: gvnic-1
spec:
  vpc: GVNIC_NETWORK_PREFIX-net
  vpcSubnet: GVNIC_NETWORK_PREFIX-sub
  deviceMode: NetDevice
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: gvnic-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: gvnic-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-0
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-0
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-0
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-0
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-1
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-1
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-1
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-1
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-2
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-2
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-2
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-2
---
apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
metadata:
  name: rdma-3
spec:
  vpc: RDMA_NETWORK_PREFIX-net
  vpcSubnet: RDMA_NETWORK_PREFIX-sub-3
  deviceMode: RDMA
---
apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: rdma-3
spec:
  type: "Device"
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: rdma-3
EOF

יצירת מדיניות של עומס עבודה

כדי ליצור מחיצה, צריך מדיניות של עומס עבודה. מידע נוסף זמין במאמר בנושא מדיניות עומסי עבודה עבור קבוצות של מכונות מנוהלות (MIG).

יוצרים מדיניות של עומס עבודה עם השדה accelerator_topology שמוגדר לערך 1x72.HIGH_THROUGHPUT

gcloud beta compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type HIGH_THROUGHPUT \
    --accelerator-topology 1x72 \
    --project PROJECT \
    --region COMPUTE_REGION

מחליפים את מה שכתוב בשדות הבאים:

  • WORKLOAD_POLICY_NAME: השם של מדיניות עומס העבודה.
  • PROJECT: שם הפרויקט.
  • COMPUTE_REGION: השם של אזור ה-Compute.

יצירת מאגר צמתים באמצעות A4X

מומלץ ליצור מאגר צמתים שמשתמש בפלאגין של מכשיר ה-GPU של GKE. התוסף הזה מספק ניהול של משאבי GPU שמנוהלים על ידי GKE. היתרונות של הגישה הזו:

  • קלות הפריסה והשדרוגים
  • התקנה אוטומטית של מנהלי התקנים
  • תכונות של יחידות GPU שמנוהלות על ידי GKE, כמו מדדים ויחידות GPU מחולקות
  • תיקונים חיוניים של נקודות חולשה באבטחה

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

יצירת מאגר צמתים A4X באמצעות תוסף מכשיר ה-GPU של GKE

יוצרים מאגר צמתים מסוג A4X שמשתמש בתוסף המכשיר GPU של GKE:

gcloud container node-pools create NODE_POOL_NAME \
    --location COMPUTE_REGION \
    --node-locations COMPUTE_ZONE \
    --cluster CLUSTER_NAME \
    --num-nodes=NODE_COUNT \
    --machine-type MACHINE_TYPE \
    --accelerator type=nvidia-gb200,count=4,gpu-driver-version=DRIVER_VERSION \
    --additional-node-network network=GVNIC_NETWORK_PREFIX-net,subnetwork=GVNIC_NETWORK_PREFIX-sub \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-0 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-1 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-2 \
    --additional-node-network network=RDMA_NETWORK_PREFIX-net,subnetwork=RDMA_NETWORK_PREFIX-sub-3 \
    --scopes "https://www.googleapis.com/auth/cloud-platform" \
    --reservation-affinity=specific \
    --reservation=RESERVATION_NAME/reservationBlocks/BLOCK_NAME \
    --placement-policy=WORKLOAD_POLICY_NAME

מחליפים את מה שכתוב בשדות הבאים:

  • NODE_POOL_NAME: שם מאגר הצמתים.
  • COMPUTE_REGION: האזור של האשכול.
  • COMPUTE_ZONE: האזור של מאגר הצמתים.
  • CLUSTER_NAME: השם של האשכול.
  • NODE_COUNT: מספר הצמתים במאגר הצמתים, שחייב להיות 18 צמתים או פחות. מומלץ להשתמש ב-18 צמתים כדי לקבל את טופולוגיית ה-GPU של 1x72 בתת-בלוק אחד באמצעות דומיין NVLink.
  • MACHINE_TYPE: a4x-highgpu-4g או ‫a4x-highgpu-4g-nolssd, בהתאם לרצון להשתמש ב-SSD מקומי.
  • DRIVER_VERSION: גרסת הדרייבר של NVIDIA להתקנה. אפשר להשתמש באחד מהערכים הבאים: default, latest או disabled.
  • RESERVATION_NAME: השם של ההזמנה. כדי למצוא את הערך הזה, אפשר לעיין במאמר בנושא הצגת מקום שמור לעתיד.
  • BLOCK_NAME: השם של בלוק ספציפי בהזמנה. כדי למצוא את הערך הזה, אפשר לעיין במאמר בנושא הצגת מקום שמור לעתיד.
  • WORKLOAD_POLICY_NAME: השם של מדיניות העומס שיצרתם קודם.

יצירת מאגר צמתים A4X באמצעות NVIDIA GPU Operator

לחלופין, כדי להשתמש באופרטור NVIDIA GPU, מבצעים את השלבים הבאים:

  1. מריצים את הפקודה gcloud container node-pools create מהקטע הקודם עם השינויים הבאים:

    • שינוי של gpu-driver-version=latest ל-gpu-driver-version=disabled. השינוי הזה מדלג על התקנה אוטומטית של מנהלי התקנים (דרייברים) של GPU כי היא לא נתמכת כשמשתמשים באופרטור NVIDIA GPU.
    • מגדירים את --node-labels="gke-no-default-nvidia-gpu-device-plugin=true" כדי להשבית את Daemonset של פלאגין מכשיר ה-GPU המנוהל ב-GKE.
  2. מחילים את מניפסט ה-DaemonSet של מנהל ההתקנה של דרייבר ה-GPU ב-GKE. קובץ המניפסט הזה פורס Pod להתקנת מנהל התקן של GPU בכל צומת A4X:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml
    
  3. ניהול מחסנית ה-GPU באמצעות NVIDIA GPU Operator ב-Google Kubernetes Engine‏ (GKE):

    1. בקטע יצירה והגדרה של מאגר צמתים של GPU, פועלים לפי ההוראות החל מהשלב של קבלת פרטי אימות.
    2. מתקינים את NVIDIA GPU Operator. צריך להשלים את כל השלבים, אבל להחליף את הפקודה בקטע שאליו מפנים, שמתקינה את NVIDIA GPU Operator באמצעות Helm. במקום זאת, משתמשים בפקודה הבאה:

      helm install --wait --generate-name \
        -n gpu-operator \
        nvidia/gpu-operator \
        --version="25.3.0" \
        -f <(cat <<EOF
      hostPaths:
        driverInstallDir: /home/kubernetes/bin/nvidia
      toolkit:
        installDir: /home/kubernetes/bin/nvidia
      cdi:
        enabled: true
        default: true
      driver:
        enabled: false
      
      daemonsets:
        tolerations:
          - key: nvidia.com/gpu
            operator: Equal
            value: present
            effect: NoSchedule
          - key: kubernetes.io/arch
            operator: Equal
            value: arm64
            effect: NoSchedule
      
      node-feature-discovery:
        worker:
          tolerations:
            - key: kubernetes.io/arch
              operator: Equal
              value: arm64
              effect: NoSchedule
            - key: "node-role.kubernetes.io/master"
              operator: "Equal"
              value: ""
              effect: "NoSchedule"
            - key: "node-role.kubernetes.io/control-plane"
              operator: "Equal"
              value: ""
              effect: "NoSchedule"
            - key: nvidia.com/gpu
              operator: Exists
              effect: NoSchedule
      EOF
      )
      

התקנה של קובץ הבינארי RDMA והגדרה של NCCL

מחילים את DaemonSet הבא כדי להתקין את הקבצים הבינאריים של RDMA ואת ספריית NCCL בכל צומת. בכל מכונה וירטואלית בסיסית, קובצי ה-RDMA הבינאריים מותקנים בספרייה /home/kubernetes/bin/gib, וספריית ה-NCCL מותקנת בספרייה /home/kubernetes/bin/nvidia/lib64.

  kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/gpudirect-rdma/nccl-rdma-installer-a4x.yaml

התקנה של NVIDIA Compute Domain CRD ושל דרייבר DRA

בשלבים הבאים מוסבר איך להתקין את ה-CRD של NVIDIA Compute Domain ואת הדרייבר של DRA כדי להשתמש ב-MNNVL. מידע נוסף זמין במאמר בנושא NVIDIA DRA Driver for GPUs.

  1. מוודאים ש-Helm מותקן בסביבת הפיתוח. ‫Helm מותקן מראש ב-Cloud Shell.

    אין דרישה ספציפית לגרסת Helm, אבל אפשר להשתמש בפקודה הבאה כדי לוודא ש-Helm מותקן.

    helm version
    

    אם הפלט דומה ל-Command helm not found, אפשר להתקין את Helm CLI באמצעות הפקודה הבאה:

    curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 \
      && chmod 700 get_helm.sh \
      && ./get_helm.sh
    
  2. מוסיפים את מאגר NVIDIA Helm:

    helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
      && helm repo update
    
  3. יוצרים ResourceQuota עבור מנהל ההתקן של DRA:

    export POD_QUOTA=POD_QUOTA
    
    kubectl create ns nvidia-dra-driver-gpu
    
    kubectl apply -n nvidia-dra-driver-gpu -f - << EOF
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: nvidia-dra-driver-gpu-quota
    spec:
      hard:
        pods: ${POD_QUOTA}
      scopeSelector:
        matchExpressions:
        - operator: In
          scopeName: PriorityClass
          values:
            - system-node-critical
            - system-cluster-critical
    EOF
    

    מחליפים את POD_QUOTA במספר שהוא לפחות פי 2 ממספר הצמתים של A4X באשכול ועוד 1. לדוגמה, אם יש לכם 18 צמתים מסוג A4X באשכול, אתם צריכים להגדיר את המשתנה ל-37 לפחות.

  4. מתקינים את מנהל ההתקן של DRA:

    helm install nvidia-dra-driver-gpu nvidia/nvidia-dra-driver-gpu \
        --version="DRA_DRIVER_VERSION" \
        --create-namespace \
        --namespace nvidia-dra-driver-gpu \
        -f <(cat <<EOF
    nvidiaDriverRoot: /home/kubernetes/bin/nvidia
    resources:
      gpus:
        enabled: false
    
    controller:
      affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: "nvidia.com/gpu"
                  operator: "DoesNotExist"
    
    kubeletPlugin:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: cloud.google.com/gke-accelerator
                    operator: In
                    values:
                      - nvidia-gb200
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                      - arm64
    
      tolerations:
        - key: nvidia.com/gpu
          operator: Equal
          value: present
          effect: NoSchedule
        - key: kubernetes.io/arch
          operator: Equal
          value: arm64
          effect: NoSchedule
    EOF
    )
    

    מחליפים את DRA_DRIVER_VERSION בגרסה 25.3.1 או בגרסה חדשה יותר. כדי לראות רשימה של גרסאות הדרייבר של NVIDIA DRA שזמינות, מריצים את הפקודה helm search repo nvidia/nvidia-dra-driver-gpu --versions. אפשר גם לעיין בנתוני הגרסה ב-GitHub כדי למצוא גרסה זמינה.

הגדרת מניפסט של עומס עבודה לריבוי רשתות, ל-RDMA ולדומיין IMEX

  1. מוסיפים את ההערות הבאות למטא-נתונים של ה-Pod:

    metadata:
      annotations:
        networking.gke.io/default-interface: 'eth0'
        networking.gke.io/interfaces: |
          [
            {"interfaceName":"eth0","network":"default"},
            {"interfaceName":"eth2","network":"rdma-0"},
            {"interfaceName":"eth3","network":"rdma-1"},
            {"interfaceName":"eth4","network":"rdma-2"},
            {"interfaceName":"eth5","network":"rdma-3"}
          ]
    
  2. מוסיפים כלל של שיוך צומת כדי לתזמן בצמתי Arm:

    spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - arm64
    

    מידע נוסף זמין במאמר בנושא תזמון עומס עבודה לארכיטקטורה אחת.

  3. מוסיפים את אמצעי האחסון הבאים למפרט של ה-Pod:

    spec:
    volumes:
      - name: library-dir-host
        hostPath:
          path: /home/kubernetes/bin/nvidia
      - name: gib
        hostPath:
          path: /home/kubernetes/bin/gib
    
  4. מוסיפים את המשאב, משתנה הסביבה והרכיבים הבאים של נפח האחסון לקונטיינר שמבקש מעבדי GPU. קונטיינר עומס העבודה צריך לבקש את כל ארבעת המעבדים הגרפיים:

    containers:
    - name: my-container
      volumeMounts:
        - name: library-dir-host
          mountPath: /usr/local/nvidia
        - name: gib
       mountPath: /usr/local/gib
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64:/usr/local/gib/lib64
      resources:
        limits:
          nvidia.com/gpu: 4
    
  5. יוצרים את משאב ComputeDomain לעומס העבודה:

    apiVersion: resource.nvidia.com/v1beta1
    kind: ComputeDomain
    metadata:
      name: a4x-compute-domain
    spec:
      numNodes: NUM_NODES
      channel:
        resourceClaimTemplate:
          name: a4x-compute-domain-channel
    

    מחליפים את NUM_NODES במספר הצמתים שנדרשים לעומס העבודה.

  6. מציינים את ResourceClaimTemplate שבו ה-Pod ישתמש:

    spec:
      ...
      volumes:
        ...
      containers:
        - name: my-container
          ...
          resources:
            limits:
              nvidia.com/gpu: 4
      claims:
              - name: compute-domain-channel
            ...
    resourceClaims:
      - name: compute-domain-channel
        resourceClaimTemplateName: a4x-compute-domain-channel
    
  7. מגדירים את כל משתני הסביבה הנדרשים כדי להגדיר את NCCL. משתמשים בסקריפט מעטפת הבא מהקונטיינר של עומס העבודה:

    source /usr/local/gib/scripts/set_nccl_env.sh
    

מפרט Pod מלא נראה כך:

apiVersion: resource.nvidia.com/v1beta1
kind: ComputeDomain
metadata:
  name: a4x-compute-domain
spec:
  numNodes: NUM_NODES
  channel:
    resourceClaimTemplate:
      name: a4x-compute-domain-channel
---
apiVersion: apps/v1
kind: Pod
metadata:
  name: my-pod
  labels:
    k8s-app: my-pod
  annotations:
    networking.gke.io/default-interface: 'eth0'
    networking.gke.io/interfaces: |
      [
        {"interfaceName":"eth0","network":"default"},
        {"interfaceName":"eth2","network":"rdma-0"},
        {"interfaceName":"eth3","network":"rdma-1"},
        {"interfaceName":"eth4","network":"rdma-2"},
        {"interfaceName":"eth5","network":"rdma-3"},
      ]
spec:
  ...
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/arch
            operator: In
            values:
            - arm64
  volumes:
    - name: library-dir-host
      hostPath:
        path: /home/kubernetes/bin/nvidia
    - name: gib
      hostPath:
        path: /home/kubernetes/bin/gib
  containers:
    - name: my-container
      volumeMounts:
        - name: library-dir-host
          mountPath: /usr/local/nvidia
        - name: gib
       mountPath: /usr/local/gib
      env:
        - name: LD_LIBRARY_PATH
          value: /usr/local/nvidia/lib64:/usr/local/gib/lib64
      resources:
        limits:
          nvidia.com/gpu: 4
        claims:
          - name: compute-domain-channel
        ...
resourceClaims:
  - name: compute-domain-channel
    resourceClaimTemplateName: a4x-compute-domain-channel

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

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

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