אוטומציה של כוונון הביצועים באמצעות פרופילים של Cloud Storage FUSE

במאמר הזה נסביר איך אפשר לשפר באופן אוטומטי את הביצועים של מנהל ההתקן של ה-CSI של Cloud Storage FUSE ולהאיץ את הגישה לנתונים של עומסי העבודה של AI/ML באמצעות פרופילים של Cloud Storage FUSE ב-Google Kubernetes Engine‏ (GKE).

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

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

לפני שקוראים את המסמך הזה, חשוב להכיר את היסודות של Cloud Storage,‏ Kubernetes ומנהל התקן ה-CSI של Cloud Storage FUSE. כדאי גם לעיין בדרישות לשימוש במנהל התקן ה-CSI של Cloud Storage FUSE.

היתרונות של שימוש בפרופילים של Cloud Storage FUSE

כדי לבצע כוונון אוטומטי של הביצועים לעומסי עבודה של AI/ML, פרופילי Cloud Storage FUSE משתמשים בהגדרות מוגדרות מראש של Cloud Storage FUSE ומחילים הגדרות נוספות ספציפיות ל-GKE. ההגדרות האלה מבוססות על שיטות מומלצות לשיפור הביצועים של Cloud Storage FUSE. היתרונות של שימוש בפרופילים מוגדרים מראש:

  • כוונון ביצועים פשוט: אפשר להשתמש בפרופילים מוגדרים מראש של Cloud Storage FUSE כדי להחיל את ההגדרות האופטימליות על עומסי עבודה נפוצים של AI/ML, כמו אימון, הצגה ונקודות ביקורת.
  • אופטימיזציה דינמית שמודעת למשאבים: השימוש בפרופילים של Cloud Storage FUSE מאפשר למנהל התקן ה-CSI להתאים באופן אוטומטי את גדלי המטמון ולבחור את אמצעי המטמון האופטימלי, כמו RAM או Local SSD, על סמך מאפיינים של קטגוריות או של ספריות משנה, כמו גודל, מספר אובייקטים וסוג המיקום, מגבלות של קובץ עזר והמשאבים הזמינים של הצומת.
  • ביצועי קריאה משופרים: כשמשתמשים בפרופיל gcsfusecsi-serving, מערכת GKE מפעילה באופן אוטומטי את Anywhere Cache כדי לשפר את ביצועי הקריאה של עומסי העבודה שלכם.
  • תובנות לגבי כוונון הביצועים: תוכלו לקבל תובנות לגבי החלטות הכוונון האוטומטיות באמצעות יומנים מובנים שמפרטים את אותות הקלט מהסביבה שלכם ואת ההגדרות שחלות כתוצאה מכך על ידי מנהל ההתקן. מידע נוסף זמין במאמר הצגת תובנות לגבי המלצות

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

מגבלות

דרישות

עלויות

בנוסף לעלויות הרגילות של GKE ושל Cloud Storage שמשויכות למנהל התקן CSI של Cloud Storage FUSE, השימוש בפרופילים של Cloud Storage FUSE כרוך בעלויות הבאות.

עלויות של סריקת דליים

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

עלויות של Anywhere Cache

בפרופיל gcsfusecsi-serving מופעלת באופן אוטומטי התכונה Anywhere Cache, והחיוב מתבצע בהתאם לתמחור של Cloud Storage Anywhere Cache. כדי להימנע מחיובים על מקרים של מטמון כשכבר לא צריך אותם, אפשר לעיין במאמר בנושא אמצעי בקרה על עלויות.

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

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

  • מפעילים את Cloud Storage API ואת Google Kubernetes Engine API.
    • הפעלת ממשקי API
  • אם רוצים להשתמש ב-CLI של Google Cloud למשימה הזו, צריך להתקין ואז להפעיל את ה-CLI של gcloud. אם התקנתם בעבר את ה-CLI של gcloud, מריצים את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • בוחרים Google Cloud אזור שמתאים לצרכים שלכם. מומלץ ליצור את אשכול GKE ואת קטגוריה של Cloud Storage באותו אזור כדי לבצע אופטימיזציה של הביצועים והעלות, אבל חובה לעשות זאת כשמשתמשים בפרופיל gcsfusecsi-serving או כשמתכננים להפעיל את Anywhere Cache.
  • מוודאים שיש לכם קטגוריה קיימת ב-Cloud Storage שמכילה את מערך הנתונים, המודל או נקודות הבדיקה של עומס העבודה של ה-AI/ML. אם צריך ליצור קטגוריה, אפשר לעיין במאמר יצירת קטגוריה.

