פתרון בעיות שקשורות ל-GPU ב-GKE

אם הפודים שלכם ב-Google Kubernetes Engine‏ (GKE) נתקעים במצב Pending בזמן בקשת משאבי nvidia.com/gpu, או אם הצמתים לא מצליחים לרשום את יחידות ה-GPU הזמינות שלהם, יכול להיות שיש בעיה בהתקנה של מנהל ההתקנים (דרייבר) של NVIDIA או בהגדרת מאגר הצמתים. הבעיות האלה מונעות מעומסי העבודה שלכם לגשת לחומרת ה-GPU שהם צריכים.

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

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

התקנת דרייבר של GPU

בקטע הזה מופיע מידע על פתרון בעיות שקשורות להתקנה אוטומטית של מנהלי התקנים של מכשירי NVIDIA ב-GKE.

התקנת מנהל ההתקן נכשלת בצמתי Ubuntu

אם אתם משתמשים בצמתי Ubuntu עם GPU מסוג L4,‏ RTX PRO 6000,‏ H100 או H200 שמחוברים אליהם, יכול להיות שמנהל התקן ה-GPU שמוגדר כברירת מחדל ומוגדר על ידי GKE לא יהיה בגרסה הנדרשת או בגרסה חדשה יותר. כתוצאה מכך, ה-Pod של תוסף מכשיר ה-GPU נשאר תקוע במצב Pending (בהמתנה), ויכול להיות שיהיו בעיות בעומסי העבודה של ה-GPU בצמתים האלה.

כדי לפתור את הבעיה, צריך לפעול לפי ההוראות שמתאימות ל-GPU:

L4 ו-H100

כדי לפתור את הבעיה ב-GPU מסוג L4 ו-H100, מומלץ לשדרג לגרסאות GKE הבאות שמתקינות את דרייבר ה-GPU בגרסה 535 כדרייבר ברירת המחדל:

  • ‫1.26.15-gke.1483000 ואילך
  • ‫1.27.15-gke.1039000 ואילך
  • ‫1.28.11-gke.1044000 ואילך
  • ‫1.29.6-gke.1073000 ואילך
  • ‫1.30.2-gke.1124000 ואילך

אפשר גם להתקין ידנית את מנהל ההתקן בגרסה 535 ואילך באמצעות הפקודה הבאה:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R535.yaml

RTX PRO 6000

כדי לפתור את הבעיה הזו במעבדי RTX PRO 6000 GPU, צריך לשדרג לאחת מגרסאות GKE הבאות. בגרסאות האלה מותקנת גרסת הדרייבר של ה-GPU‏ 580 כדרייבר ברירת המחדל:

  • ‫1.32.8-gke.1170000 ואילך
  • ‫1.33.4-gke.1245000 ואילך
  • ‫1.34.0-gke.1662000 ואילך

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

H200

כדי לפתור את הבעיה ב-GPU מדגם H200, צריך להתקין באופן ידני את מנהל ההתקן בגרסה 550 ואילך באמצעות הפעלת הפקודה הבאה:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/ubuntu/daemonset-preloaded-R550.yaml

תוספי מכשירי GPU נכשלים עם שגיאות CrashLoopBackOff

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

הקונטיינר של הפלאגין של מכשיר ה-GPU נכשל עם הסטטוס Init:CrashLoopBackOff. היומנים של הקונטיינר אמורים להיראות כך:

failed to verify installation: failed to verify GPU driver installation: exit status 18

כדי לפתור את הבעיה, אפשר לנסות את השיטות הבאות:

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

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

  • מחילים מחדש את מניפסט ה-DaemonSet של התקנת מנהל ההתקן הידנית על האשכול. ב-25 בינואר 2023 עדכנו את קובץ המניפסט כך שיתעלם מצמתים שמשתמשים בהתקנה אוטומטית של מנהלי התקנים.

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nvidia-driver-installer/cos/daemonset-preloaded.yaml

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

    gcloud container node-pools update POOL_NAME \
    --accelerator=type=GPU_TYPE,count=GPU_COUNT,gpu-driver-version=disabled \
    --cluster=CLUSTER_NAME \
    --location=LOCATION

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

    • ‫POOL_NAME: שם מאגר הצמתים.
    • ‫GPU_TYPE: סוג ה-GPU שמאגר הצמתים כבר משתמש בו.
    • ‫GPU_COUNT: מספר המעבדים הגרפיים שכבר מצורפים למאגר הצמתים.
    • ‫CLUSTER_NAME: השם של אשכול GKE שמכיל את מאגר הצמתים.
    • ‫LOCATION: המיקום של האשכול ב-Compute Engine.

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

