פתרון בעיות שקשורות להרשאות בגיבוי ל-GKE

בדף הזה מתוארות שגיאות הרשאה שאתם עשויים להיתקל בהן כשאתם משתמשים ב-Backup for GKE, דברים שכדאי לקחת בחשבון כשמבצעים את הפעולה ואיך לפתור את השגיאה.

שגיאה 100010101: הגיבוי של PersistentVolumeClaim נכשל – חסר קישור IAM לפרויקט הדייר

השגיאה 100010101 מתרחשת כשניסיון לגבות PersistentVolumeClaim נכשל בגלל חוסר בהרשאת Identity and Access Management (ניהול זהויות וגישה) לפרויקט הדייר, וכתוצאה מכך מופיעה הודעת השגיאה Failed to backup PersistentVolumeClaim - Missing IAM binding for tenant project.

גיבוי ל-GKE יוצר קובצי snapshot של דיסק האחסון המתמיד (Persistent Disk) של אשכול GKE. התמונות נשמרות ב Cloud de Confiance by S3NS פרויקט שלכם, שנקרא גם פרויקט הצרכן, ו- Cloud de Confiance by S3NS יוצר אותן בתוך פרויקט דייר (tenant) שהוא מנהל. פרויקט הדייר קיים בארגון google.com, בנפרד מהארגון שלכם.

לסוכן השירות בפרויקט הדייר נדרשות הרשאות ספציפיות כדי להשתמש במפתח ההצפנה בניהול הלקוח (CMEK) שמצפין את הדיסק הקשיח שאליו מתבצעת הפניה על ידי PersistentVolumeClaim של האשכול. ההרשאה הזו מצפינה ומפענחת את נתוני ה-snapshot. אם לסוכן השירות service-TENANT_PROJECT_NUMBER@compute-system.s3ns-system.iam.gserviceaccount.com אין את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter ב-CMEK של הדיסק, פעולת הגיבוי תיכשל.

כדי לפתור את השגיאה, פועלים לפי ההוראות הבאות:

  1. מוודאים שיש לכם הרשאות IAM מספיקות לשינוי מדיניות IAM במפתח Cloud Key Management Service במסוף Cloud de Confiance , כמו roles/cloudkms.admin או roles/owner.

  2. מאתרים את סוכן השירות של Compute Engine בפרויקט הדייר באמצעות הערך TENANT_PROJECT_NUMBER שנמצא בהודעה status reason של פעולת הגיבוי שנכשלה. לדוגמה: service-TENANT_PROJECT_NUMBER@compute-system.s3ns-system.iam.gserviceaccount.com.

  3. מאתרים את פרטי ה-CMEK הבאים שמשמשים להצפנה של הדיסק לאחסון מתמיד:

    • שם המפתח: השם של מפתח ההצפנה.

    • ‫Key ring: השם של אוסף המפתחות שבו נמצא המפתח.

    • ‫מיקום: המיקום שבו נמצא המפתח. Cloud de Confiance by S3NS לדוגמה, global או us-central1.

  4. כדי להעניק לסוכן השירות של Compute Engine בפרויקט הדייר את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter ב-CMEK, מריצים את הפקודה gcloud kms keys add-iam-policy-binding באמצעות Google Cloud CLI:

    gcloud kms keys add-iam-policy-binding KEY_NAME \
    --keyring KEY_RING \
    --location LOCATION \
    --member "serviceAccount:service-TENANT_PROJECT_NUMBER@compute-system.s3ns-system.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

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

    • ‫KEY_NAME: השם של מפתח ההצפנה.

    • ‫KEY_RING: השם של אוסף המפתחות.

    • ‫LOCATION: Cloud de Confiance by S3NS המיקום של המפתח. לדוגמה, global או us-central1.

    • ‫TENANT_PROJECT_NUMBER: מספר פרויקט הדייר שקיבלתם מההודעה status reason של פעולת הגיבוי שנכשלה.

    אם הפקודה מסתיימת בלי שגיאות, הפלט ייראה כך:

    - members:
- serviceAccount:service-987654321098@compute-system.s3ns-system.iam.gserviceaccount.com
role: roles/cloudkms.cryptoKeyEncrypterDecrypter

  5. מנסים שוב לבצע את פעולת הגיבוי. אם הפעולה עדיין לא מצליחה, אפשר לפנות ל-Cloud Customer Care לקבלת עזרה נוספת.

שגיאה 100010104: הגיבוי של PersistentVolumeClaim נכשל – הפרה של מגבלת מדיניות הארגון במהלך יצירת צילום מצב

