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

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

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

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

התקנת דרייבר ל-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, צריך לשדרג לאחת מהגרסאות הבאות של GKE. בגרסאות האלה מותקן דרייבר GPU בגרסה 580 כדרייבר ברירת המחדל:

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

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

H200

כדי לפתור את הבעיה הזו במעבדי 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, אפשר להריץ קונטיינר עם הרשאות שמתקשר עם המארח כדי לוודא שההגדרה של מנהלי ההתקנים (דרייברים) של 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: not a directory.

השגיאה הזו מתרחשת מהקונטיינר של מתקין מנהל ההתקן (דרייבר) של ה-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.

שגיאה: לא נמצא הפלאגין Network 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. אין. (הטייס האוטומטי מגביל את השימוש בסוגי עדיפות ברמת המערכת).
תפקיד התוסף פועל כ-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. בדף הערות הגרסה של אבן הדרך הספציפית, מחפשים את הערת הגרסה שמתאימה לגרסה הספציפית של תמונת הצומת של מערכת ההפעלה שמותאמת לקונטיינרים. לדוגמה, בהערות לגבי גרסת מערכת ההפעלה שמותאמת לקונטיינרים: אבן דרך 121, אפשר לראות את cos-121-18867-90-4. בטבלה בעמודה GPU Drivers, לוחצים על See List כדי לראות את פרטי הגרסה של מנהל ההתקן של ה-GPU.

ב-GKE מגרסה 1.36.0-gke.3302004 ואילך, ‏ GKE מפרסם באופן אוטומטי את גרסת מנהל ההתקן של NVIDIA שהותקנה כהערות בצמתים של GPU שפועלים. כדי לראות את ההערות של גרסת הדרייבר בצומת GPU, מריצים את הפקודה הבאה:

kubectl get node GPU_NODE_NAME -o jsonpath='{.metadata.annotations}'

מחליפים את GPU_NODE_NAME בשם של צומת ה-GPU.

הפלט כולל הערות שדומות לאלה:

{
  "cloud.google.com/cuda.driver-version.full": "580.126.20",
  "cloud.google.com/cuda.driver-version.major": "580",
  "cloud.google.com/cuda.driver-version.minor": "126",
  "cloud.google.com/cuda.driver-version.revision": "20"
}

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

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

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

‫GKE מטמיע את הדרייברים והכלים הדרושים של NVIDIA מהמארח (host) של הצומת בקונטיינרים, בדרך כלל בנתיב /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

כדי להפעיל מחדש את מערכת ההפעלה של האורח בצומת 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. לוחצים על אירועים כדי להציג את דף האירועים של הצומת.

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

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

אם פעלתם לפי השלבים האלה בצומת שמופעלת בו גרסה מוקדמת יותר מ-1.35.5-gke.1023000, יכול להיות שהצומת ישמור גם את cloud.google.com/impending-node-termination ה-taint וגם את התווית cloud.google.com/perform-reboot=true אחרי שההפעלה מחדש תסתיים. לצומת יש סטטוס Ready אבל אי אפשר להריץ בו עומסי עבודה. כדי לפתור את הבעיה, צריך לשדרג ל-GKE גרסה ‎1.35.5-gke.1023000 ואילך. כדי לצמצם את הבעיה הזו בלי לשדרג, מסירים ידנית את הכתם והתווית מהצומת המושפע על ידי הפעלת הפקודות הבאות:

# Remove the perform-reboot label
kubectl label node NODE_NAME cloud.google.com/perform-reboot-

# Remove the boot ID annotation (might report "not found", which is expected)
kubectl annotate node NODE_NAME node.gke.io/reboot-boot-id-

# Remove the taint (might already be removed automatically, which is expected)
kubectl taint nodes NODE_NAME cloud.google.com/impending-node-termination:NoSchedule-

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

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

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

בכל גרסאות GKE, אם מפעילים מחדש את התווית cloud.google.com/perform-reboot=true תוך 60 שניות מסיום האתחול מחדש, יכול להיות שמטפל התחזוקה לא יפעל על התווית החדשה בגלל מרוץ תהליכים במצב הפנימי שלו. הצומת נשאר תקוע עם התווית perform-reboot והדחייה cloud.google.com/impending-node-termination, אבל לא מתבצעת הפעלה מחדש.

כדי לפתור את הבעיה, צריך להמתין לפחות 60 שניות אחרי השלמת האתחול מחדש לפני שמחילים מחדש את התווית cloud.google.com/perform-reboot=true. כדי לוודא שההפעלה מחדש הושלמה, בודקים שהתווית perform-reboot וההערה reboot-boot-id הוסרו מהצומת:

kubectl get node NODE_NAME -o jsonpath='{.metadata.labels.cloud\.google\.com/perform-reboot}'
kubectl get node NODE_NAME -o jsonpath='{.metadata.annotations.node\.gke\.io/reboot-boot-id}'

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

שתי הפקודות צריכות להחזיר פלט ריק לפני שמחילים מחדש את התווית.

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

  1. מסירים את תווית הצומת cloud.google.com/perform-reboot:

    kubectl label node NODE_NAME \
    cloud.google.com/perform-reboot-

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

  2. הסרת ההערה node.gke.io/reboot-boot-id:

    kubectl annotate node NODE_NAME \
    node.gke.io/reboot-boot-id-

    אם הפלט הוא not found, סימן שההערה כבר הוסרה.

  3. מסירים את ה-taint‏ cloud.google.com/impending-node-termination:NoSchedule:

    kubectl taint nodes NODE_NAME \
    cloud.google.com/impending-node-termination:NoSchedule-

    אם הפלט הוא not found, המשמעות היא שההכתמה כבר הוסרה.

  4. מחכים לפחות 60 שניות.

  5. החלה מחדש של התווית cloud.google.com/perform-reboot:

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

איפוס של מעבדי 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

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

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

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

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

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

כדי להשתמש בצמתים סודיים של GKE, צריך להתקין ידנית דרייבר של 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, ה-Pod של gpu-device-plugin שפועל בצומת המושפע מתעד את השגיאה ביומן. יש שני סוגים של יומני שגיאות 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 או 1.35, כדאי לעיין גם בדף בעיות ידועות ב-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

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

הבעיה הזו מתרחשת אם שדרגתם את מאגרי הצמתים של 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 באמצעות Topology Aware Scheduling (TAS). אחרי שמריצים את הבדיקה של NCCL, המערכת יוצרת באופן אוטומטי את היומנים בכל הצמתים המשתתפים.

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

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

    אם אתם לא בטוחים איפה קובצי היומן נמצאים, בדוגמה הבאה אפשר לראות איפה 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.

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