אימון מודלים של למידת מכונה בקנה מידה גדול ב-GKE באמצעות Multi-Tier Checkpointing

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

יתרונות

היתרונות של שימוש ב-Multi-Tier Checkpointing:

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

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

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

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

דרישות

התכונה 'יצירת נקודות בקרה בכמה רמות' דורשת גרסה ‎1.32.4-gke.1415000 ואילך של אשכול GKE.

מגבלות

  • אין תמיכה באשכולות Autopilot.

הגדרת צמתי GKE לשימוש ב-Multi-Tier Checkpointing

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

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

  1. יוצרים אשכול עם Multi-Tier Checkpointing,‏ Cloud Storage FUSE CSI driver ואיחוד זהויות של עומסי עבודה ל-GKE מופעלים. אם אתם משתמשים בפרוסות TPU לעומס העבודה של הלמידה החישובית, תצטרכו לשנות את הפקודה ליצירת אשכול כדי לכלול את ההגדרה של מאגר צמתים של פרוסת TPU.

    gcloud container clusters create CLUSTER_NAME \
    --addons=HighScaleCheckpointing,GcsFuseCsiDriver  \
    --node-locations=NODE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --cluster-version=CLUSTER_VERSION
    --location=CLUSTER_LOCATION \
    --machine-type=MACHINE_TYPE \
    --num-nodes=NUM_NODES

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫NODE_LOCATION: האזור של צמתי האשכול. כאן נמצאת קיבולת ה-TPU שלכם.
    • ‫PROJECT_ID: Google Cloud מזהה הפרויקט.
    • ‫CLUSTER_VERSION: הגרסה של האשכול. הגרסה המינימלית הנתמכת היא 1.32.4-gke.1415000.
    • ‫CLUSTER_LOCATION: האזור שבו רוצים ליצור את האשכול.
    • ‫MACHINE_TYPE: סוג המכונה שמשמש לצמתים שמריצים רכיבים כמו בקר JobSet ובקר multi-tier checkpointing. לצורך אימון בקנה מידה גדול, מומלץ להשתמש ב-e2-standard-4 מכונות לפחות. לא תשתמשו בסוג המכונה הזה לאימון המודל. במקום זאת, תיצרו מאגרי צמתים נפרדים למטרה הזו, ולרוב תשתמשו במשפחות של מכונות וירטואליות שעברו אופטימיזציה להאצה.
    • ‫NUM_NODES: מספר הצמתים שייווצרו בכל אחד מהאזורים של האשכול.

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

כדי להשתמש בגיבוי רב-שכבתי עם אשכול קיים, מפעילים אותו יחד עם מנהל התקן ה-CSI של Cloud Storage FUSE ועם איחוד שירותי אימות הזהות של עומסי עבודה ל-GKE באמצעות הפקודות הבאות. גרסת האשכול הקיימת צריכה להיות מאוחרת יותר מגרסה 1.32.3-gke.1170000.

  1. הפעלת איחוד שירותי אימות הזהות של עומסי העבודה ב-GKE:

    gcloud container clusters update CLUSTER_NAME \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --location=CLUSTER_LOCATION

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

    • ‫CLUSTER_NAME: שם האשכול.
    • ‫PROJECT_ID: Google Cloud מזהה הפרויקט.
    • ‫CLUSTER_LOCATION: האזור של האשכול.

  2. מפעילים את התכונה Multi-Tier Checkpointing ואת מנהל התקן ה-CSI של Cloud Storage FUSE:

    gcloud container clusters update CLUSTER_NAME \
    --update-addons=HighScaleCheckpointing=ENABLED,GcsFuseCsiDriver=ENABLED \
    --location=CLUSTER_LOCATION

הגדרת הרשאות לשימוש בתכונה 'שמירת נקודות ביקורת מרובות'

בקטע הזה מוסבר איך מגדירים הרשאות לשימוש בתכונה Multi-Tier Checkpointing.

איך מעניקים גישה לקטגוריות של Cloud Storage

נפחי האחסון הזמניים שבהם נעשה שימוש במנהל ההתקן של ה-CSI של Multi-Tier Checkpointing חייבים להשתמש בקטגוריות קיימות של Cloud Storage.

כדי לאחסן נקודות ביקורת בקטגוריה של Cloud Storage, ל-Multi-Tier Checkpointing צריכה להיות גישה לקטגוריה. כדי להשתמש בתכונה Multi-Tier Checkpointing, צריך להקצות את תפקיד ה-IAM ‏Storage Object User ‏ (roles/storage.objectUser) ב-bucket לחשבון השירות של Kubernetes.