שגיאה: 'קובץ אימג' של קונטיינר cos-nvidia-installer:fixed לא קיים עם מדיניות משיכה של Never' או 'קובץ אימג' של קונטיינר ubuntu-nvidia-installer:fixed לא קיים עם מדיניות משיכה של Never'.

הבעיה הזו מתרחשת כש-Pods של nvidia-driver-installer נמצאים במצב PodInitializing, וכשמכשיר הפלאגין של ה-GPU או ה-Pods של תוכנת ההתקנה של מנהל ההתקן של ה-GPU מדווחים על השגיאה הבאה. הודעת השגיאה הספציפית תלויה במערכת ההפעלה שפועלת בצומת:

COS

Container image "cos-nvidia-installer:fixed" is not present with pull policy of Never.

Ubuntu

Container image "gke-nvidia-installer:fixed" is not present with pull policy of Never.

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

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

  • ‫1.25.15-gke.1040000 ואילך
  • ‫1.26.10-gke.1030000 ואילך
  • ‫1.27.6-gke.1513000 ואילך
  • ‫1.28.3-gke.1061000 ואילך

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

אם הצמתים שלכם מריצים Ubuntu, עדיין אין תיקון לבעיה הזו של איסוף נתונים מיותרים. כדי לפתור את הבעיה ב-Ubuntu, אפשר להריץ קונטיינר עם הרשאות מיוחדות שמתקשר עם המארח כדי לוודא שההגדרה של מנהלי ההתקנים (דרייברים) של NVIDIA GPU נכונה. כדי לעשות זאת, מריצים את הפקודה sudo /usr/local/bin/nvidia-container-first-boot מהצומת או מחילים את המניפסט הבא:

apiVersion: v1
kind: Pod
metadata:
  name: gke-nvidia-installer-fixup
spec:
  nodeSelector:
    cloud.google.com/gke-os-distribution: ubuntu
  hostPID: true
  containers:
  - name: installer
    image: ubuntu
    securityContext:
      privileged: true
    command:
      - nsenter
      - -at
      - '1'
      - --
      - sh
      - -c
      - "/usr/local/bin/nvidia-container-first-boot"
  restartPolicy: Never

סיבה פוטנציאלית נוספת לבעיה היא אובדן של תמונות הדרייבר של NVIDIA אחרי הפעלה מחדש של הצומת או תחזוקת המארח. הבעיה הזו יכולה להתרחש בצמתים סודיים או בצמתים עם GPU, שמשתמשים באחסון SSD מקומי זמני. במצב הזה, GKE טוען מראש את קובצי האימג' של הקונטיינר nvidia-installer-driver בצמתים ומעביר אותם מדיסק האתחול ל-SSD המקומי באתחול הראשון.

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

resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
log_id("cloudaudit.googleapis.com/system_event")

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

  • ‫1.27.13-gke.1166000 ואילך
  • ‫1.29.3-gke.1227000 ואילך
  • ‫1.28.8-gke.1171000 ואילך

שגיאה: הגדרת ספריות ההתקנה של מנהל ההתקן של ה-GPU נכשלה: יצירת שכבת-על של lib64 נכשלה: יצירת הספרייה ‎ /usr/local/nvidia/lib64 נכשלה: mkdir ‎ /usr/local/nvidia/lib64: לא מדובר בספרייה.

השגיאה הזו מופיעה מהקונטיינר של מתקין מנהל ההתקן של ה-GPU בתוך הפלאגין של מכשיר ה-GPU, כשההגדרה NCCL fastsocket מופעלת:

failed to configure GPU driver installation dirs: failed to create lib64 overlay: failed to create dir /usr/local/nvidia/lib64: mkdir /usr/local/nvidia/lib64: not a directory.

הבעיה הזו מתרחשת רק באשכולות ובצמתים שמופעלים בהם GKE 1.28 ו-GKE 1.29.

הבעיה נגרמת בגלל מרוץ תהליכים של NCCL fastsocket עם תוכנת ההתקנה של מנהל ההתקן של ה-GPU.

כדי לפתור את הבעיה, צריך לשדרג את גרסת GKE לאחת מהגרסאות הבאות:

  • ‫1.28.8-gke.1206000 ואילך
  • ‫1.29.3-gke.1344000 ואילך

מידע נוסף זמין בהערות הגרסה של GPUDirect-TCPXO.

שגיאה: לא ניתן לאחזר את המכשיר nvidia0: המכשיר nvidia0 לא נמצא.

השגיאה הבאה מציינת ש-XID 62 ו-RmInitAdapter נכשלו עבור GPU עם מינור 0:

Failed to get device for nvidia0: device nvidia0 not found.

בגרסה 525.105.17 של מנהל ההתקן של NVIDIA יש באג שעלול לגרום לשגיאות תקשורת (XID) ולמנוע אתחול תקין של ה-GPU, מה שמוביל לכשל באתחול ה-GPU.

כדי לפתור את הבעיה, צריך לשדרג את הדרייבר של NVIDIA לגרסה 525.110.11 או לגרסה חדשה יותר.

בעיות ב-GPUDirect RDMA

בקטע הזה מופיע מידע על פתרון בעיות שקשורות ל-GPUDirect RDMA.

שגיאה: לא נמצא פלאגין gIB לרשת

התמונה pytorch/pytorch:latest ממאגר PyTorch לא כוללת את Netlink Library Protocol Suite‏ (libnl), שנדרש לתוסף gIB. השגיאה הבאה מציינת שהתוסף gIB לא נטען כי libnl הספריות חסרות בתמונה:

ncclInvalidUsage: Error: network gIB not found.

כדי לפתור את הבעיה, צריך להשתמש בתמונת בסיס אחרת של Pytorch או להוסיף את הספריות למאגרי התמונות באופן ידני. הבעיה לא ספציפית לסוג מכונה מסוים. מידע נוסף על השימוש ב-NCCL/gIB זמין במאמר אופטימיזציה של רשתות אשכולות באמצעות NCCL/gIB.

פתרון הבעיה באמצעות תמונת Nvidia PyTorch

כדי לפתור את הבעיה הזו, אפשר להשתמש בתמונת NVIDIA PyTorch. כדי למצוא את הגרסה העדכנית, אפשר לעיין בהערות לגבי הגרסה של PyTorch.

פתרון הבעיה באמצעות התקנה ידנית

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

apt update -y && apt upgrade -y && apt install -y libnl-3-200 libnl-route-3-200

כדי לוודא שהספרייה IBVerbs עקבית בתוך מאגר עומסי העבודה, צריך להשתמש ב-DaemonSet המעודכן של NCCL RDMA Installer כדי להתקין את ספריות הפלאגין gIB בנתיב המאגר.

כדי להוריד את ההגדרה של DaemonSet, משכפלים את מאגר המאיצים של Container Engine:

cd
git clone https://github.com/GoogleCloudPlatform/container-engine-accelerators.git

מחפשים את ההגדרה בספרייה tree/master/gpudirect-rdma:

cd container-engine-accelerators/gpudirect-rdma
ls -l nccl-rdma-installer*
-rw-r----- 1 adelab primarygroup 2899 May  6 15:57 nccl-rdma-installer-a4x.yaml
-rw-r----- 1 adelab primarygroup 2743 Apr 30 00:34 nccl-rdma-installer-autopilot.yaml
-rw-r----- 1 adelab primarygroup 2677 May  6 15:57 nccl-rdma-installer.yaml

בוחרים אחת מהגדרות ההתקנה הבאות:

תיאור nccl-rdma-installer.yaml nccl-rdma-installer-a4x.yaml nccl-rdma-installer-autopilot.yaml
מצב הפעולה של GKE GKE Standard GKE Standard טייס אוטומטי של GKE
סוגי מכונות סוגי המכונות A4 ו-A3 Ultra סוג המכונה A4X סוגי המכונות A4 ו-A3 Ultra
מרחב שמות פריסה אל kube-system. פריסה אל kube-system. הפריסה מתבצעת למרחב שמות ייעודי של rdma-system (כי Autopilot מגביל את השינויים במרחב השמות של kube-system).
סיווג לפי עדיפות משתמש ב-system-node-critical כדי לוודא שהתוכנה להתקנה תפעל בעדיפות גבוהה. נעשה שימוש ב-system-node-critical. אין. (ב-Autopilot יש הגבלה על השימוש בסוגי עדיפות ברמת המערכת).
תפקיד הכלי פועל כ-DaemonSet ומתקין את הפלאגין GPUDirect-TCPX ‏ (GIB) NCCL (במיוחד nccl-plugin-gib:v1.1.1) בספריות המארח /home/kubernetes/bin/nvidia/lib64 ו-/home/kubernetes/bin/gib. הגישה הזו מאפשרת תקשורת RDMA עם ביצועים גבוהים עבור NCCL בצמתים של GKE. בדומה לתוכנת ההתקנה הבסיסית, אבל מתקינה את הגרסה של פלאגין GPUDirect-TCPX ‏ (GIB) NCCL (מספר nccl-plugin-gib-arm64:v1.1.0) שעברה קומפילציה ל-ARM64. כוללת גם זיקה ספציפית לצומת עבור nvidia-gb200 ו-arm64 כדי להבטיח שהיא תפעל רק בצמתי GKE הספציפיים האלה. התוסף GPUDirect-TCPX‏ (GIB) NCCL (nccl-plugin-gib:v1.1.1) מותקן, אבל עם שינויים שתומכים במודל האבטחה והתפעול של מצב Autopilot:
  • הפריסה מתבצעת במרחב השמות rdma-system.
  • סקריפט ההתקנה מופעל עם הדגל --install-nccl, שמבצע הגדרה נוספת כדי לוודא שספריית NCCL מוגדרת או מותקנת כראוי בסביבת Autopilot. ב-GKE Autopilot, סביבת המארח עשויה להיות מוגבלת יותר או מוגדרת מראש באופן שונה בהשוואה ל-GKE Standard.