בחירת פרופיל ביצועים

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

פרופיל שם ה-StorageClass אופטימיזציה ל תכונות עיקריות
הדרכה gcsfusecsi-training קריאות תפוקה גבוהה מבצע אופטימיזציה של זמן האחזור של הנתונים עבור מעבדי GPU ו-TPU במהלך אימון על מערכי נתונים גדולים.
Checkpointing gcsfusecsi-checkpointing כתיבה בתפוקה גבוהה מצמצם את הזמן שנדרש לשמירת נקודות ביקורת גדולות, וכך מקטין את ההפסקות באימון.
השרת ממלא את הבקשה gcsfusecsi-serving גישה לנתונים ושמירתם במטמון ההגדרה Anywhere Cache מופעלת כברירת מחדל כדי להאיץ פעולות קריאה.

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

kubectl get sc -l gke-gcsfuse/profile=true

הגדרת הרשאות IAM

נותנים לסוכן השירות של GKE הרשאות לניתוח של קטגוריית Cloud Storage ולניהול של Anywhere Cache.

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

  • ‫GCS_PROJECT: מזהה הפרויקט שמכיל את הקטגוריה שלכם ב-Cloud Storage.
  • ‫PROJECT_NUMBER: מספר הפרויקט של פרויקט אשכול GKE.
  • ‫BUCKET_NAME: שם הקטגוריה של Cloud Storage.

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

אפשרות א': תפקיד בהתאמה אישית (מומלץ)

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

  1. יוצרים תפקיד IAM בהתאמה אישית שמאפשר לסרוק אובייקטים וליצור מטמון בכל מקום:

    gcloud iam roles create gke.gcsfuse.profileUser \
  --project=GCS_PROJECT \
  --title="GKE GCSFuse Profile User" \
  --description="Allows scanning GCS buckets for objects, retrieving bucket metadata, and creating caches." \
  --permissions="storage.objects.list,storage.buckets.get,storage.anywhereCaches.create,storage.anywhereCaches.get,storage.anywhereCaches.list,storage.anywhereCaches.update"

  2. מקשרים את התפקיד המותאם אישית לסוכן השירות של GKE עבור הדלי הספציפי:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --project=GCS_PROJECT \
  --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
  --role="projects/GCS_PROJECT/roles/gke.gcsfuse.profileUser"

אפשרות ב': תפקיד רגיל לפרופילים של אימון וסימון נקודות

אם אתם משתמשים רק בפרופילים Training או Checkpointing ולא מתכננים להשתמש ב-Anywhere Cache, מריצים את הפקודה הבאה:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
    --project=GCS_PROJECT \
    --member="serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

פריסת עומס עבודה עם פרופיל Cloud Storage FUSE