gcloud storage buckets add-iam-policy-binding gs://GCS_BUCKET \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-managed-checkpointing/sa/gke-checkpointing-multitier-node" \
    --role "roles/storage.objectUser"

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

(אופציונלי) מעניקים גישה לחשבון השירות שמוגדר כברירת המחדל של Compute Engine

אם המכונות של Compute Engine צריכות גישת קריאה לקטגוריה של Cloud Storage, צריך להעניק את תפקיד ה-IAM‏ Storage Object Viewer‏ (roles/storage.objectViewer) לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine.

gcloud storage buckets add-iam-policy-binding gs://GCS_BUCKET \
    --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role roles/storage.objectViewer

פריסת בקר JobSet

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

כדי להגדיל את בקשת הזיכרון ל-‎1 Gi, את מגבלת הזיכרון ל-‎2 Gi ואת בקשת המעבד ל-1 עבור מאגר המנהלים בפריסת JobSet, מריצים את פקודת התיקון הבאה:

kubectl patch -n jobset-system deploy jobset-controller-manager --type json \
    --patch '[{"op": "add", "path": "/spec/template/spec/containers/0/resources", "value": {"limits": {"memory": "2Gi"}, "requests": {"cpu": "1", "memory": "1Gi"}}}]'

הפעלת ה-CSI driver של Multi-Tier Checkpointing

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

יצירת CheckpointConfiguration

‫CheckpointConfiguration הוא משאב מותאם אישית של Kubernetes שמציין מאפיינים לפריסת מנהל ההתקן Multi-Tier Checkpointing CSI. המשאב הזה הוא ברמת האשכול.

  1. יוצרים את קובץ המניפסט checkpoint.yaml.

    apiVersion: checkpointing.gke.io/v1
kind: CheckpointConfiguration
metadata:
  name: MTC_CONFIG_NAME-configuration
spec:
    cloudStorageBucketName: GCS_BUCKET
    nodeSelector:
        node.kubernetes.io/instance-type: MACHINE_TYPE
    tolerations:
    - key: TOLERATION_KEY
        operator: Exists
        effect: NoSchedule
    inMemoryVolumeSize: IN_MEMORY_VOLUME_SIZE
    gcsFuseMountOptions:
    - implicit-dirs
    - metadata-cache:negative-ttl-secs:0
    - metadata-cache:ttl-secs:-1
    - metadata-cache:stat-cache-max-size-mb:-1
    - metadata-cache:type-cache-max-size-mb:-1
    - file-system:kernel-list-cache-ttl-secs:0
    - read_ahead_kb=1024
    - write:enable-streaming-writes:true

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

    • ‫MTC_CONFIG_NAME: השם של CheckpointConfiguration. השם הזה הוא גלובלי לאשכול ולא ספציפי לעבודה.
    • ‫GCS_BUCKET: השם של הקטגוריה ב-Cloud Storage שבה מאחסנים את נתוני נקודת הבדיקה. משתמשים בקטגוריה שהגדרתם בשלב הגדרת קטגוריה של Cloud Storage עם הרשאות.

    • ‫MACHINE_TYPE: סוג המכונה של המאיצים המתאימים. הערך יכול להיות אחד מהערכים הבאים:

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

    • ‫TOLERATION_KEY: השדה הזה מאפשר לתזמן את מנהל ההתקן של CSI בצמתים עם כתמי התאמה. מידע נוסף על אופן הפעולה של דחייה (taint) בסוגים שונים של מאיצים זמין בדפים הבאים:

    • ‫IN_MEMORY_VOLUME_SIZE: הגודל של מטמון נקודות הבדיקה בזיכרון. מציינים את הכמות ואת היחידה (לדוגמה, ‎200 Gi).הערך הזה צריך להיות:

      • גודל נקודת הביקורת המקומית של TPU כפול 2.2
      • גודל נקודת הביקורת המקומית עבור מעבדי GPU עם עמית יחיד כפול 6.6.

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

    kubectl apply -f checkpoint.yaml

  3. בודקים שמנהל ההתקן של CSI פועל:

    kubectl get pod -n gke-managed-checkpointing

    הפלט אמור להיראות כך: יהיו כמה רשומות, אחת לכל צומת מואץ.

    NAME                                                          READY   STATUS    RESTARTS   AGE
