הגדרת קונטיינר sidecar של מנהל התקן ה-CSI של Cloud Storage FUSE ל-GKE

טייס אוטומטי רגילה

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

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

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

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

• מנהל התקן ה-CSI של Cloud Storage FUSE
• קטגוריות של Cloud Storage
• פריסות ונפחי Kubernetes

איך פועל קובץ ה-sidecar

מנהל התקן ה-CSI של Cloud Storage FUSE משתמש בקונטיינר sidecar כדי לטעון קטגוריות של Cloud Storage, וכך מאפשר לאפליקציות של Kubernetes לגשת אליהן כמערכות קבצים מקומיות. קונטיינר ה-sidecar הזה, שנקרא gke-gcsfuse-sidecar, פועל לצד קונטיינר עומס העבודה באותו Pod. כשהדרייבר מזהה את ההערה gke-gcsfuse/volumes: "true" במפרט של Pod, הוא מוסיף באופן אוטומטי את הקונטיינר המשני. הגישה הזו של קונטיינר משני עוזרת לשמור על האבטחה ולנהל את המשאבים ביעילות.

קונטיינר ה-sidecar מטפל במורכבות של טעינת קטגוריות Cloud Storage ומספק גישה למערכת הקבצים לאפליקציות, בלי שתצטרכו לנהל ישירות את זמן הריצה של Cloud Storage FUSE. אפשר להגדיר מגבלות על משאבים עבור קונטיינר ה-sidecar באמצעות הערות כמו gke-gcsfuse/cpu-limit ו-gke-gcsfuse/memory-limit. מודל הקונטיינר מסוג sidecar גם מבטיח שמופע Cloud Storage FUSE קשור למחזור החיים של עומס העבודה, וכך מונע צריכת משאבים שלא לצורך. כלומר, קונטיינר ה-sidecar מסתיים אוטומטית כשהקונטיינרים של עומס העבודה יוצאים, במיוחד בעומסי עבודה של Job או ב-Pods עם RestartPolicy של Never.

תאימות ל-OSS Istio

קונטיינר ה-sidecar של מנהל התקן ה-CSI של Cloud Storage FUSE ו-Istio יכולים להתקיים ולהיפעל בו-זמנית ב-Pod. עם זאת, ב-GKE בגרסה 1.29 ואילך, יכול להיות שתיתקלו בבעיות באימות אם Cloud Storage FUSE ינסה להתחבר לשרת המטא-נתונים לפני ששרת ה-proxy של Istio יהיה מוכן. אם נתקלים בבעיות אימות כאלה, אפשר לפתור את הבעיה על ידי הוספת traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32 אל metadata.annotations במפרט ה-Pod. ההערה הזו מגדירה את Istio כך שכתובת ה-IP של שרת המטא-נתונים של GKE לא תיכלל בהפניה האוטומטית.

הערה: ב-Cloud Service Mesh אי אפשר להריץ כמה קונטיינרים משניים (sidecar). מידע נוסף זמין במאמר בנושא מגבלות של Cloud Service Mesh.

הגדרת מאגר כתיבה בהתאמה אישית

‫Cloud Storage FUSE מבצע כתיבה בשלבים בספרייה מקומית, ואז מעלה את הנתונים ל-Cloud Storage בפעולות close או fsync.

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

אתם יכולים לציין כל סוג אחסון שנתמך על ידי מנהל התקן ה-CSI של Cloud Storage FUSE לשמירת קבצים במטמון, כמו SSD מקומי, אחסון מבוסס דיסק מתמשך ודיסק RAM (זיכרון). ‫GKE ישתמש באמצעי האחסון שצוין כדי לשמור נתונים זמנית לפני כתיבתם לקובץ. מידע נוסף על האפשרויות האלה

כדי להשתמש בנפח מאגר מותאם אישית שמגובה בדיסק לאחסון מתמיד, צריך לציין fsGroup שאינו אפס ב-securityContext של ה-Pod. בשלב הזה מעניקים לקונטיינר המשני (sidecar) שאינו ברמה הבסיסית (root) את הרשאות הקריאה או הכתיבה הנדרשות לנפח האחסון. ההגדרה הזו לא נדרשת אם ה-PVC טוען קטגוריות של Cloud Storage כנפחים קבועים באמצעות מנהל התקן ה-CSI של Cloud Storage FUSE.