כדי לפרוס עומס עבודה עם פרופיל Cloud Storage FUSE, פועלים לפי השלבים הבאים.

  1. יוצרים מניפסט של PersistentVolume ‏(PV) שמפנה לאחד מסוגי האחסון (StorageClass) של פרופיל Cloud Storage FUSE:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 5Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: STORAGECLASS_NAME
  mountOptions:
    - only-dir=BUCKET_DIR_PATH # Optional
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME

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

    • ‫STORAGECLASS_NAME: השם של פרופיל StorageClass שרוצים להשתמש בו. הערך חייב להיות gcsfusecsi-training,‏ gcsfusecsi-checkpointing או gcsfusecsi-serving.
    • ‫BUCKET_DIR_PATH: (אופציונלי) הנתיב בתוך הקטגוריה של Cloud Storage, אם אתם טוענים ספרייה ספציפית. אם מציינים נתיב, GKE סורק את הנתיב הזה כדי לבצע אופטימיזציה. אם לא מציינים את הנתיב, GKE סורק את כל הדלי.
    • ‫BUCKET_NAME: שם הקטגוריה ב-Cloud Storage שציינתם כשהגדרתם גישה לקטגוריות ב-Cloud Storage.

  2. יוצרים PersistentVolumeClaim ‏ (PVC) שמבקש את אותו StorageClass כמו PV:

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
  namespace: NAMESPACE
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
  volumeName: my-pv
  storageClassName: STORAGECLASS_NAME

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

    • ‫NAMESPACE: מרחב השמות שבו רוצים לפרוס את ה-Pod.
    • ‫STORAGECLASS_NAME: השם של StorageClass כפי שמופיע ב-PV.

  3. משתמשים ב-PVC בפריסה:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  namespace: NAMESPACE
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
      annotations:
        gke-gcsfuse/volumes: "true"
    spec:
      serviceAccountName: KSA_NAME
      containers:
      - name: my-container
        image: busybox
        volumeMounts:
        - name: my-gcs-volume
          mountPath: "/data"
      volumes:
      - name: my-gcs-volume
        persistentVolumeClaim:
          claimName: my-pvc

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

אחרי הפריסה, מנהל ההתקן של CSI מחשב באופן אוטומטי את גדלי המטמון האופטימליים ואת אפשרויות ההרכבה על סמך המשאבים של הצומת, כמו יחידות GPU או TPU, זיכרון, SSD מקומי, גודל הדלי או ספריית המשנה ומגבלות המשאבים של ה-sidecar.

אימות האופטימיזציה האוטומטית

תהליכים ברקע ב-GKE מנתחים באופן אוטומטי את הדלי ומסנכרנים את Anywhere Cache (אם נעשה בו שימוש).

בדיקת הסטטוס של סריקת הקטגוריה ושל המטמון

אחרי שיוצרים את ה-PV, פועלים לפי השלבים הבאים כדי לבדוק את הסטטוס של סריקת ה-bucket ושל הזיכרון מטמון. אין צורך להמתין עד לפריסת ה-Pod.

  1. בודקים את סטטוס ה-PV:

    kubectl describe pv my-pv

  2. בפלט, מוודאים שהאירוע ScanOperationSucceeded מופיע. הפלט אמור להיראות כך:

    Normal  ScanOperationSucceeded  gke-gcsfuse-scanner  Bucket scan completed successfully for bucket "my-bucket", directory "my-dir": "526893" objects, "57690897566" bytes

  3. אם אתם משתמשים בפרופיל gcsfusecsi-serving, ודאו שהאירוע AnywhereCacheSyncSucceeded מופיע אחרי ששכבת הקאשינג מוכנה. הפלט אמור להיראות כך:

    Normal  AnywhereCacheSyncSucceeded  gke-gcsfuse-scanner  Anywhere Cache sync succeeded for PV "my-pv": us-central1-c:running

  4. מוודאים שההערות של PV עודכנו עם תוצאת הסריקה:

    gke-gcsfuse/bucket-scan-status: completed
gke-gcsfuse/bucket-scan-num-objects: "526893"
gke-gcsfuse/bucket-scan-total-size-bytes: "57690897566"
gke-gcsfuse/bucket-scan-location-type: multi-region
gke-gcsfuse/bucket-scan-last-updated-time: 2025-12-10T22:48:38Z

בדיקת הסטטוס של ה-Pod

אחרי שפורסים את ה-Pod, מריצים את הפקודה הבאה:

kubectl get pods -n NAMESPACE

מחליפים את NAMESPACE במרחב השמות שבו פרסתם את ה-Pods.

המודולים שלכם אמורים להיות עכשיו במצב RUNNING, עם שיטות מומלצות לשיפור הביצועים שמוחלות באופן אוטומטי. אם הסטטוס של ה-Pods הוא SchedulingGated, המשמעות היא ש-GKE עדיין סורק את הדלי או את ספריית המשנה. ה-Pods יישארו במצב הזה עד שבקר ה-CSI ישלים את הסריקה ויעדכן את ה-PV.

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

אם נתקלתם בשגיאות, אפשר להיעזר בקטע פתרון בעיות.