multitier-driver-e2b033a7-a4e7-496a-87a3-ffd7fcc2e57b-2d4fz   5/5     Running   0          114s

הסרת מנהל התקן CSI של Multi-Tier Checkpointing

אם רוצים לבטל את הפריסה של מנהל התקני ה-CSI של Multi-Tier Checkpointing, צריך למחוק את המשאב CheckpointConfiguration. בקר Multi-Tier Checkpointing מסיר את מנהל התקן ה-CSI מהצמתים. כך מסירים את דיסקי ה-RAM ומתפנה זיכרון לעומסי עבודה אחרים. לדוגמה:

kubectl delete -f checkpoint.yaml

ניהול שמירת נתונים ואיסוף פסולת עבור גיבויים של אחסון בענן

אתם אחראים להטמעת מדיניות שמירת נתונים לגיבויים של נקודות ביקורת ב-Cloud Storage. הגיבוי באמצעות Multi-Tier Checkpointing כותב גיבויים של נקודות ביקורת רק ל-Cloud Storage, ואף פעם לא משנה או מוחק אותם.

הרבה כלים של קוד פתוח יכולים לטפל בשמירת נתונים וב-garbage collection, כולל הכלים הבאים:

בדוגמה הבאה נעשה שימוש ב-backup-warden, כאשר הספרייה backup נטענת למיקום גיבוי שמשתמש ב-Cloud Storage FUSE:

# Add --delete option to actually delete the backups, as is it only shows what would be deleted (dry-run)
backup-warden -p backup \
    --hourly 24 \
    --daily 7 \
    --weekly 5 \
    --monthly always \
    --yearly always \
    --prefer-recent

עדכון המניפסט של עומס העבודה JobSet

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

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

  1. מוסיפים את השורות הבאות למאגר jax-tpu.

    volumeMounts:
- name: checkpoint
  mountPath: CHECKPOINT_DIR

    מחליפים את CHECKPOINT_DIR בנתיב לספריית נקודות הבדיקה. זה המיקום שבו נוצר replicator.yaml ובו מתבצעת פעולת השמירה של נקודת המיקום על ידי Multi-Tier Checkpointing. מידע נוסף זמין במאמר בנושא שילוב של שמירת נקודות ביקורת מרובות באפליקציה.

  2. מוסיפים את השורות הבאות לשדה spec.template.spec של תיאור המשרה.

    volumes:
- name: checkpoint
  csi:
    driver: multitier-checkpoint.csi.storage.gke.io

שילוב של Multi-Tier Checkpointing באפליקציה

כדי לשתף מידע על מיקומי נקודות הבדיקה ועל מוכנות השכפול, צריך לשנות את האפליקציה כך שתשתמש בפרוטוקול הבא כדי לתקשר עם Multi-Tier Checkpointing.

השילוב הזה כבר מיושם במסגרות ובספריות הבאות:

  1. ‫MaxText (באמצעות Orbax): ל-MaxText יש תמיכה מובנית ב-Multi-Tier Checkpointing ‏ (MTC). מידע נוסף זמין במאמרי העזרה בנושא MaxText MTC.
  2. כל מודל שמשתמש ב-Orbax: השילוב מורכב משני רכיבים עיקריים: מודול ההפעלה של MTC להגדרה ראשונית (לדוגמה, ראו MaxText), וReplicator Checkpoint Manager לשמירה ולשחזור של נקודות ביקורת מדיסק RAM מקומי (לדוגמה, ראו MaxText).
  3. דוגמה להפניה ל-PyTorch: הדוגמה הזו זמינה לעומסי עבודה שמשתמשים ב-NeMo עם PyTorch.

הפעלה

בקטע הזה מתוארים השלבים הראשוניים שנדרשים כדי שהאפליקציה תפעל עם Multi-Tier Checkpointing.

הכלי Replicator הוא רכיב ליבה של Multi-Tier Checkpointing, והוא פועל בכל צומת כחלק מ-CSI driver. הכלי Replicator מנהל את השכפול של נקודות הבדיקה בשכבות אחסון שונות, החל מדיסק ה-RAM המקומי ועד לצמתים עמיתים ולאחסון חיצוני כמו Cloud Storage.