מחילים את ה-daemonset:

kubectl apply -f nccl-rdma-installer.yaml

מיפוי של גרסת GKE וגרסת קובץ האימג' של צומת מערכת ההפעלה שמותאמת לקונטיינרים לגרסת מנהל ההתקן של GPU

כדי למצוא את גרסאות מנהלי ההתקנים של ה-GPU שממופות לגרסאות GKE ולגרסאות של קובצי אימג' של צמתים של מערכת הפעלה שמותאמת לקונטיינרים, מבצעים את השלבים הבאים:
  1. מיפוי של גרסאות של תמונות צמתים של מערכת הפעלה שמותאמת לקונטיינרים לגרסאות תיקון של GKE לגרסת GKE ספציפית שבה רוצים למצוא את גרסת הדרייבר של ה-GPU. לדוגמה, בגרסה 1.33.0-gke.1552000 נעשה שימוש ב-cos-121-18867-90-4.
  2. בוחרים את אבן הדרך של גרסת קובץ האימג' של הצומת של מערכת ההפעלה שמותאמת לקונטיינרים בהערות הגרסה של מערכת ההפעלה שמותאמת לקונטיינרים. לדוגמה, בוחרים באבן דרך 121 עבור cos-121-18867-90-4.
  3. בדף הערות הגרסה של אבן הדרך הספציפית, מחפשים את הערת הגרסה שמתאימה לגרסה הספציפית של תמונת הצומת של מערכת ההפעלה שמותאמת לקונטיינרים. לדוגמה, בהערות לגבי הגרסה של מערכת ההפעלה Container-Optimized: אבן דרך 121, אפשר לראות את cos-121-18867-90-4. בטבלה בעמודה GPU Drivers, לוחצים על See List כדי לראות את פרטי הגרסה של מנהל ההתקן של ה-GPU.

הפקודה nvidia-smi נכשלת

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

  • bash: nvidia-smi: command not found
  • שגיאות שמציינות שלא ניתן למצוא את libnvidia-ml.so או ספריות אחרות של NVIDIA.

‫GKE מטמיע את הדרייברים והכלים הנדרשים של NVIDIA מהמארח node בקונטיינרים, בדרך כלל בנתיב /usr/local/nvidia/. עם זאת, יכול להיות שמשתני הסביבה שמוגדרים כברירת מחדל בקונטיינר (PATH ו-LD_LIBRARY_PATH) לא יכללו את הנתיבים לקבצים הבינאריים ולספריות של NVIDIA.

כדי לפתור את השגיאות האלה, צריך לעדכן את קובץ המניפסט של ה-Pod או של הפריסה כדי לכלול את נתיבי NVIDIA הנדרשים במשתני הסביבה PATH ו-LD_LIBRARY_PATH של הקונטיינר.

לדוגמה, מוסיפים את הבלוק env הבא למפרט spec.template.spec.containers:

spec:
  containers:
  - name: gpu-container
    image: gpu-image
    env:
    - name: LD_LIBRARY_PATH
      # Prepend NVIDIA lib64 directory to existing LD_LIBRARY_PATH
      value: /usr/local/nvidia/lib64
    - name: PATH
      # Prepend NVIDIA bin directory to existing PATH
      value: /usr/local/nvidia/bin:$PATH
    # ... other container settings

הפעלה מחדש של מערכת ההפעלה האורחת באשכולות רגילים

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

יכול להיות שיהיה צורך להפעיל מחדש צומת GKE אם יש בו בעיות ב-Xid או בעיות אחרות ב-GPU. דוגמאות לבעיות שקשורות ל-Xid מפורטות במאמר בנושא טיפול ב-Xid ב-Compute Engine.

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

  • מערכת ההפעלה של האורח מאופסת.
  • יחידת ה-GPU מאופסת.
  • המופע הבסיסי לא משתנה ודיסק האתחול נשמר, אבל אחרי ההפעלה מחדש, מזהה האתחול שונה.