הפניה להגדרות של StorageClass

בקטע הזה מופיעים מניפסטים של StorageClass לפרופילים המותקנים מראש של Cloud Storage FUSE, וכן הפניה מפורטת לאפשרויות ולפרמטרים של הטעינה שבהם נעשה שימוש בפרופילים. ההגדרות האלה מאפשרות לדרייבר של gcsfuse.csi.storage.gke.io להגדיר אוטומציה של כוונון הביצועים וניהול המשאבים של עומסי העבודה של ה-AI/ML.

הדרכה

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcsfusecsi-training
  labels:
    gke-gcsfuse/profile: "true"
provisioner: gcsfuse.csi.storage.gke.io
mountOptions:
  - profile:aiml-training
parameters:
  skipCSIBucketAccessCheck: true
  gcsfuseMetadataPrefetchOnMount: "true"
  fuseFileCacheMediumPriority: "gpu:ram|lssd,tpu:ram,general_purpose:ram|lssd"
  fuseMemoryAllocatableFactor: "0.7"
  fuseEphemeralStorageAllocatableFactor: "0.85"
  bucketScanResyncPeriod: "168h"
  bucketScanTimeout: "2m"

Checkpointing

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcsfusecsi-checkpointing
  labels:
    gke-gcsfuse/profile: "true"
provisioner: gcsfuse.csi.storage.gke.io
mountOptions:
  - profile:aiml-checkpointing
  - read_ahead_kb=1024
parameters:
  skipCSIBucketAccessCheck: true
  gcsfuseMetadataPrefetchOnMount: "true"
  fuseFileCacheMediumPriority: "gpu:ram|lssd,tpu:ram,general_purpose:ram|lssd"
  fuseMemoryAllocatableFactor: "0.7"
  fuseEphemeralStorageAllocatableFactor: "0.85"
  bucketScanResyncPeriod: "168h"
  bucketScanTimeout: "2m"

השרת ממלא את הבקשה

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcsfusecsi-serving
  labels:
    gke-gcsfuse/profile: "true"
provisioner: gcsfuse.csi.storage.gke.io
mountOptions:
  - profile:aiml-serving
  - read_ahead_kb=131072
  - file-cache:max-size-mb:0
  - read:enable-buffered-read:true
  - read:global-max-blocks:80
parameters:
  anywhereCacheZones: "*"
  anywhereCacheAdmissionPolicy: "admit-on-first-miss"
  anywhereCacheTTL: "1h"
  skipCSIBucketAccessCheck: true
  gcsfuseMetadataPrefetchOnMount: "true"
  fuseFileCacheMediumPriority: "gpu:ram|lssd,tpu:ram,general_purpose:ram|lssd"
  fuseMemoryAllocatableFactor: "0.7"
  fuseEphemeralStorageAllocatableFactor: "0.85"
  bucketScanResyncPeriod: "168h"
  bucketScanTimeout: "2m"