השגיאה 100010104 מתרחשת כשניסיון לגבות את PersistentVolumeClaim נכשל בגלל הפרה של מגבלת מדיניות הארגון במהלך יצירת תמונת מצב, וכתוצאה מכך מופיעה הודעת השגיאה Failed to backup PersistentVolumeClaim - Org policy constraint violation while creating snapshot.

גיבוי ל-GKE יוצר קובצי snapshot של דיסק האחסון המתמיד (Persistent Disk) של אשכול GKE. התמונות נשמרות בפרויקט Cloud de Confiance by S3NS , שנקרא גם פרויקט הצרכן, והן נוצרות בפרויקט דייר שמנוהל על ידי Cloud de Confiance by S3NS. פרויקט הדייר קיים בארגון google.com, בנפרד מהארגון שלכם.

מדיניות הארגון קובעת איפה אפשר ליצור משאבי אחסון. השגיאה Constraint constraints/compute.storageResourceUseRestrictions violated מציינת שמשאב או קובץ snapshot מפרים את המדיניות כי הם נוצרו בפרויקט דייר (tenant) שלא נכלל במבנה הארגוני המותר. מכיוון שפרויקט הדייר (tenant) נמצא בארגון של Google, הוא לא נכלל במדיניות שהגדרתם, ולכן הגיבוי נכשל.

כדי לפתור את השגיאה, פועלים לפי ההוראות הבאות:

  1. מאתרים את מדיניות הארגון שמטמיעה את האילוץ constraints/compute.storageResourceUseRestrictions. מידע נוסף על הצגת מדיניות הארגון באמצעות מסוף Cloud de Confiance זמין במאמר הצגת מדיניות הארגון.

  2. משנים את המדיניות constraints/compute.storageResourceUseRestrictions כך שתכלול ברשימת ההיתרים שלה את תיקיית פרויקט הדייר (tenant) folders/77620796932 שבה נעשה שימוש בגיבוי ל-GKE.

  3. אחרי שמוסיפים את התיקייה לרשימת ההיתרים, שומרים את השינויים במדיניות.

  4. אחרי שהמדיניות הארגונית מתעדכנת ומופצת, מה שקורה בדרך כלל תוך כמה דקות, צריך לבדוק מחדש את פעולת הגיבוי. הגיבוי צריך להתבצע בלי להפר את ההגבלות על השימוש במשאבי האחסון. אם הפעולה עדיין לא מצליחה, פנו אל Cloud Customer Care לקבלת עזרה נוספת.

שגיאה 100010106: הגיבוי של PersistentVolumeClaim נכשל – חסר קישור IAM לסוכן השירות של Backup for GKE

השגיאה 100010106 מתרחשת כשניסיון לגבות PersistentVolumeClaim נכשל בגלל חוסר בקישור של ניהול זהויות וגישה (IAM) לסוכן השירות של Backup for GKE, וכתוצאה מכך מוצגת הודעת השגיאה Failed to backup PVC - Missing IAM binding for Backup for GKE service agent.

כדי להצפין ולפענח את הכרכים של דיסקים לאחסון מתמיד, Backup for GKE צריך הרשאות לשימוש במפתח ההצפנה בניהול הלקוח (CMEK) של BackupPlan. אם לסוכן השירות של Backup for GKE אין את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter ב-CMEK שלכם ב-BackupPlan, פעולות הגיבוי ייכשלו.