ההפעלה מחדש נמשכת כחמש דקות. הזמן הזה הוא בנוסף לתקופת החסד לסיום השימוש שהוגדרה ב-pods. פרטים נוספים על מחזור החיים של ה-Pod ועל תקופת הסיום זמינים במאמר סיום של Pods.

דרישות

כדי להשתמש בשיטה הזו להפעלה מחדש של מערכת ההפעלה האורחת, צריך להפעיל את האשכול ב-GKE בגרסה 1.35.5-gke.1023000 ואילך.

הפעלה מחדש של מערכת ההפעלה של האורח בצומת GKE

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

  1. מזהים את הצומת שרוצים להפעיל מחדש.

  2. מחילים את התווית cloud.google.com/perform-reboot=true באמצעות הפקודה הבאה:

    kubectl label nodes NODE_NAME cloud.google.com/perform-reboot=true

    מחליפים את NODE_NAME בשם הצומת.

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

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

  3. עוברים לאירועים של הצומת כדי לראות שהצומת הופעל מחדש בהצלחה.

    1. במסוף Google Cloud , עוברים אל Kubernetes Engine > Clusters.

      מעבר אל Clusters

    2. בוחרים את האשכול שמכיל את הצומת שמפעילים מחדש.

    3. לוחצים על Nodes (צמתים) ובוחרים את הצומת שמבצעים לו הפעלה מחדש.

    4. לוחצים על אירועים כדי להציג את דף האירועים של הצומת.

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

      • כשהצומת מופעל אחרי ההפעלה מחדש.
      • כשה-handler של התחזוקה מסיר את התווית של צומת perform-reboot.
      • כשמזוהה שינוי במזהה האתחול.

איפוס יחידות GPU במכונות וירטואליות מסוג A3 ו-A4

יכול להיות שתצטרכו לאפס את ה-GPU במכונה וירטואלית מסוג A3 או A4 כדי לפתור בעיות מסוימות.

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

כדי לאפס את ה-GPU באופן ידני:

  1. מסירים את ה-Pods שמבקשים משאבי GPU מהצומת שבו צריך לאפס את ה-GPU.

  2. משביתים את תוסף מכשיר ה-GPU בצומת:

    kubectl get nodes \
    --selector=kubernetes.io/hostname=NODE_NAME \
    --no-headers | awk '{print $1}' \
    | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=true

    מחליפים את NODE_NAME בשם הצומת.

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

    א. שימו לב לערך הנוכחי של התווית cloud.google.com/gke-gpu-driver-version בצומת.

    ב. כדי להוציא את ה-Pod של כלי הייצוא של DCGM, משנים את ערך התווית ל-reset:

      kubectl label node NODE_NAME \
      cloud.google.com/gke-gpu-driver-version=reset --overwrite

    ה-Pod מוצא אוטומטית מהמערכת כי הוא דורש שהתווית תהיה default או latest.

  4. מתחברים ל-VM שמגבה את הצומת.

  5. בסשן ה-SSH, מאפסים את ה-GPU:

    איפוס כל יחידות ה-GPU במכונה הווירטואלית

    /home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset

    כדי לאפס GPU ספציפי

    # Identify the faulty GPU
/home/kubernetes/bin/nvidia/bin/nvidia-smi

# Reset the specifc GPU using either the GPU index or PCI bus ID from above command output 
/home/kubernetes/bin/nvidia/bin/nvidia-smi --gpu-reset -i <gpu_id>

  6. כדי להפעיל מחדש את התוסף של מכשיר ה-GPU ואת כלי הייצוא DCGM, צריך לשחזר את תוויות הצומת:

    א. מפעילים מחדש את הפלאגין של מכשיר ה-GPU:

      kubectl get nodes --selector=kubernetes.io/hostname=NODE_NAME \
      --no-headers \| awk '{print $1}' \
      | xargs -I{} kubectl label node {} gke-no-default-nvidia-gpu-device-plugin=false \
      --overwrite

    ב. כדי להפעיל מחדש את הכלי DCGM exporter, צריך לשחזר את הערך המקורי של התווית cloud.google.com/gke-gpu-driver-version (לדוגמה, latest או default):

      kubectl label node NODE_NAME \
      cloud.google.com/gke-gpu-driver-version=ORIGINAL_VALUE --overwrite

יחידות GPU בצמתים של Confidential GKE