הפרופילים משתמשים באפשרויות ההרכבה ובפרמטרים הבאים עבור מנהל ההתקן gcsfuse.csi.storage.gke.io:

  • mountOptions:
    • ‫profile: מחיל קבוצה מוגדרת מראש של אופטימיזציות של Cloud Storage FUSE שמותאמות לעומסי עבודה של AI/ML. הערכים התקפים לפרופילים שהותקנו מראש הם aiml-training,‏ aiml-checkpointing ו-aiml-serving.
    • ‫read_ahead_kb: מציין את הגודל של מאגר הנתונים הזמני לקריאה מראש בקילובייט (KB). האפשרות הזו מאפשרת ל-Cloud Storage FUSE לבצע אחזור מראש של נתונים מ-Cloud Storage, מה שעשוי לשפר את ביצועי הקריאה בדפוסי גישה רציפים.
    • ‫file-cache:max-size-mb: בפרופיל ההצגה, מציין את הגודל המקסימלי במביבייט (MiB) של מטמון הקבצים. בעומסי עבודה של הגשת נתונים, שבהם מודלים נטענים בדרך כלל לזיכרון של GPU או TPU רק פעם אחת, הפרמטר הזה מוגדר לערך 0 כדי להשבית את מטמון הקבצים המקומי של Cloud Storage FUSE. כך אפשר למנוע קלט/פלט מיותרים בדיסק ולחסוך בנפח האחסון המקומי.
    • ‫read:enable-buffered-read: בפרופיל Serving, האפשרות הזו מאפשרת ל-Cloud Storage FUSE לנהל את המאגרים הפנימיים שלו, וכך להפחית את מספר קריאות המערכת הקטנות והיקרות בין האפליקציה לבין ליבת מערכת ההפעלה.
    • ‫read:global-max-blocks: בפרופיל ההצגה, המגבלה על המספר הכולל של בלוקים של זיכרון בו-זמני שמשמשים לקריאות עם מאגר זמני. האפשרות הזו עוזרת למנוע ממערכת FUSE לצרוך את כל ה-RAM הזמין כשמוצגות כמה בקשות.
  • parameters:
    • ‫skipCSIBucketAccessCheck: כשהערך מוגדר ל-"true", דרייבר ה-CSI מדלג על בדיקת הגישה הראשונית לקטגוריה. הפרמטר הזה עוזר לצמצם את מספר הקריאות ל-Security Token Service כדי למנוע בעיות פוטנציאליות במכסת השימוש.
    • ‫gcsfuseMetadataPrefetchOnMount: כשהערך מוגדר ל-"true", דרייבר ה-CSI מתחיל prefetching של מטא-נתונים של אובייקטים מ-Cloud Storage למטמון המקומי ברגע שהנפח מותקן. הפרמטר הזה יכול להאיץ את הגישה הראשונה לקבצים.
    • ‫fuseFileCacheMediumPriority: מגדיר את סדר העדיפויות של אמצעי האחסון שמשמשים את מטמון הקבצים של Cloud Storage FUSE. אפשר לציין העדפות שונות לצמתים עם מעבדי GPU, מעבדי TPU או צמתים למטרות כלליות. אפשרויות המדיה כוללות ram ו-lssd (Local SSD, אם הוא זמין ומופעל).
    • ‫fuseMemoryAllocatableFactor: מציינת בפורמט מחרוזת שבר שמגביל את הזיכרון המקסימלי ש-Cloud Storage FUSE יכול לצרוך במטמון, ביחס לזיכרון הכולל שניתן להקצאה של הצומת ולמגבלת הזיכרון של ה-sidecar.
    • ‫fuseEphemeralStorageAllocatableFactor: מגביל את השימוש במטמון של Cloud Storage FUSE באחסון זמני בצומת (כמו SSD מקומי לשמירת קבצים במטמון), ביחס לאחסון הזמני שניתן להקצאה בצומת או לאחסון הזמני של ה-sidecar שמוגבל לשמירה במטמון.
    • ‫bucketScanResyncPeriod: מגדיר את מרווח הזמן שבו מתבצעת סריקה מחדש של ה-PV כדי לזהות שינויים שבוצעו בקטגוריה של Cloud Storage.
    • ‫bucketScanTimeout: משך הזמן המקסימלי שמותר לפעולת סריקה של דלי. אם הסריקה נמשכת יותר מהזמן הזה, יכול להיות שיוצגו תוצאות חלקיות.
    • ‫anywhereCacheZones: מציינים רשימה מופרדת בפסיקים של אזורים נתמכים שבהם נוצרים מטמון Anywhere, לדוגמה, "us-central1-a,us-central1-b". כדי להשתמש בכל האזורים שזמינים לאשכול, משתמשים בערך "*". אם מגדירים את הערך "none" או לא מציינים ערך, המטמון בכל מקום מושבת.
    • ‫anywhereCacheTTL: אורך החיים (TTL) של הנתונים שמאוחסנים ב-Anywhere Cache, שנמדד מהגישה האחרונה. אם משנים את הערך הזה, מופעים קיימים של Anywhere Cache מתעדכנים עם ה-TTL החדש.
    • anywhereCacheAdmissionPolicy: קובע מתי להכניס נתונים למטמון Anywhere אחרי פספוס קריאה (כשנתונים מבוקשים לא נמצאים במטמון). האפשרויות כוללות את "admit-on-first-miss", שמאפשרת גישה לנתונים במקרה של החמצה ראשונה של קריאה, או את "admit-on-second-miss", שמאפשרת גישה לנתונים רק במקרה של החמצה שנייה של קריאה לאותו אובייקט. אם משנים את הערך הזה, מופעים קיימים של Anywhere Cache מתעדכנים בהתאם למדיניות החדשה.