כדי לפתור את השגיאה, פועלים לפי ההוראות הבאות:

  1. מזהים את סוכן השירות של הגיבוי ל-GKE שמנוהל על ידי Google, שספציפי לפרויקט שלכם. לדוגמה, service-PROJECT_NUMBER@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com. אפשר למצוא את מספר הפרויקט באמצעות השיטות הבאות:

    • משתמשים בלוח הבקרה של הפרויקט במסוף Cloud de Confiance . Cloud de Confiance by S3NS

    • מריצים את הפקודה gcloud projects describe באמצעות Google Cloud CLI:

      gcloud projects describe PROJECT_ID –format="value(projectNumber)"

      מחליפים את PROJECT_ID בשם הייחודי של הפרויקט.

  2. מזהים את פרטי ה-CMEK הבאים:

    • שם המפתח: השם של מפתח ההצפנה.

    • ‫Key ring: השם של אוסף המפתחות שבו נמצא המפתח.

    • מיקום: Cloud de Confiance by S3NS המיקום שבו נמצא מפתח ה-CMEK שלכםBackupPlan. לדוגמה, global או us-central1.

  3. כדי להעניק לסוכן השירות של Backup for GKE את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter במפתח ה-CMEK, מריצים את הפקודה gcloud kms keys add-iam-policy-binding באמצעות Google Cloud CLI:

    gcloud kms keys add-iam-policy-binding KEY_NAME \
    --keyring KEY_RING \
    --location LOCATION \
    --member "serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

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

    • ‫KEY_NAME: השם של מפתח ההצפנה.

    • ‫KEY_RING: השם של אוסף המפתחות.

    • ‫LOCATION: Cloud de Confiance by S3NS המיקום של המפתח. לדוגמה, global או us-central1.

    • ‫PROJECT_NUMBER: מספר הפרויקט ב- Cloud de Confiance by S3NS .

  4. מוודאים שיש לכם את ההרשאות הנדרשות לניהול זהויות והרשאות גישה (IAM) במפתח של Cloud Key Management Service. לדוגמה, roles/cloudkms.admin או roles/owner.

  5. מוודאים שיש לכם את ההרשאות שניתנו. בפלט של הפקודה הקודמת gcloud kms keys add-iam-policy-binding, מחפשים רשומה שדומה לזו:

    -members:
-serviceAccount:service-123456789012@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com
role: roles/cloudkms.cryptoKeyEncrypterDecrypter

  6. אחרי שנותנים את ההרשאות הנדרשות, צריך לבדוק מחדש את פעולת הגיבוי. אם הפעולה לא הושלמה בהצלחה, פנו אל Cloud Customer Care לקבלת עזרה נוספת.

שגיאה 100010107: הגיבוי של PersistentVolumeClaim נכשל – חסר קישור IAM – חשבון שירות של סוכן (KCP)

השגיאה 100010107 מתרחשת כשמנסים לבצע גיבוי באמצעות Backup for GKE, ולסוכן השירות של אשכול Google Kubernetes Engine אין גישה למפתח ההצפנה בניהול הלקוח (CMEK). כתוצאה מכך, מוצגת ההודעה Failed to backup PVC - Missing IAM binding - agent service account (KCP).

סוכן השירות של אשכול Google Kubernetes Engine, בדרך כלל בפורמט service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com, חיוני כדי שאשכול GKE יוכל ליצור אינטראקציה עם שירותים. Cloud de Confiance by S3NSכשתוכנית הגיבוי משתמשת במפתח הצפנה בניהול הלקוח (CMEK). סוכן השירות הזה צריך הרשאות להצפנה ולפענוח של נתוני הגיבוי באמצעות CMEK. אם תפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter חסר בתוכנית הגיבוי ב-CMEK, פעולות הגיבוי שהופעלו מהאשכול ייכשלו עם השגיאה permission denied.

