פתרון בעיות שקשורות ל-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

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

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

ה-init container של הפלאגין של מכשיר ה-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, וה-Pods של מנהל ההתקן של ה-GPU או של הפלאגין של ה-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.

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

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

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

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

שגיאה: לא הצלחנו למצוא את המכשיר 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 ‏ (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, משכפלים את המאגר של מאיצי מנוע הקונטיינרים:

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. בדף הערות הגרסה של אבן הדרך הספציפית, מאתרים את הערת הגרסה שמתאימה לגרסה הספציפית של תמונת הצומת של מערכת ההפעלה שמותאמת לקונטיינרים. לדוגמה, בנתוני הגרסה של מערכת הפעלה שמותאמת לקונטיינרים: אבן דרך 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 או של ה-Deployment כך שיכלול את הנתיבים הנדרשים של 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 מאופס.
  • המכונה הבסיסית לא משתנה ודיסק האתחול נשמר, אבל אחרי ההפעלה מחדש, מזהה האתחול שונה.

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

דרישות

כדי להפעיל מחדש את מערכת ההפעלה של האורח בשיטה הזו, צריך להפעיל באשכול את GKE בגרסה 1.37.0-gke.3503000 ואילך. אל תפעילו מחדש את מערכת ההפעלה של האורח בגרסאות קודמות, כי יכול להיות ש-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. מגדירים את הצומת כלא פעיל.
    2. מפנה Pods, תוך התחשבות בתקציבי ההפצה ובפרק הזמן להפסקת הפעולה. פרטים על אופן ההגדרה של התנהגויות הסיום האלה זמינים במאמר הגדרת סיום תקין של עומסי עבודה ב-GKE
    3. מפעיל מחדש את הצומת באמצעות systemd. הצומת נסגר ומופעל מחדש, ומזהה האתחול משתנה.

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

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

      כניסה לדף Clusters

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

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

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

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

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

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

# 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.37.0-gke.3503000 ואילך.

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

בכל גרסאות 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 במכונות וירטואליות (VM) מסוג A3 ו-A4

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

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

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

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

    איפוס כל ה-GPU ב-VM

    /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

Confidential GKE Nodes דורש שתתקינו ידנית דרייבר של GPU שתואם לסוג ה-GPU שנבחר ולגרסת ה-GKE. אם הפודים של ה-GPU לא מתוזמנים בצומתי Confidential GKE ונשארים במצב 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 של התקנת מנהל ההתקן לא תומך ב-Confidential GKE Nodes.

פורסים את ה-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. משיגים את שם הצומת שמריץ את ה-GPU Pod:

    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, כמו מחזור פעילות ושימוש בזיכרון.

הכלי 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

כדאי גם לבדוק אם ה-Pods של device-injector במרחב השמות 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. מפעילים מחדש את הפודים של עומס העבודה.

ניפוי באגים באמצעות יומנים של 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 מכל הצמתים, צריך לוודא שהיומנים מכילים את המידע הבא:

    • שמות המארחים של כל המכונות הווירטואליות שמשתתפות בעומס העבודה.
    • מזהי התהליכים (PID) של כל התהליכים הרלוונטיים במכונה הווירטואלית.
    • הדירוגים של כל יחידות ה-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: שם המארח של ה-VM. הערך הזה מציין באיזו מכונה וירטואלית נעשה שימוש כש-NCCL יצר את רשומת היומן.
    • ‫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.

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