בדוגמה הבאה אפשר לראות איך משתמשים ב-PersistentVolumeClaim מוגדר מראש כנפח של המאגר:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-buffer
    persistentVolumeClaim:
      claimName: BUFFER_VOLUME_PVC

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

• ‫FS_GROUP: מזהה fsGroup.
• ‫BUFFER_VOLUME_PVC: השם המוגדר מראש של ה-PVC.

הגדרת נפח מטמון קריאה בהתאמה אישית

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

התרחיש הזה רלוונטי אם צריך להחליף את עוצמת הקול emptyDir שמוגדרת כברירת מחדל ב-Cloud Storage FUSE כדי לשמור את הקבצים במטמון בפעולות קריאה. אפשר לציין כל סוג אחסון שנתמך על ידי GKE, כמו PersistentVolumeClaim, ו-GKE ישתמש בנפח שצוין לשמירת קבצים במטמון. האפשרות הזו שימושית אם אתם צריכים לשמור במטמון קבצים בגודל של יותר מ-10 GiB באשכולות Autopilot.

כדי להשתמש בנפח מטמון מותאם אישית שמגובה על ידי דיסק לאחסון מתמיד, צריך לציין ערך שאינו אפס fsGroup ב-securityContext של ה-Pod. בשלב הזה מקצים את הרשאות הקריאה או הכתיבה הנדרשות לנפח עבור קונטיינר sidecar שאינו root. ההגדרה הזו לא נדרשת אם ה-PVC שלכם טוען קטגוריות של Cloud Storage כנפחי אחסון קבועים באמצעות מנהל התקן ה-CSI של Cloud Storage FUSE.

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

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-cache
    persistentVolumeClaim:
      claimName: CACHE_VOLUME_PVC

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

• ‫FS_GROUP: מזהה fsGroup.
• ‫CACHE_VOLUME_PVC: השם שהוגדר מראש של PersistentVolumeClaim.

הגדרת אימג' פרטי עבור קונטיינר sidecar

בקטע הזה מוסבר איך להשתמש בקובץ אימג' של קונטיינר משני (sidecar) אם אתם מארחים אותו ב-Container Registry פרטי. התרחיש הזה רלוונטי אם אתם צריכים להשתמש בצמתים פרטיים מטעמי אבטחה.

כדי להגדיר ולצרוך את קובץ האימג' של קונטיינר ה-sidecar הפרטי, בצעו את השלבים הבאים:

1. כדי למצוא קובץ אימג' של קונטיינר תואם של sidecar ציבורי, אפשר לעיין בטבלת התאימות הזו של GKE.
2. מושכים אותו לסביבה המקומית ודוחפים אותו למאגר הפרטי של מאגר קונטיינרים.

3. במניפסט, מציינים קונטיינר בשם gke-gcsfuse-sidecar עם השדה image בלבד. מערכת GKE תשתמש בקובץ האימג' של קונטיינר ה-sidecar שצוין כדי להתכונן להחדרת קונטיינר ה-sidecar.

   לדוגמה:

   apiVersion: v1
   kind: Pod
   metadata:
     annotations:
       gke-gcsfuse/volumes: "true"
   spec:
     containers:
     - name: gke-gcsfuse-sidecar
       image: PRIVATE_REGISTRY/gcs-fuse-csi-driver-sidecar-mounter:PRIVATE_IMAGE_TAG
     - name: main # your main workload container.
   

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

   • ‫PRIVATE_REGISTRY: Container Registry פרטי. לדוגמה, us-central1-docker.pkg.dev/my-project/my-registry.
   • ‫PRIVATE_IMAGE_TAG: תג של קובץ אימג' פרטי של קונטיינר sidecar. לדוגמה, v1.17.1-gke.1.

הגדרת משאבים של קונטיינר sidecar

כברירת מחדל, מאגר התגים gke-gcsfuse-sidecar מוגדר עם בקשות ועם מגבלות המשאבים הבאות עבור אשכולות רגילים ואשכולות במצב טייס אוטומטי:

בקשות:

• ‫250m CPU
• זיכרון בנפח 256MiB
• אחסון זמני בנפח ‎5 GiB

מגבלות (גרסת GKE‏ 1.29.1-gke.1670000 ואילך):

• מעבד ללא הגבלה
• זיכרון ללא הגבלה
• אחסון זמני ללא הגבלה

מגבלות (לפני גרסה 1.29.1-gke.1670000 של GKE):

• ‫250m CPU
• זיכרון בנפח 256MiB
• אחסון זמני בנפח ‎5 GiB

כברירת מחדל, מאגר התגים gke-gcsfuse-metadata-prefetch מוגדר עם בקשות ועם מגבלות המשאבים הבאות עבור אשכולות רגילים ואשכולות במצב טייס אוטומטי:

בקשות:

• ‫10 דקות של שימוש במעבד (CPU)
• זיכרון בנפח ‎10 MiB
• נפח אחסון זמני של ‎10 MiB

מגבלות:

• ‫50m CPU
• זיכרון בנפח 250 MiB
• אחסון זמני ללא הגבלה

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

• קלאסטרים רגילים: אם מוגדרת אחת מהבקשות או המגבלות ולא מוגדרת השנייה, הבקשות והמגבלות של המשאבים של ה-Pods יוגדרו כזהות. אם גם הבקשה וגם המגבלות מוגדרות, ה-Pods משתמשים בבקשות ובמגבלות המדויקות של המשאבים שציינתם. אם לא מגדירים ערכים, המשאבים שמוגדרים כברירת מחדל (כפי שמתואר למעלה) מוחלים ישירות.
• קלאסטרים של Autopilot: אם אחת מהבקשות או מהמגבלות מוגדרת והשנייה לא מוגדרת, מגבלות המשאבים והבקשות של ה-Pods יוגדרו זהות. במאמר הגדרת מגבלות משאבים ב-Autopilot מוסבר איך שינוי ברירות המחדל של המשאבים וערכי ברירת המחדל של המשאבים שהוגדרו משפיעים על ההתנהגות של ה-Pod.

כדי להחליף את ערכי ברירת המחדל של מאגר התגים gke-gcsfuse-sidecar, אפשר לציין את ההערה gke-gcsfuse/[cpu-limit|memory-limit|ephemeral-storage-limit|cpu-request|memory-request|ephemeral-storage-request] כמו בדוגמה הבאה:

כדי לשנות את ערכי ברירת המחדל של מאגר gke-gcsfuse-metadata-prefetch (החל מגרסה 1.32.3-gke.1717000 של GKE ואילך), אפשר לציין את ההערה gke-gcsfuse/[metadata-prefetch-cpu-limit|metadata-prefetch-memory-limit|metadata-prefetch-ephemeral-storage-limit|metadata-prefetch-cpu-request|metadata-prefetch-memory-request|metadata-prefetch-ephemeral-storage-request], כמו בדוגמה הבאה:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"

    # gke-gcsfuse-sidecar overrides
    gke-gcsfuse/cpu-limit: "10"
    gke-gcsfuse/memory-limit: 10Gi
    gke-gcsfuse/ephemeral-storage-limit: 1Ti
    gke-gcsfuse/cpu-request: 500m
    gke-gcsfuse/memory-request: 1Gi
    gke-gcsfuse/ephemeral-storage-request: 50Gi

    # gke-gcsfuse-metadata-prefetch overrides
    gke-gcsfuse/metadata-prefetch-cpu-limit: "10"
    gke-gcsfuse/metadata-prefetch-memory-limit: 10Gi
    gke-gcsfuse/metadata-prefetch-ephemeral-storage-limit: 1Ti
    gke-gcsfuse/metadata-prefetch-cpu-request: 500m
    gke-gcsfuse/metadata-prefetch-memory-request: 1Gi
    gke-gcsfuse/metadata-prefetch-ephemeral-storage-request: 50Gi

אפשר להשתמש בערך "0" כדי לבטל את ההגדרה של כל המגבלות או הבקשות של המשאבים, אבל חשוב לדעת שבקונטיינר gke-gcsfuse-sidecar כבר בוטלה ההגדרה של כל המגבלות (cpu-limit,‏ memory-limit ו-ephemeral-storage-limit), ובקונטיינר gke-gcsfuse-metadata-prefetch כבר בוטלה ההגדרה של ephemeral-storage-limit. לכן, הגדרת המגבלות האלה ל-"0" באשכול עם GKE בגרסה 1.32.3-gke.1717000 ואילך לא תניב תוצאה.