קובץ ה-replicator.yaml משמש כמישור בקרה דינמי בין משימת האימון של ה-ML (קוד המסגרת) לבין רכיב המשכפל. אפליקציית ה-ML שלכם יוצרת את הקובץ הזה באופן פרוגרמטי בכרך המקומי (RAMDisk), שאליו יש גישה גם למשימת האימון וגם לשירות Replicator. קובץ המניפסט הזה מאפשר למסגרת למידת המכונה לספק הוראות להגדרת זמן הריצה ולניהול מחזור החיים לרפליקטור, שונות מפרמטרים סטטיים של התשתית (לדוגמה, תדירות ההעלאה ל-Cloud Storage) שמוגדרים במהלך הגדרת ה-Backend.

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

האפליקציה צריכה לבצע את השלבים הבאים במהלך ההפעלה:

  1. מחכים עד שהקובץ replicator.yaml לא יהיה קיים, מה שמצביע על כך שהכלי Replicator מוכן להגדרה על ידי האפליקציה. קובץ replicator.yaml נוצר במיקום CHECKPOINT_DIR שהגדרתם בקטע עדכון המניפסט של JobSet של עומס העבודה.

    כשיוצרים לראשונה את משימת אימון המודל, הקובץ לא קיים והאפליקציה יכולה להמשיך מיד.replicator.yaml עם זאת, אם המשימה הופעלה מחדש (למשל, בגלל כשל או התערבות ידנית), יכול להיות שהמערכת עדיין תעבד את מופע המשימה הקודם, והקובץ replicator.yaml מהמופע הזה עדיין יהיה קיים בכרך המקומי.

  2. האפליקציה או משינת ה-ML יוצרות את הקובץ replicator.yaml עם הגדרות שדומות לאלה שבהמשך.

    Orbax

    job-name: orbax
framework: orbax
assume-data-parallelism: 3
node-rank: 0
nodes: 32
peer-ranks: [1, 16] or peers-per-node: 2
backup-interval-minutes: 30

    PyTorch

    job-name: nemo
framework: pytorch.distributed
node-rank: 0
nodes: 32
peer-ranks: [1, 16] or peers-per-node: 2
backup-interval-minutes: 30

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

    • ‫name: השם של משימת האימון.
    • ‫framework: ה-framework של למידת המכונה שבו נעשה שימוש במשימת האימון.
    • ‫node-rank: המזהה הייחודי של הצומת הנוכחי במשימת האימון המבוזרת. הערך הזה מייצג את דירוג הצומת של הצומת שיצר את הקובץ הזה. לכל צומת שמשתתף בהרצה יהיה דירוג משלו.
    • ‫nodes: המספר הכולל של הצמתים שמשתתפים במשימת האימון המבוזרת. הערך הזה מגיע מהמטא-נתונים של ה-Pod. גם משימת האימון של ה-ML יכולה לראות את הערך הזה.
    • ‫peer-ranks או peers-per-node: שתי דרכים חלופיות לציין את טופולוגיית השכפול. צריך להשתמש רק באחד משני הפרמטרים האלה.
      • ‫peer-ranks: דרגות מפורשות של צמתי עמיתים שאליהם צריך לשכפל את נתוני נקודת הבקרה של הצומת הנוכחי. כך תוכלו לשלוט במדויק באילו צמתים ספציפיים ישמשו כשותפים לשכפול.
      • ‫peers-per-node: מספר הצמתים העמיתים לכל צומת שהכלי Replicator צריך לבחור באופן אוטומטי לשכפול.
    • ‫backup-interval-minutes: התדירות, בדקות, שבה מתבצע גיבוי של נקודות ביקורת ל-Cloud Storage. מומלץ להגדיר את הערך הזה ל-30 דקות או יותר.

  3. מחכים עד שהמערכת תמחק את קובץ ה-replicator.yaml החדש. ההודעה הזו מציינת שהכלי לשכפול הופעל מחדש וביצע ניקוי. השלב הזה מאפשר לכם להימנע מקבצים זמניים או לא עדכניים בנפח האחסון המקומי, כשאתם מבצעים את השלבים שמתוארים בקטע הבא באפליקציה.

שחזור מנקודת הבדיקה האחרונה הידועה כטובה (LKG)

  1. אחרי האתחול של הכלי לשכפול, Multi-Tier Checkpointing יוצר קישור סמלי אחד לכל עובד TPU או GPU. הקישורים הסמליים האלה נוצרים באותו נפח מקומי שמוטען כמו קובץ replicator.yaml, שבו העבודה שומרת נקודות ביקורת.

    הקישורים הסמליים הם בפורמט <job-name>-s{step}-n<node-rank>-w<worker-index>.restore.

  2. משחזרים כל עובד מקובץ .restore המתאים. לדוגמה, אפשר לעיין בדוגמה של מנהל נקודות ביקורת משוכפלות של Orbax בקטע הבא.