כדי לפתור את השגיאה, פועלים לפי הוראות פתרון הבעיות הבאות:

  1. מוודאים שיש לכם את ההרשאות הנכונות לשינוי מדיניות IAM במפתח Cloud Key Management Service. לדוגמה, cloudkms.admin או roles/owner.

  2. זיהוי סוכן השירות של אשכול Google Kubernetes Engine. סוכן השירות הזה נוצר ומנוהל אוטומטית על ידי Cloud de Confiance by S3NS בשביל אשכולות GKE. לדוגמה, service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com. כדי ליצור את חשבון השירות המלא, צריך את מספר הפרויקט. אפשר למצוא את מספר הפרויקט באחת מהשיטות הבאות:

    • משתמשים בלוח הבקרה של הפרויקט במסוף Cloud de Confiance . Cloud de Confiance by S3NS

    • מריצים את הפקודה gcloud projects describe באמצעות Google Cloud CLI:

      gcloud projects describe PROJECT_ID –-format="value(projectNumber)"

      מחליפים את PROJECT_ID במזהה הפרויקט.

  3. מאתרים את פרטי ה-CMEK הבאים:

    • שם המפתח: השם של מפתח ההצפנה.

    • ‫Key ring: השם של אוסף המפתחות שבו נמצא המפתח.

    • ‫מיקום: המיקום שבו נמצא המפתח. Cloud de Confiance by S3NS לדוגמה, global או us-central1.

  4. הקצאת התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter ברמת CMEK. סוכן השירות של Google Kubernetes Engine צריך הרשאות למפתח ההצפנה שלכם. כדי להעניק את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter ב-CMEK, מריצים את הפקודה gcloud kms key add-iam-policy-binding באמצעות Google Cloud CLI:

    gcloud kms keys add-iam-policy-binding KEY_NAME \
    --keyring KEY_RING \
    --location LOCATION \
    --member "serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

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

    • ‫KEY_NAME: השם של מפתח ההצפנה.

    • ‫KEY_RING: השם של אוסף המפתחות.

    • ‫LOCATION: Cloud de Confiance by S3NS המיקום של המפתח. לדוגמה, global או us-central1.

    • ‫PROJECT_NUMBER: שם הפרויקט.

    הפלט אמור להיראות כך:

     - members:
 - serviceAccount:service-123456789012@container-engine-robot.s3ns-system.iam.gserviceaccount.com
 role: roles/cloudkms.cryptoKeyEncrypterDecrypter
 ```

  5. מנסים שוב לבצע את הפעולה של גיבוי ל-GKE. אם הפעולה ממשיכה להיכשל, אפשר לפנות אל Cloud Customer Care לקבלת עזרה נוספת.

שגיאה 100010109: הגיבוי של PersistentVolumeClaim נכשל – אזור הגיבוי לא מורשה על ידי מדיניות DiskSettings

השגיאה 100010109 מתרחשת כשמיקום הגיבוי שאליו רוצים להעביר את הנתונים לא מורשה על ידי מדיניות מיקום הגישה DiskSettings.

הסבר על השגיאה

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

No permission to read source disk in us-central1 from target snapshot in us-east1.

שלבים לפתרון בעיות

  1. זיהוי אזורי המקור והיעד: בודקים את הודעת השגיאה כדי למצוא את מיקום דיסק המקור (לדוגמה, us-central1) ואת אזור היעד של התמונה (לדוגמה, us-east1) שהגישה אליהם נדחתה.

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

    • לדיסק אזורי (לדוגמה, הוספה של us-east1 כהרשאה לדיסקים ב-us-central1-a):

      gcloud beta compute disk-settings update --access-location-policy=specific-regions --add-access-locations=us-east1 --zone=us-central1-a

    • לדיסק אזורי (לדוגמה, הוספה של us-east1 כהרשאה לדיסקים ב-us-central1):

      gcloud beta compute disk-settings update --access-location-policy=specific-regions --add-access-locations=us-east1 --region=us-central1

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

שגיאה 100020101: הגיבוי של PersistentVolumeClaim נכשל – PersistentVolumeClaim קשור לסוג PersistentVolume שלא נתמך

השגיאה 100020101 מתרחשת כשניסיון לגבות PersistentVolumeClaim נכשל כי PersistentVolumeClaim מקושר לסוג PersistentVolume שלא נתמך. השגיאה גורמת להודעת השגיאה הבאה: PersistentVolumeClaims are bound to PersistentVolumes of unsupported types and cannot be backed up.

השגיאה הזו מתרחשת כשבמהלך פעולת הגיבוי ל-GKE נתקלים ב-PersistentVolumeClaim שקשור ל-PersistentVolume שמשתמש בסוג נפח שלא נתמך לגיבוי נתונים בגיבוי ל-GKE. הגיבוי ל-GKE תומך בעיקר בגיבוי נתונים מנפחי אחסון של Persistent Disk. אם PersistentVolumeClaim מקושר ל-PersistentVolume שהוא לא Persistent Disk, פעולת הגיבוי של הנתונים ב-PersistentVolumeClaim נכשלת.

כדי לפתור את השגיאה, פועלים לפי הוראות פתרון הבעיות הבאות:

  1. כדי לראות את הרשימה של כל PersistentVolumeClaims וPersistentVolumes שמקושרים אליהם, מריצים את הפקודה kubectl get pvc. כדאי לעיין ברשימה הזו כדי לזהות את PersistentVolumes שמגובים על ידי סוגי אמצעי אחסון שלא נתמכים.

    kubectl get pvc --all-namespaces -o wide

  2. כדי לקבוע את סוג הנפח של PersistentVolume שמגובה על ידי סוג נפח שלא נתמך בגיבוי ל-GKE, מריצים את הפקודה kubectl describe pv:

    kubectl describe pv PERSISTENT_VOLUME_NAME

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

    ‫PERSISTENT_VOLUME_NAME: השם של PersistentVolume שיש לו סוג נפח לא נתמך שמופיע כעמודה VOLUME בפלט מהשלב הקודם.

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

    • לדיסקים נתמכים של אחסון מתמיד: הפלט אמור להיראות כך: Source.Driver: pd.csi.storage.gke.io או Source.Type:GCEPersistentDisk.

    • לסוגים שלא נתמכים שגורמים לשגיאה: הפלט יהיה מנהל התקן של דיסק לא קבוע, לדוגמה, Source.Driver:filestore.csi.storage.gke.io.

  3. כדי לפתור את השגיאה, אפשר להשתמש באחת מהשיטות הבאות:

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

    • הפעלת מצב הרשאה בגיבוי ל-GKE: אנחנו ממליצים על השיטה הזו אם לא נדרש גיבוי נתונים לנפחי אחסון שלא נתמכים. אם העברת הנתונים לא אפשרית או לא נחוצה – למשל, אם עוצמת הקול מגובה על ידי שירות חיצוני ואתם מתכננים לצרף אותה מחדש במהלך פעולת השחזור – אתם יכולים להגדיר את תוכנית הגיבוי שלכם ב-Backup for GKE כך שהגיבוי ימשיך במצב מתירני. מידע נוסף על הפעלת מצב הרשאה מלאה זמין במאמר הפעלת מצב הרשאה מלאה בתוכנית גיבוי.

  4. מנסים שוב לבצע את הפעולה של גיבוי ל-GKE. בהתאם לשיטה שבחרתם כדי לפתור את השגיאה, הפעולה 'גיבוי ל-GKE' מתנהגת באופנים הבאים:

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

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

אם הפעולה ממשיכה להיכשל, פנו אל Cloud Customer Care לקבלת עזרה נוספת.

שגיאה 100020104: הגיבוי של PersistentVolumeClaim נכשל – PersistentVolumeClaim לא משויך ל-PersistentVolume

השגיאה 100020104 מתרחשת כשניסיון לגבות PersistentVolumeClaim נכשל כי PersistentVolumeClaim לא מקושר ל-PersistentVolume. השגיאה מובילה להודעת השגיאה הבאה: Failed to backup PVC - PVC Not Bound to a Persistent Volume.

השגיאה הזו מתרחשת כשפעולת הגיבוי של Backup for GKE מנסה לגבות PersistentVolumeClaim שלא נקשר בהצלחה ל-PersistentVolume. לפני שעומס עבודה (workload) שצורכת את ה-PersistentVolumeClaim, כמו Pod, יכול להשתמש בו, צריך לקשר אותו ל-PersistentVolume. לאחר מכן, אפשר לגבות אותו באמצעות Backup for GKE. אם PersistentVolumeClaim נשאר במצב Pending, המשמעות היא שאין PersistentVolume מתאים או שאי אפשר להקצות או לקשר אותו, ולכן פעולת הגיבוי נכשלת. סיבה נפוצה לכך ש-PersistentVolumeClaim נשאר לא מאוגד היא כש-StorageClass המשויך משתמש במצב איגוד WaitForFirstConsumer, אבל אף Pod או עומס עבודה אחר עדיין לא מנסה לצרוך את PersistentVolumeClaim.

כדי לפתור את השגיאה, פועלים לפי הוראות פתרון הבעיות הבאות:

  1. כדי לבדוק את הסטטוס של כל PersistentVolumeClaims באשכול ולזהות את PersistentVolumeClaim שלא קשור, מריצים את הפקודה kubectl get pvc:

    kubectl get pvc --all-namespaces | grep `Pending`

  2. אחרי שמזהים את PersistentVolumeClaim שלא משויך ל-PersistentVolume, מאחזרים מידע על PersistentVolumeClaim שלא משויך על ידי הפעלת הפקודה kubectl describe pvc:

    kubectl describe pvc PVC_NAME -n NAMESPACE_NAME

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

    • ‫PVC_NAME: השם של PersistentVolumeClaim שלא הצליח לגבות.

    • ‫NAMESPACE_NAME: השם של מרחב השמות שבו נמצא PersistentVolumeClaim.

    אחרי שהתיאור מופיע, משתמשים בשדות Status ו-Events כדי לקבוע אם הרכיב PersistentVolumeClaim קשור לרכיב PersistentVolume. אם עדיין לא הצלחתם להבין למה PersistentVolumeClaim לא מקושר ל-PersistentVolume או שלא הצלחתם לפתור את הבעיה שזוהתה, אתם יכולים להפעיל מצב הרשאה בתוכנית הגיבוי. מידע נוסף על הפעלת מצב הרשאה מופיע במאמר בנושא הפעלת מצב הרשאה בתוכנית גיבוי.

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