בקטעים הבאים מוסבר איך לזהות ולפתור בעיות ב-GPU שפועלים ב-Confidential GKE Nodes.

עומסי עבודה של GPU לא מתוזמנים בצמתים של Confidential GKE

כדי להשתמש ב-Confidential GKE Nodes, צריך להתקין ידנית דרייבר של GPU שמתאים לסוג ה-GPU שנבחר ולגרסת GKE. אם לא מתבצע תזמון של GPU Pods ב-Confidential GKE Nodes והם נשארים במצב Pending, צריך לתאר את ה-DaemonSet של התקנת מנהל ההתקן:

kubectl --namespace=kube-system get daemonset nvidia-driver-installer -o yaml

אם הפלט מחזיר שגיאה NotFound, צריך להתקין את מנהל ההתקן.

אם DaemonSet פועל, הפלט דומה לזה:

apiVersion: apps/v1
kind: DaemonSet
# lines omitted for clarity
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      k8s-app: nvidia-driver-installer
  template:
    metadata:
      creationTimestamp: null
      labels:
        k8s-app: nvidia-driver-installer
        name: nvidia-driver-installer
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: cloud.google.com/gke-accelerator
                operator: Exists
              - key: cloud.google.com/gke-gpu-driver-version
                operator: DoesNotExist
              - key: cloud.google.com/gke-confidential-nodes-instance-type
                operator: In
                values:
                - TDX

בפלט הזה, מוודאים שהשדה nodeAffinity מכיל את המפתח cloud.google.com/gke-confidential-nodes-instance-type. אם הפלט לא מכיל את המפתח הזה, ה-DaemonSet של התקנת מנהל ההתקן לא תומך בצמתים סודיים של GKE.

פורסים את DaemonSet שתומך ב-GPU בצמתים של Confidential GKE:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/refs/heads/master/nvidia-driver-installer/cos/daemonset-confidential.yaml

אחרי שמתקינים את הדרייברים, בודקים אם עומסי העבודה של ה-GPU מתחילים בהצלחה.

שגיאה: הקצאת וקטור המכשיר נכשלה

הודעת השגיאה הבאה ביומני מאגר ה-GPU מציינת שה-GPU נותק ממופע ה-VM של הצומת:

Failed to allocate device vector A (error code unknown error)!

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

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

  1. מקבלים את השם של הצומת שמריץ את ה-Pod של ה-GPU:

    kubectl get pod POD_NAME -o yaml | grep "nodeName"

    מחליפים את POD_NAME בשם של ה-Pod שנכשל.

    הפלט אמור להיראות כך:

    nodeName: gke-cluster-1-default-pool-b7asdfbt-fd3e

  2. מאפסים את המכונה של Compute Engine:

    gcloud compute instances reset NODE_NAME

    מחליפים את NODE_NAME בשם הצומת מהפלט של השלב הקודם.

    ה-CLI של gcloud מחפש מכונות וירטואליות עם השם הזה בפרויקט הפעיל. אם מוצגת בקשה לבחור אזור, מציינים Y.

  3. בודקים אם עומסי העבודה של ה-GPU פועלים ללא שגיאות.

שגיאה: הפענוח נכשל עם השגיאה ‎-74

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

Decryption failed with error -74

השגיאה הזו מתרחשת כשהדמון של NVIDIA Persistence, שפועל במופע של מכונת ה-VM של הצומת, נכשל. אם מופיעה הודעת השגיאה הזו, צריך לאפס את המופע:

gcloud compute instances reset NODE_NAME

מחליפים את NODE_NAME בשם של הצומת שנכשל.

ה-CLI של gcloud מחפש מכונות וירטואליות עם השם הזה בפרויקט הפעיל. אם מוצגת בקשה לבחור אזור, מציינים Y.

אם איפוס המופע לא פותר את הבעיה, אפשר לפנות ל-Cloud Customer Care או לשלוח באג במוצר. מידע נוסף מופיע במאמר איך מקבלים תמיכה.

איתור שגיאות XID

ה-daemonset‏ gpu-device-plugin פועל במרחב השמות kube-system ואחראי על הפעולות הבאות:

  • תזמון עומסי עבודה ב-GPU: הקצאת משאבי GPU ל-Pods.
  • בדיקת תקינות של GPU: מעקב אחר התקינות של יחידות ה-GPU.
  • איסוף מדדים של GPU: איסוף מדדים שקשורים ל-GPU, כמו דיוטי סייקל (Duty cycle) ושימוש בזיכרון.

