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

במאמר הזה נסביר איך לשפר אוטומטית את הביצועים של מנהל ההתקן של ה-CSI של Cloud Storage FUSE ולהאיץ את הגישה לנתונים של עומסי העבודה (workloads) שלכם ל-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, על סמך מאפיינים של קטגוריות או של ספריות משנה, כמו גודל, מספר אובייקטים וסוג המיקום, מגבלות של sidecar והמשאבים הזמינים של הצומת.
• ביצועי קריאה מהירים יותר: כשמשתמשים בפרופיל gcsfusecsi-serving, ‏ GKE מפעיל אוטומטית את Rapid Cache כדי לשפר את ביצועי הקריאה של עומסי העבודה שלכם.
• תובנות לגבי אופטימיזציה של הביצועים: אתם מקבלים תובנות לגבי ההחלטות של האופטימיזציה האוטומטית באמצעות יומנים מובנים שמפרטים את אותות הקלט מהסביבה שלכם ואת ההגדרות שנוצרו על ידי מנהל ההתקן. מידע נוסף זמין במאמר הצגת תובנות לגבי המלצות

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

מגבלות

• אי אפשר להשתמש בפרופילים של Cloud Storage FUSE עם נפחים זמניים של Cloud Storage FUSE CSI.
• הפרופילים לא תומכים בטעינה דינמית, שבה מציינים קו תחתון (‎_) כדי לטעון את כל הקטגוריות שלחשבון השירות של Kubernetes יש גישה אליהן.
• אי אפשר להחליף את תמונת ה-sidecar בתמונת sidecar פרטית בהתאמה אישית. מידע נוסף זמין במאמר בנושא הגדרת תמונה פרטית עבור קונטיינר sidecar.

דרישות

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

עלויות

בנוסף לעלויות הסטנדרטיות של GKE ושל Cloud Storage שמשויכות ל-Cloud Storage FUSE CSI Driver, השימוש בפרופילים של Cloud Storage FUSE כרוך בעלויות הבאות.

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

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

עלויות של Rapid Cache

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

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

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

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

• בוחרים Cloud de Confiance by S3NS אזור שמתאים לצרכים שלכם. למרות שאנחנו ממליצים ליצור את אשכול GKE ואת דלי Cloud Storage באותו אזור כדי לשפר את הביצועים ולצמצם את העלויות, חובה לעשות זאת כשמשתמשים בפרופיל gcsfusecsi-serving או כשמתכננים להפעיל את Rapid Cache.
• מוודאים שיש לכם קטגוריה קיימת של Cloud Storage שמכילה את מערך הנתונים, המודל או נקודות הבדיקה של עומס העבודה של ה-AI/ML. אם צריך ליצור קטגוריה, אפשר לעיין במאמר יצירת קטגוריה.

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

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

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

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

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

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

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

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

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

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

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

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

   gcloud iam roles create gke.gcsfuse.profileUser \
     --project=GCS_PROJECT \
     --title="GKE GCSFuse Profile User" \
     --description="Allows scanning Cloud Storage 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.s3ns-system.iam.gserviceaccount.com" \
     --role="projects/GCS_PROJECT/roles/gke.gcsfuse.profileUser"
   

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

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

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

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

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

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

   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
   

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

   • ‫NAMESPACE: מרחב השמות שבו רוצים לפרוס את ה-Pod.
   • ‫KSA_NAME: השם של Kubernetes ServiceAccount שיצרתם כשהגדרתם גישה לקטגוריות של Cloud Storage.

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

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

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

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

