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

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

מגבלות

דרישות

עלויות

בנוסף לעלויות הסטנדרטיות של 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 למשימה הזו, צריך להתקין ואז לאתחל את ה-CLI של gcloud. אם כבר התקנתם את ה-CLI של gcloud, הריצו את הפקודה gcloud components update כדי לקבל את הגרסה העדכנית. יכול להיות שגרסאות קודמות של ה-CLI של gcloud לא יתמכו בהרצת הפקודות שמופיעות במסמך הזה.
  • בוחרים Google Cloud אזור שמתאים לצרכים שלכם. כדי לשפר את הביצועים ולהוזיל את העלויות, אנחנו ממליצים ליצור את אשכול GKE ואת הקטגוריה של Cloud Storage באותו אזור. אם אתם משתמשים בפרופיל gcsfusecsi-serving או מתכננים להפעיל את Rapid Cache, אתם חייבים לעשות את זה.
  • מוודאים שיש לכם קטגוריה קיימת של Cloud Storage שמכילה את מערך הנתונים, המודל או נקודות הבדיקה של עומס העבודה של ה-AI/ML. אם אתם צריכים ליצור קטגוריה, ראו יצירת קטגוריה.

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

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

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

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

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

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

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

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

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

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

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

האפשרות הזו נדרשת בפרופיל הצגת המודעות או אם משתמשים ב-Rapid Cache. אם אתם משתמשים בפרופיל להצגת מודעות או מתכננים להפעיל ידנית את 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.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.iam.gserviceaccount.com" \
    --role="roles/storage.legacyBucketReader"

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

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

  1. יוצרים מניפסט של PersistentVolume ‏ (PV) שמפנה לאחד מ-StorageClasses של פרופיל 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 מנתחים באופן אוטומטי את הדלי ומסנכרנים את 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 עדיין סורק את הקטגוריה או את ספריית המשנה. ה-Pods יישארו במצב הזה עד שבקר ה-CSI ישלים את הסריקה ויעדכן את ה-PV.

כדי להבין את ההחלטות הספציפיות לגבי ההתאמה שמתועדות על ידי ה-Driver אחרי שה-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: בפרופיל 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" או לא מציינים ערך, Rapid Cache מושבת.
    • ‫anywhereCacheTTL: אורך החיים (TTL) של הנתונים שמאוחסנים במטמון של Rapid Cache, שנמדד מהגישה האחרונה. אם תשנו את הערך הזה, מופעים קיימים של Rapid Cache יעודכנו עם ה-TTL החדש.
    • ‫anywhereCacheAdmissionPolicy: קובע מתי להכניס נתונים למטמון של Rapid Cache אחרי פספוס קריאה (כשהנתונים המבוקשים לא נמצאים במטמון). האפשרויות כוללות את "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 משתמש בערכים האלה כדי לחשב הגדרות אופטימליות של ביצועים בלי לסרוק את הדלי.

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

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

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

פתרון בעיות

המידע הבא יעזור לכם לעקוב אחרי הסטטוס של פרופילים ב-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.

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

תסמין

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

הסיבה

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

רזולוציה

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

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

מנהל ההתקן של Cloud Storage FUSE CSI מתעד החלטות מפורטות לגבי ההגדרות ותובנות לגבי הביצועים. כדי להציג את היומנים האלה ב-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,
    },
    "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
    }
  },
  ...
}

הסרת המשאבים

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

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