לדוגמה, אם מגדירים את gke-gcsfuse/metadata-prefetch-memory-limit: "0", המשמעות היא שרוצים לבטל את ההגדרה של מגבלת הזיכרון של מאגר התגים gke-gcsfuse-metadata-prefetch. האפשרות הזו שימושית כשאתם לא מצליחים להחליט על כמות המשאבים שדרושה לתכונה של אחזור מראש של מטא-נתונים עבור עומסי העבודה שלכם, ואתם רוצים לאפשר לאחזור מראש של מטא-נתונים לצרוך את כל המשאבים הזמינים בצומת.

הערה: אם משתמשים בערך "0" כדי לבטל את ההגדרה של מגבלות המשאבים או הבקשות של קונטיינר משני (sidecar) באשכולות Autopilot, ההתנהגות של הפודים משתנה בהתאם לכמה גורמים, כולל אם האשכול תומך ב-bursting. פרטים נוספים זמינים במאמר בנושא הגדרת מגבלות משאבים ב-Autopilot.

הערה: אובייקט LimitRange יבטל גם את ערכי ברירת המחדל וגם את הערכים עם ההערות.

(אופציונלי) ניתוח הביצועים באמצעות Cloud Profiler

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

השימוש ב-Cloud Profiler הוא אופציונלי ומיועד לאדמינים שזקוקים לניתוח מפורט של הביצועים. ‫Cloud Profiler מופעל כברירת מחדל עבור מנהל ההתקן של הצומת. בקונטיינרים משניים (sidecar), זו תכונה שצריך להפעיל באופן ידני.

לפני שמפעילים את Cloud Profiler

כדי להשתמש ב-Cloud Profiler עם מנהל התקן ה-CSI של Cloud Storage FUSE, צריך לוודא שאתם משתמשים ב-GKE בגרסה 1.36.0-gke.2403000 ואילך. לפני שמפיקים פרופילים, צריך להפעיל את Cloud Profiler API ולהגדיר את הרשאות ה-IAM המתאימות לרכיבים שרוצים ליצור להם פרופיל.

הפעלת ה-API

הפעלת Cloud Profiler API

מתן הרשאות למנהל ההתקן של הצומת

כדי לשלוח נתוני פרופיילינג ל-Cloud Profiler, מנהל ההתקן של הצומת צריך הרשאות IAM. מכיוון שדרייבר הצומת פועל ברשת המארח כברירת מחדל, הוא מאומת באמצעות חשבון השירות של IAM שמשויך לצומת GKE, במקום להשתמש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE.

מקצים את התפקיד roles/cloudprofiler.agent לחשבון השירות של הצומת:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/cloudprofiler.agent \
    --member=serviceAccount:NODE_SERVICE_ACCOUNT

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫NODE_SERVICE_ACCOUNT: חשבון השירות ב-IAM שמשמש את הצמתים ב-GKE. בדרך כלל זהו חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, למשל PROJECT_NUMBER-compute@, אלא אם הצמתים מוגדרים לשימוש בחשבון שירות אחר.

מתן הרשאות לקונטיינר sidecar

כדי לשלוח נתוני פרופילים ל-Cloud Profiler, צריך הרשאות IAM לתהליך gcsfuse ולמאגר ה-sidecar. האימות של הרכיבים האלה מתבצע באמצעות איחוד שירותי אימות הזהות של עומסי עבודה ב-GKE, שמשתמש בחשבון השירות של Kubernetes ‏ (KSA) שמשויך לקבוצת ה-Pod של עומס העבודה.

מקצים את התפקיד roles/cloudprofiler.agent לחשבון ה-KSA שבו משתמש ה-Pod:

gcloud projects add-iam-policy-binding projects/PROJECT_ID \
    --role=roles/cloudprofiler.agent \
    --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME \
    --condition=None

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

• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud .
• ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud .
• ‫NAMESPACE: השם של מרחב השמות של Kubernetes.
• ‫KSA_NAME: השם של חשבון השירות של Kubernetes.

הערה: אם ה-Pod של עומס העבודה משתמש ברשת המארחת אבל לא מציין את מאפיין הנפח hostNetworkPodKSA, צריך להקצות את התפקיד cloudprofiler.agent ישירות לחשבון השירות של הצומת הבסיסי.

הפעלה של Cloud Profiler לעומסי עבודה של sidecar

כדי ליצור פרופילים ל-sidecar mounter ולתהליך gcsfuse הבסיסי, מגדירים את מאפיין הנפח enableCloudProfilerForSidecar ל-"true" במפרט של עומס העבודה. כשמפעילים את Cloud Profiler בקונטיינר המשני, הוא מופעל באופן אוטומטי גם בתהליך gcsfuse הבסיסי.

מחליפים את BUCKET_NAME בשם הקטגוריה שלכם ב-Cloud Storage:

volumes:
  - name: gcs-fuse-csi-ephemeral
    csi:
      driver: gcsfuse.csi.storage.gke.io
      volumeAttributes:
        bucketName: BUCKET_NAME
        enableCloudProfilerForSidecar: "true"

הצגת נתוני פרופיל

כדי לראות את נתוני הפרופיילינג, נכנסים לדף Cloud Profiler במסוף Google Cloud . כדי לנתח את הרכיב שאתם בודקים, השתמשו במסנן Service name באופן הבא:

רכיב	סינון לפי שם שירות
Node Driver	gcs-fuse-csi-driver
Sidecar Mounter	gke-gcsfuse-sidecar
GCSFuse	gcsfuse

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

(אופציונלי) השבתת פרופיילינג של GCSFuse

כברירת מחדל, הפעלת פרופילים עבור קונטיינר sidecar יוצרת גם פרופילים של תהליך gcsfuse הבסיסי. יכול להיות שתרצו להשבית את gcsfuse יצירת הפרופיל כדי לצמצם את התקורה של המשאבים או כדי להתמקד בניתוח הביצועים של קונטיינר ה-sidecar בלבד.

כדי להשבית את יצירת הפרופיל של gcsfuse ולהשאיר את יצירת הפרופיל של sidecar מופעלת, מוסיפים את enable-cloud-profiler=false למאפיין mountOptions במפרט עוצמת הקול.

מחליפים את BUCKET_NAME בשם הקטגוריה שלכם ב-Cloud Storage:

volumes:
  - name: gcs-fuse-csi-ephemeral
    csi:
      driver: gcsfuse.csi.storage.gke.io
      volumeAttributes:
        bucketName: BUCKET_NAME
        enableCloudProfilerForSidecar: "true"
        mountOptions: "enable-cloud-profiler=false"

הגדרת רמת הפירוט של הרישום ביומן

כברירת מחדל, מאגר התגים gke-gcsfuse-sidecar יוצר יומנים ברמות info ו-error. עם זאת, לצורך ניפוי באגים או ניתוח מפורט יותר, יכול להיות שתצטרכו לשנות את דרגת המלל של הרישום ביומן. בקטע הזה מוסבר איך להגדיל או להקטין את רמת הרישום ביומן.

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

במניפסט של Pod היעד, כוללים את ההגדרות הבאות:

      volumeAttributes:
        bucketName: BUCKET_NAME
        mountOptions: "implicit-dirs"
        gcsfuseLoggingSeverity:  LOGGING_SEVERITY

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

  mountOptions: "logging:severity:LOGGING_SEVERITY"

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

• ‫BUCKET_NAME: השם של הקטגוריה שלכם ב-Cloud Storage.
• LOGGING_SEVERITY: אחד מהערכים הבאים, בהתאם לדרישות שלכם:
  • trace
  • debug
  • info
  • warning
  • error

אחרי שה-Pod נפרס, מנהל ההתקן של CSI מפעיל את gcsfuse עם רמת הרישום החדשה שהוגדרה.

אפשר להשתמש במסנן הבא כדי לוודא שרמת החומרה של הרישום חלה:

resource.labels.container_name="gke-gcsfuse-sidecar"
resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
"severity:"

פתרון בעיות

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

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

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