אחרי שיוצרים את ה-PV, פועלים לפי השלבים הבאים כדי לבדוק את הסטטוס של סריקת הדלי ושל המטמון. אין צורך להמתין עד לפריסת ה-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-hns-enabled: true
   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 עדיין סורק את ה-bucket או את ספריית המשנה. ה-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"

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: בפרופיל Serving, המגבלה על המספר הכולל של בלוקים של זיכרון בו-זמני שמשמשים לקריאות עם מאגר זמני. האפשרות הזו עוזרת למנוע ממערכת FUSE לצרוך את כל ה-RAM הזמין כשמציגים כמה בקשות.
• parameters:
  • ‫skipCSIBucketAccessCheck: כשהערך מוגדר ל-"true", מנהל ההתקן של CSI מדלג על בדיקת הגישה הראשונית לקטגוריה. הפרמטר הזה עוזר לצמצם את מספר הקריאות ל-Security Token Service כדי למנוע בעיות פוטנציאליות במכסת השימוש.
  • ‫gcsfuseMetadataPrefetchOnMount: כשהערך מוגדר ל-"true", מנהל ההתקן של CSI מורה על הפעלה של prefetching של מטא-נתונים של אובייקטים מ-Cloud Storage למטמון המקומי ברגע שהנפח מותקן. הפרמטר הזה יכול להאיץ את הגישה הראשונה לקבצים.
  • ‫fuseFileCacheMediumPriority: מגדיר את סדר העדיפויות של אמצעי האחסון שמשמשים את מטמון הקבצים של Cloud Storage FUSE. אפשר לציין העדפות שונות לצמתים עם מעבדי GPU, מעבדי TPU או צמתים למטרות כלליות. אפשרויות המדיה כוללות ram ו-lssd (SSD מקומי, אם הוא זמין ומופעל).
  • ‫fuseMemoryAllocatableFactor: מציינת בפורמט מחרוזת שבר שמגביל את הזיכרון המקסימלי שניתן להקצות למטמון של Cloud Storage FUSE, ביחס לזיכרון הכולל שניתן להקצאה של הצומת ולמגבלת הזיכרון של קובץ ה-sidecar.
  • ‫fuseEphemeralStorageAllocatableFactor: מגביל את השימוש במטמון של Cloud Storage FUSE בשטח אחסון זמני בצומת (כמו SSD מקומי לשמירת קבצים במטמון), ביחס לשטח האחסון הזמני שניתן להקצאה בצומת או לשטח האחסון הזמני של ה-sidecar שמוגבל לשמירה במטמון.
  • ‫bucketScanResyncPeriod: מגדיר את מרווח הזמן שבו מתבצעת סריקה חוזרת של ה-PV כדי לזהות שינויים שבוצעו בקטגוריה של Cloud Storage.
  • ‫bucketScanTimeout: משך הזמן המקסימלי שמותר לפעולת סריקה של קטגוריה אחת. אם הסריקה חורגת מהזמן הזה, יכול להיות שייעשה שימוש בתוצאות חלקיות.
  • ‫anywhereCacheZones: רשימה מופרדת בפסיקים של אזורים נתמכים שבהם נוצרים מטמוני Rapid Cache. לדוגמה, "us-central1-a,us-central1-b". כדי להשתמש בכל האזורים שזמינים באשכול, משתמשים בערך "*". אם מגדירים את ההגדרה הזו לערך "none" או לא מציינים ערך, המטמון המהיר מושבת.
  • ‫anywhereCacheTTL: אורך החיים (TTL) של הנתונים שמאוחסנים במטמון המהיר, שנמדד מהגישה האחרונה. אם משנים את הערך הזה, מופעל עדכון של מופעי Rapid Cache קיימים עם ה-TTL החדש.
  • ‫anywhereCacheAdmissionPolicy: קובע מתי להכניס נתונים למטמון של Rapid Cache אחרי read miss (כשנתונים מבוקשים לא נמצאים במטמון). האפשרויות כוללות את "admit-on-first-miss", שמאפשרת גישה לנתונים במקרה של החמצה ראשונה של קריאה, או את "admit-on-second-miss", שמאפשרת גישה לנתונים רק במקרה של החמצה שנייה של קריאה לאותו אובייקט. אם משנים את הערך הזה, מופעים קיימים של Rapid 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.

תרחישי שימוש נפוצים:

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

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

תרחישי שימוש נפוצים:

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

חוסר התאמה במיקום של Rapid Cache

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

תסמין

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

הסיבה

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

פתרון

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

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

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

תסמין

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

הסיבה

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

פתרון

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

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

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

תסמין

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

הסיבה

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

פתרון

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

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

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

תסמין

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

הסיבה

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

פתרון

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

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

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

kubectl describe pv PV_NAME

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

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

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

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

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

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

• ‫inputSignals: מספר האובייקטים בקטגוריה, גודל הנתונים הכולל ומשאבי הצומת הזמינים (RAM ואחסון זמני).
• ‫decision: הגדלים הסופיים של המטמון שחושבו והאמצעי לאחסון שנבחר (ram או lssd).

{
  "insertId": "INSERT_ID",
  "jsonPayload": {
    "decision": {
      "fileCacheBytes": 300000000,
      "fileCacheMedium": "lssd",
      "metadataStatCacheBytes": 4500,
    },
    "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 | Expand for full details",
    "inputSignals": {
      "requiredFileCacheBytes": 300000000,
      "fuseBudgetMemoryBytes": 187904819,
      "sidecarLimitMemoryBytes": 268435456,
      "nodeType": "gpu",
      "bucketTotalObjects": 3,
      "nodeAllocatableMemoryBytes": 191291998208,
      "bucketTotalDataSizeBytes": 300000000,
      "bucketLocationType": "multi-region",
      "bucketHNSEnabled": true,
      "sidecarLimitEphemeralStorageBytes": 0,
      "requiredMetadataStatCacheBytes": 4500,
      "nodeAllocatableEphemeralStorageBytes": 1317908854882,
      "nodeHasEphemeralStorageLSSD": true,
      "fuseBudgetEphemeralStorageBytes": 1120222526649
    }
  },
  ...
}

הסרת המשאבים

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

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

   kubectl delete deployment my-deployment -n NAMESPACE
   

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

2. מוחקים את PersistentVolumeClaim:

   kubectl delete pvc my-pvc -n NAMESPACE
   

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

3. מחיקת ה-PersistentVolume:

   kubectl delete pv my-pv
   

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

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

• מידע נוסף על הדרייבר של Cloud Storage FUSE CSI
• איך מבצעים אופטימיזציה ידנית של מנהל התקן ה-CSI של Cloud Storage FUSE לשיפור הביצועים