אופציונלי: שינוי ההגדרות של פרופילים

אתם יכולים להתאים אישית הגדרות ספציפיות בפרופיל ועדיין ליהנות מהגדרות הבסיס שלו. אפשר להשתמש באפשרויות הבאות כדי לשנות פרופיל בלי ליצור StorageClass חדש.

שינוי אפשרויות ופרמטרים של טעינת הכונן

כדי לשנות התנהגויות ספציפיות, מוסיפים אפשרויות טעינה לשדה spec.mountOptions או פרמטרים של CSI לשדה spec.csi.volumeAttributes ב-PV. מערכת GKE מחילה את ההגדרות הידניות שלכם בנוסף להגדרות ברירת המחדל של הפרופיל.

בדוגמה הבאה אפשר לראות איך משנים את ברירת המחדל של אפשרות ההרכבה read_ahead_kb ומשביתים את הפרמטר gcsfuseMetadataPrefetchOnMount בפרופיל ההצגה.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv-override
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 5Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: gcsfusecsi-serving
  mountOptions:
  - read_ahead_kb=2048 # Overrides the profile's default.
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: my-gcs-bucket
    volumeAttributes:
      gcsfuseMetadataPrefetchOnMount: "false" # Overrides the profile's default.

תרחישים נפוצים לדוגמה:

  • כדי להפעיל את Anywhere Cache בפרופיל אימון, מוסיפים את הפרמטר anywhereCacheZones ישירות למפרט ה-PV.
  • כדי לשנות התנהגויות ספציפיות של Cloud Storage FUSE, כמו הגדלת הגודל של read_ahead_kb, כדי לעמוד בדרישות הייחודיות של עומס עבודה מסוים.

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

  • הגדרה של גודל מטמון ידני מבטלת את ההגדרה האוטומטית של גודל דינמי רק עבור הרכיב הספציפי הזה. השינוי הדינמי של הגודל ממשיך לכל שאר הרכיבים על בסיס המאמץ הטוב ביותר במסגרת יתרת תקציב המשאבים.
  • הגדרת אפשרות של metadata-cache או file-cache, כמו metadata-cache:stat-cache-max-size-mb, לא משביתה את החישוב האוטומטי לסוגים אחרים של מטמון.
  • אם מציינים את file-cache:max-size-mb באופן ידני, צריך להגדיר גם נפח מטמון קריאה בהתאמה אישית. כך אפשר לוודא שמוגדר באופן מפורש אמצעי אחסון עם קיבולת מספקת לגודל המטמון המותאם אישית.

עקיפה של סריקת קטגוריות באמצעות הערות

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

בדוגמה הבאה אפשר לראות איך מוסיפים את ההערה gke-gcsfuse/bucket-scan-status: "override" ל-PV, יחד עם הערות ספציפיות למדד.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv-override
  annotations:
    gke-gcsfuse/bucket-scan-status: "override"
    gke-gcsfuse/bucket-scan-num-objects: 19238
    gke-gcsfuse/bucket-scan-total-size-bytes: 94837465
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 5Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: STORAGECLASS_NAME
  csi:
    driver: gcsfuse.csi.storage.gke.io
    volumeHandle: BUCKET_NAME

תרחישים נפוצים לדוגמה:

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

פתרון בעיות

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

פרמטר הגדרה לא חוקי (InvalidArgument)

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

תסמין

ה-PV מציג אירוע ScanOperationStartError או AnywhereCacheSyncError עם הודעה שמכילה rpc error: code = InvalidArgument. לדוגמה:

  • Bucket scan timeout configuration error: rpc error: code = InvalidArgument desc = invalid duration format for "INVALID_DURATION".
  • Anywhere Cache sync failed for PV "PV_NAME": rpc error: code = InvalidArgument desc = failed to get anywhere cache "CACHE_NAME" ... invalid anywhere cache "CACHE_NAME" provided.