שמירת נקודת הביקורת

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

Orbax

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

מידע נוסף על השימוש בכלי Orbax לניהול נקודות ביקורת של שכפול זמין בקובץ MaxtTest checkpointing. דוגמה לאינטראקציה של שירות משכפל מופיעה בקובץ MaxText max_utils.

PyTorch

משתמשים ב-InClusterLocalCheckpointIO כ-pytorch_lightning.CheckpointIO מותאם אישית כדי להפעיל את התכונה 'יצירת נקודות ביקורת מבוזרות' בצורה נכונה עם אחסון מקומי. הפקודה לדוגמה הבאה מפעילה יצירת נקודות ביקורת רב-שכבתית באמצעות הטמעה לדוגמה שמבוססת על ה-framework של NVIDIA NeMo:

torchrun train.py <other_train_flags> \
    --local-ckpt-dir=CHECKPOINT_DIR \
    --local-ckpt-interval=20 \
    --job-name=JOB_NAME \
    --enable-high-scale-ckpt

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

  • ‫CHECKPOINT_DIR: הנתיב לספריית נקודות הבדיקה.
  • ‫JOB_NAME: השם של עומס העבודה של משימת האימון.

שדרוגי אשכולות

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

אם אתם רוצים לשמור על אותה הגדרה של daemonset, אתם לא צריכים לעשות כלום.

פתרון בעיות

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

האפשרות 'נקודות ביקורת מרובות רמות' לא מופעלת

השגיאה הבאה מציינת שהתכונה Multi-Tier Checkpointing לא מופעלת באשכול:

error: unable to recognize "checkpoint.yaml": no matches for kind "CheckpointConfiguration" in version "checkpointing.gke.io/v1"

יכול להיות שתיתקלו בשגיאה הזו אחרי שתריצו את הפקודה kubectl apply -f checkpoint.yamlבשלב Create a CheckpointConfiguration.

כדי לפתור את הבעיה, בודקים אם הפעלתם את התכונה Multi-Tier Checkpointing באשכול באמצעות הפקודה הבאה:

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID
    --location CLUSTER_LOCATION

אם האפשרות Multi-Tier Checkpointing מופעלת, הפלט אמור להיראות כך:

addonsConfig:
  gcePersistentDiskCsiDriverConfig:
    enabled: true
  gcsFuseCsiDriverConfig:
    enabled: true
  highScaleCheckpointingConfig:
    enabled: true
  kubernetesDashboard:
    disabled: true
  networkPolicyConfig:
    disabled: true

אם התכונה Multi-Tier Checkpointing לא מופעלת, צריך לעדכן את האשכול כדי להפעיל אותה.

מנהל התקנים (driver) של CSI לנקודות ביקורת (checkpoint) מרובות רמות לא מצליח לטעון נפחים

יכול להיות שתיתקלו בבעיה הזו אם מנהל ההתקן של CSI לא מצליח לטעון את אמצעי האחסון של Cloud Storage. יכול להיות שיש כמה שורות דומות.

kubectl get pod -n gke-managed-checkpointing
NAME                                                          READY   STATUS     RESTARTS   AGE
multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9   0/5     Init:0/1   0          6m32s

כדי לפתור את הבעיה, בודקים את האירועים של ה-Pod של מנהל ההתקן של CSI, כמו בדוגמה הבאה:

kubectl describe pod multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 -n gke-managed-checkpointing

Events:
  Type     Reason       Age                 From               Message
  ----     ------       ----                ----               -------
  Normal   Scheduled    17m                 default-scheduler  Successfully assigned gke-managed-checkpointing/multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 to gke-my-cluster-default-pool-353c773f-6d8q
  Warning  FailedMount  82s (x16 over 17m)  kubelet            MountVolume.SetUp failed for volume "gcs" : rpc error: code = PermissionDenied desc = failed to get GCS bucket "checkpointing-test-bucket": googleapi: Error 403: Caller does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist)., forbidden

אם הבעיה מתרחשת בגלל שגיאה בקטגוריה PermissionDenied של Cloud Storage, כמו שמוצג בדוגמה, אפשר לפתור את הבעיה על ידי הגדרה נכונה של ההרשאות.

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