‫gpu-device-plugin משתמש בספריית הניהול של NVIDIA‏ (NVML) כדי לזהות שגיאות XID. כשמתרחשת שגיאת XID, השגיאה נרשמת ביומן של gpu-device-plugin Pod שפועל בצומת המושפע. יש שני סוגים של יומני שגיאות של XID:

  • שגיאות לא קריטיות של XID:
    • פורמט יומן: Skip error Xid=%d as it is not Xid Critical
    • משמעות: השגיאות האלה לא נחשבות קריטיות. הן יכולות להיגרם מבעיות שונות בתוכנה או בחומרה.
    • פעולה: GKE לא מבצע פעולה אוטומטית לגבי שגיאות XID לא קריטיות.
  • שגיאות קריטיות ב-XID:
    • פורמט יומן: XidCriticalError: Xid=%d, All devices will go unhealthy
    • משמעות: השגיאות האלה מעידות על בעיה בחומרה של ה-GPU.
    • פעולה:
      • ‫GKE מסמן את משאבי ה-GPU של הצומת כלא תקינים.
      • ‫GKE מונע תזמון של עומסי עבודה של GPU בצומת.
      • אם התיקון האוטומטי של הצומת מופעל, GKE יוצר מחדש את הצומת.

בעיות ב-GPUDirect-TCPX(O)

בקטע הזה מפורט מידע על פתרון בעיות שקשורות ל-GPUDirect-TCPX(O). אם אתם משתמשים ב-GKE גרסה 1.34 ואילך, כדאי לעיין גם בדף בעיות ידועות ב-GKE.

נתוני גרסה והוראות שדרוג

למשתמשים חדשים, המאמר Maximize GPU network bandwidth in Standard mode clusters מספק הנחיות לשימוש ב-GPUDirect-TCPX(O). משתמשים קיימים יכולים לקרוא את הערות הגרסה של GPUDirect-TCPXO כדי לקבל מידע על הגרסה והוראות לשדרוג, כי אנחנו משיקים גרסאות חדשות באופן שוטף.

כשלים ב-tcpx-daemon וב-tcpxo-daemon אחרי שדרוג גרסת GKE

יכול להיות שתיתקלו בשגיאה הבאה אם הפודים של tcpx-daemon או tcpxo-daemon נכשלים:

cuda error detected! name: CUDA_ERROR_NO_DEVICE; string: no CUDA-capable device is detected

בנוסף, בודקים אם ה-Pods במרחב השמות kube-system נמצאים במצב CrashLoopBackOff או Error.device-injector

הבעיה הזו מתרחשת אם שדרגתם את מאגרי הצמתים של GKE לאחת מהגרסאות הבאות או לגרסאות מתקדמות יותר:

  • ‫GKE 1.31: ‏ 1.31.14-gke.1033000
  • ל-GKE 1.32: ‏ 1.32.9-gke.1575000
  • ‫GKE 1.33: ‏ 1.33.5-gke.1862000
  • ‫GKE 1.34: ‏ 1.34.1-gke.3225000
  • ל-GKE מגרסה 1.35 ואילך

הבעיה נגרמת כתוצאה משימוש בגרסה ישנה של מניפסט הכלי להוספת מכשירים ל-NRI, שכוללת initContainer בשם enable-nri. בגרסאות GKE המושפעות, ה-NRI מופעל כברירת מחדל בהגדרת הצומת. הקונטיינר enable-nri שיצא משימוש מנסה לשנות את ההגדרה ולהפעיל מחדש את זמן הריצה של הקונטיינר, וזה יוצר קונפליקט עם ברירות המחדל של המערכת וגורם לקריסת ה-Pods של nri-device-injector. הכשל הזה מונע ממכשירי GPU להיחשף למאגר tcpx-daemon או tcpxo-daemon.

כדי לפתור את הבעיה, צריך לעדכן את nri-device-injector DaemonSet לגרסה העדכנית ביותר, שבה הוסר initContainer שגורם להתנגשות.

  1. מוחקים את ה-DaemonSet הקיים:

    kubectl delete daemonset device-injector -n kube-system

  2. החלת המניפסט העדכני:

    kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/container-engine-accelerators/master/nri_device_injector/nri-device-injector.yaml

  3. מפעילים מחדש את ה-Pods של עומס העבודה.

ניפוי באגים באמצעות יומנים של NCCL

אם לא הצלחתם לפתור בעיה ב-NCCL, כדאי לאסוף יומנים של NCCL עם מידע על ניפוי באגים. היומנים האלה מכילים מידע חשוב על פעולות NCCL ויכולים לעזור לכם למצוא את מקור הבעיה. אם לא הצלחתם לפתור את הבעיה, עליכם לאסוף את היומנים האלה לפני שאתם פותחים פנייה לתמיכה של Cloud Customer Care. היומנים האלה יכולים לעזור ל-Cloud Customer Care לפתור את הבעיה שלכם מהר יותר.