הסיבה

אחד או יותר מהפרמטרים בשדה spec.csi.volumeAttributes של ה-PV שלכם מעוצבים בצורה שגויה או מכילים ערכים שהמערכת לא יכולה לנתח.

הפתרון

מתקנים את ערכי הפרמטרים הלא תקינים במניפסט של ה-PV ומבצעים פריסה מחדש של ה-PV. מוודאים שכל ערכי משך הזמן (כמו bucketScanTimeout) הם בפורמט הנכון (לדוגמה, 2m או 10m) ושההגדרות הספציפיות לפרופיל תואמות לערכים הנתמכים התקפים.

ההרשאה נדחתה במהלך סריקת קטגוריה של Cloud Storage

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

תסמין

ב-PV מוצג אירוע ScanOperationStartError עם הודעה Error 403: Forbidden שמציינת שלמתקשר אין גישה ל-storage.buckets.get.

הסיבה

לסוכן השירות של GKE חסרות הרשאות ה-IAM הנדרשות, או ששם הקטגוריה שגוי.

הפתרון

  • מוודאים ששם הקטגוריה בשדה volumeHandle של ה-PV נכון ושהקטגוריה קיימת.
  • מוודאים שההרשאות של סוכן השירות של GKE ניתנות לזהות service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com עבור הקטגוריה הספציפית. מידע נוסף זמין במאמר הגדרת הרשאות IAM.

חוסר התאמה במיקום של מטמון Anywhere

לא ניתן ליצור את Anywhere Cache כי האזור המבוקש לא תואם למיקום של הדלי.

תסמין

ה-PV מציג אירוע AnywhereCacheSyncWarning עם ההודעה: Invalid zone. Anywhere Cache isn't available in the requested zone.

הסיבה

צריך ליצור את Anywhere Caches באזורים שנמצאים במיקום האזורי של הקטגוריה. השגיאה הזו מתרחשת בדרך כלל כשקלאסטר GKE וקטגוריית Cloud Storage נמצאים באזורים שונים.

הפתרון

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

הסתיים הזמן הקצוב לתפוגה של סריקת דלי

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

תסמין

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

הסיבה

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

הפתרון

  • מגדירים ערך גדול יותר בשדה bucketScanTimeout בקטע spec.csi.volumeAttributes של ה-PV, למשל 10m.
  • אם גודל הקטגוריה סטטי, אפשר לדלג על הסריקה על ידי הזנה ידנית של מספר האובייקטים והגודל שלהם.

מטמון המטא-נתונים מוגבל על ידי תקציב הזיכרון

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

תסמין

היומנים מכילים הודעה שמציינת שגודל המטמון של נתוני ה-stat של המטא-נתונים הנדרשים הוגבל לתקציב הזיכרון הזמין של Cloud Storage FUSE.

הסיבה

מטמון המטא-נתונים של מספר האובייקטים בקטגוריה חורג מהזיכרון שהוקצה ל-Cloud Storage FUSE sidecar או מהזיכרון הזמין של הצומת.

הפתרון

  • כדי לצמצם את היקף הגישה לנפח האחסון לספריית משנה קטנה יותר עם פחות אובייקטים, משתמשים באפשרות only-dir mount.
  • הגדלת מגבלת הזיכרון עבור קונטיינר ה-sidecar של Cloud Storage FUSE.
  • אם המגבלות של קובץ ה-sidecar כבר מספיקות, כדאי להשתמש בסוג צומת עם יותר זיכרון שניתן להקצאה.

מטמון הקבצים הושבת בגלל מגבלות על משאבים

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

תסמין

ביומנים מופיעה האזהרה: No suitable file cache medium found or requirement exceeded limits for all options.

הסיבה

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

הפתרון

  • כדי לצמצם את היקף הגישה לנפח האחסון לספריית משנה קטנה יותר עם פחות אובייקטים, משתמשים באפשרות only-dir mount.
  • מגדילים את מגבלות המשאבים של Cloud Storage FUSE sidecar.
  • משתמשים בסוג צומת עם יותר זיכרון או מפעילים כונני SSD מקומיים במאגר הצמתים.

