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

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

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

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

הכלי "גיבוי ל-GKE" יוצר קובצי snapshot של Persistent Disk באשכול GKE. תמונות המצב נמצאות בפרויקט Google Cloud שלכם, שנקרא גם פרויקט הצרכן, ו- Google Cloud יוצר אותן בפרויקט דייר (tenant) שהוא מנהל. פרויקט הדייר (tenant) נמצא בארגון google.com, בנפרד מהארגון שלכם.

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

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

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

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

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

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

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

    • ‫Location: המיקום של המפתח ב- Google Cloud . לדוגמה, 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.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

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

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

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

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

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

    אם הפקודה בוצעה בהצלחה, הפלט ייראה כך:

    - members:
- serviceAccount:service-987654321098@compute-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. התמונות של המצב נמצאות בפרויקט שלכם ב- Google Cloud , שנקרא גם פרויקט צרכן, והן נוצרות בפרויקט דייר (tenant) שמנוהל על ידי Google Cloud. פרויקט הדייר (tenant) נמצא בארגון google.com, בנפרד מהארגון שלכם.

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

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

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

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

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

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

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

השגיאה 100010106 מתרחשת כשניסיון לגבות PersistentVolumeClaim נכשל בגלל שחסר קישור של ניהול זהויות והרשאות גישה (IAM) לסוכן השירות של "גיבוי ל-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 ב-BackupPlan CMEK, פעולות הגיבוי ייכשלו.

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

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

    • משתמשים במרכז הבקרה של הפרויקט Google Cloud במסוף Google Cloud .

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

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

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

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

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

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

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

  3. כדי להקצות לסוכן השירות של "גיבוי ל-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.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

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

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

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

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

    • ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud .

  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.iam.gserviceaccount.com
role: roles/cloudkms.cryptoKeyEncrypterDecrypter

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

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

השגיאה 100010107 מתרחשת כשמנסים לבצע גיבוי של 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.iam.gserviceaccount.com, חיוני כדי שאשכול GKE יוכל ליצור אינטראקציה עם שירותים. Google Cloudכשתוכנית הגיבוי משתמשת במפתח הצפנה בניהול הלקוח (CMEK). סוכן השירות הזה צריך הרשאות כדי להצפין ולפענח את נתוני הגיבוי באמצעות ה-CMEK. אם חסר לתוכנית הגיבוי התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter ב-CMEK, פעולות הגיבוי שהופעלו מהאשכול ייכשלו עם השגיאה permission denied.

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

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

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

    • משתמשים במרכז הבקרה של הפרויקט Google Cloud במסוף Google Cloud .

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

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

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

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

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

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

    • ‫Location: המיקום של המפתח ב- Google Cloud . לדוגמה, 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.iam.gserviceaccount.com" \
    --role roles/cloudkms.cryptoKeyEncrypterDecrypter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. מזהים את אזורי המקור והיעד: בודקים את הודעת השגיאה כדי למצוא את מיקום דיסק המקור (לדוגמה, us-central1) ואת אזור היעד של ה-snapshot (לדוגמה, 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. מריצים את הפקודה kubectl get pvc כדי לראות את כל PersistentVolumeClaims ואת כל PersistentVolumes שמקושרים אליהם. כדאי לעיין ברשימה הזו כדי לזהות את 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 כדי לקבל פרטים על הקצאת נפח האחסון:

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

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

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

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

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

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

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

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

אם הפעולה ממשיכה להיכשל, אפשר לפנות אל 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) צורך, כמו Pod, יכול להשתמש ב-PersistentVolumeClaim, צריך לקשר אותו ל-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, מריצים את הפקודה kubectl describe pvc כדי לאחזר מידע על PersistentVolumeClaim שלא משויך:

    kubectl describe pvc PVC_NAME -n NAMESPACE_NAME

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

    • ‫PVC_NAME: השם של PersistentVolumeClaim שנכשל בגיבוי.

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

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

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