כדי ליצור ולאסוף את היומנים, מבצעים את השלבים הבאים:

  1. מגדירים את משתני הסביבה הבאים בתוך ה-Pod או המניפסט של האפליקציה:

    NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,ENV,COLL,GRAPH
NCCL_DEBUG_FILE=/DIRECTORY/FILE_NAME.%h.%p

    מידע נוסף על משתני הסביבה האלה זמין במאמר בנושא איסוף יומני ניפוי באגים של NCCL.

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

  3. איסוף היומנים מכל הצמתים. מוודאים שאספתם יומני NCCL מכל הצמתים. לשם כך, בודקים שהיומנים מכילים את המידע הבא:

    • שמות המארחים של כל המכונות הווירטואליות שמשתתפות בעומס עבודה.
    • מזהי התהליך (PID) של כל התהליכים הרלוונטיים במכונת ה-VM.
    • הדירוגים של כל יחידות ה-GPU שמשמשות את עומס העבודה בכל מכונת VM.

    אם אתם לא בטוחים איפה נמצאים קובצי היומן, בדוגמה הבאה אפשר לראות איפה NCCL יוצר את קובצי היומן כשהמשתנה NCCL_DEBUG_FILE מוגדר ל-/tmp/nccl_log.%h.%p. יש לכם שתי מכונות וירטואליות בשם a3plus-vm-1 ו-a3plus-vm-2, וכל מכונה וירטואלית מפעילה שמונה תהליכים בקונטיינר של עומס העבודה. בתרחיש הזה, NCCL יוצר את קובצי היומן הבאים בספרייה /tmp בתוך קונטיינר עומס העבודה בכל מכונה וירטואלית:

    • ב-a3plus-vm-1: שמונה קובצי יומן בשם nccl_log.a3plus-vm-1.PID, כאשר PID הוא מזהה התהליך.
    • ב-a3plus-vm-2: שמונה קובצי יומן בשם nccl_log.a3plus-vm-2.PID.

  4. בודקים את היומנים. הרשומות ביומן NCCL הן בפורמט הבא:

    HOSTNAME:PID:TID [RANK] NCCL_MESSAGE

    רשומות היומן האלה מכילות את הערכים הבאים:

    • ‫HOSTNAME: שם המארח של המכונה הווירטואלית. הערך הזה מציין באיזו מכונה וירטואלית נעשה שימוש כש-NCCL יצר את רשומת היומן.
    • ‫PID: ה-PID. הערך הזה מזהה את התהליך שיצר את רשומת היומן.
    • ‫TID: מזהה השרשור. הערך הזה מזהה את השרשור בתהליך שהיה בשימוש כש-NCCL יצר את רשומת היומן.
    • ‫RANK: מזהה הדירוג המקומי. הערך הזה מציין באיזה GPU נעשה שימוש כש-NCCL יצר את הרשומה ביומן. הדירוגים ממוספרים מ-0 עד N, כאשר N הוא המספר הכולל של מעבדי ה-GPU שמשתתפים בתהליך. לדוגמה, אם עומס העבודה שלכם פועל עם שמונה מעבדי GPU לכל מכונה וירטואלית, לכל מכונה וירטואלית צריכים להיות שמונה ערכים שונים של דירוג (0-7).
    • NCCL_MESSAGE: הודעה תיאורית שמספקת מידע נוסף על האירוע וכוללת את חותמת הזמן של מועד יצירת היומן על ידי NCCL.

    לדוגמה:

    gke-a3plus-mega-np-2-aa33fe53-7wvq:1581:1634 [1] NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.

    בדוגמה הזו יש את הערכים הבאים:

    • ‫gke-a3plus-mega-np-2-aa33fe53-7wvq: שם המארח.
    • ‫1581: מזהה התהליך.
    • ‫1634: מזהה השרשור.
    • ‫1: מזהה הדירוג המקומי.
    • ‫NCCL INFO 00:09:24.631392: NET/FasTrak plugin initialized.: ההודעה שמסבירה מה קרה.

  5. אם פותחים בקשת תמיכה, צריך לארוז את היומנים שאספתם, יחד עם הפלט של בדיקת NCCL, בקובץ zip. צריך לצרף את קובץ ה-ZIP כששולחים בקשת תמיכה ל-Cloud Customer Care.

  6. כדי להפסיק את האיסוף של יומני ניפוי הבאגים של NCCL, מסירים את המשתנים שהוספתם בשלב 1.

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