מעקב אחר הסטטוס באמצעות אירועים של PersistentVolume

‫GKE מתעד ב-PV שגיאות ואירועים מרכזיים שקשורים להגדרות. כדי לבדוק את האירועים האלה, מריצים את הפקודה הבאה:

kubectl describe pv PV_NAME

אחרי שהסריקה של הקטגוריה מסתיימת בהצלחה, מופיע אירוע ScanOperationSucceeded. אם משתמשים בפרופיל gcsfusecsi-serving, יופיע אירוע AnywhereCacheSyncSucceeded אחרי ששכבת השמירה במטמון תפעל.

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

מנהל התקן ה-CSI של Cloud Storage FUSE מתעד החלטות מפורטות לגבי ההגדרות ותובנות לגבי הביצועים. כדי להציג את היומנים האלה ב-Cloud Logging, משתמשים בשאילתה הבאה:

resource.type="k8s_container"
resource.labels.pod_name=~"gcsfusecsi-node-.*"

צפייה בתובנות לגבי ההמלצה

כדי להבין את אותות הקלט הספציפיים ואת ההחלטות שהתקבלו על ידי לוגיקת הכוונון האוטומטי, מחפשים את המחרוזת GCSFuseCSIRecommendation ביומני מנהל ההתקן של CSI. מטען הנתונים (payload) של JSON שמתקבל מספק מדדים מפורטים, כולל:

  • ‫inputSignals: מספר האובייקטים בקטגוריה, גודל הנתונים הכולל ומשאבי הצומת הזמינים (RAM ואחסון זמני).
  • ‫decision: הגדלים הסופיים של המטמון שחושבו ומדיום האחסון שנבחר (ram או lssd).
{
  "insertId": "INSERT_ID",
  "jsonPayload": {
    "decision": {
      "fileCacheBytes": 300000000,
      "fileCacheMedium": "lssd",
      "metadataStatCacheBytes": 4500,
      "metadataTypeCacheBytes": 600
    },
    "target": {
      "nodeName": "NODE_NAME",
      "pvName": "PV_NAME",
      "podName": "POD_NAME"
    },
    "message": "GCSFuseCSIRecommendation: Recommended cache configs for PV PV_NAME and Pod POD_NAME: FileCache: 287MiB (lssd) | MetadataStatCache: 1MiB | MetadataTypeCache: 1MiB | Expand for full details",
    "inputSignals": {
      "requiredFileCacheBytes": 300000000,
      "fuseBudgetMemoryBytes": 187904819,
      "sidecarLimitMemoryBytes": 268435456,
      "nodeType": "gpu",
      "requiredMetadataTypeCacheBytes": 600,
      "bucketTotalObjects": 3,
      "nodeAllocatableMemoryBytes": 191291998208,
      "bucketTotalDataSizeBytes": 300000000,
      "bucketLocationType": "multi-region",
      "sidecarLimitEphemeralStorageBytes": 0,
      "requiredMetadataStatCacheBytes": 4500,
      "nodeAllocatableEphemeralStorageBytes": 1317908854882,
      "nodeHasEphemeralStorageLSSD": true,
      "fuseBudgetEphemeralStorageBytes": 1120222526649
    }
  },
  ...
}

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שנוצרו במדריך הזה, מבצעים את השלבים הבאים:

  1. מחיקת הפריסה:

    kubectl delete deployment my-deployment -n NAMESPACE

    מחליפים את NAMESPACE במרחב השמות של Kubernetes שבו יצרתם את הפריסה.

  2. מחיקת ה-PersistentVolumeClaim:

    kubectl delete pvc my-pvc -n NAMESPACE

    מחליפים את NAMESPACE במרחב השמות של Kubernetes שבו יצרתם את ה-PVC.

  3. מחיקת נפח האחסון המתמיד:

    kubectl delete pv my-pv

  4. אם השתמשתם בפרופיל gcsfusecsi-serving או הפעלתם ידנית את Anywhere Cache, אתם צריכים לפעול לפי ההוראות להשבתה או מחיקה של מטמון כדי להפסיק את החיובים על מופעי המטמון.

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