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

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

שגיאה 100010105: הגיבוי של PersistentVolumeClaim נכשל – הדיסק שאליו מתבצעת ההפניה על ידי PersistentVolume לא קיים

השגיאה 100010105 מתרחשת כשניסיון לגבות את PersistentVolumeClaim נכשל כי הוא מפנה לדיסק שלא קיים, וכתוצאה מכך מוצגת הודעת השגיאה Failed to backup PersistentVolumeClaim - Disk referenced by PersistentVolume does not exist.

ב-Google Kubernetes Engine, PersistentVolumeClaims מבקשים אחסון מ-PersistentVolumes. PersistentVolume מייצג בתורו חלק מאחסון, לרוב דיסק לאחסון מתמיד ב-Compute Engine. שגיאה יכולה להתרחש כש-PersistentVolumeClaim מאוגד ל-PersistentVolume וההגדרה של PersistentVolume מציינת Persistent Disk ב-Compute Engine. עם זאת, לא ניתן למצוא בפרויקט Google Cloud את הדיסק בפועל עם השם והמיקום שצוינו בהגדרות של PersistentVolume. לכן, אי אפשר להמשיך את הגיבוי של דיסק שלא קיים באמצעות Backup for GKE, והגיבוי נכשל.

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

  1. מזהים את PersistentVolumeClaim וPersistentVolume הבעייתיים. השמות של רשומת PersistentVolumeClaim הבעייתית ושל PersistentVolume המשויך אליה מופיעים בשדה state reason של פעולת הגיבוי שנכשלה ב-Backup for GKE. מומלץ לתעד את PersistentVolumeClaim השם, מרחב השמות שלו והשם של PersistentVolume.

  2. בודקים את PersistentVolume. כדי לתאר את PersistentVolume, משתמשים בשם PersistentVolume שזיהיתם בשדה של סיבת המצב בפקודה הבאה:

    kubectl describe pv PERSISTENTVOLUME_NAME

    מחליפים את PERSISTENTVOLUME_NAME בשם של ה-PersistentVolume.

  3. בפלט, בודקים את הקטע source, במיוחד את הקטע csi. בקטע הזה מתואר VolumeHandle שPersistentVolume מנסה להפנות אליו. לדוגמה:

    Source:
  Type: GCEPersistentDisk (a Persistent Disk resource in Google Compute Engine)
PDName: my-non-existent-disk
FSType: ext4
Partition: 0
ReadOnly: false
            In this example, the PD name is my-non-existent-disk.

    Source:
  Type:       CSI (a Container Storage Interface (CSI) volume)
  Driver:     pd.csi.storage.gke.io
  VolumeHandle: projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
...

    בדוגמה הזו, VolumeHandle מכיל את הנתיב המלא לדיסק, כולל השם והמיקום שלו. לדוגמה, projects/my-gcp-project/zones/us-central1-a/disks/my-disk-name.

  4. משתמשים ב-VolumeHandle שמתקבל מתיאור PersistentVolume כדי לזהות את שם הדיסק והאזור.

  5. מוודאים שהדיסק קיים ב Google Cloud פרויקט באחת מהשיטות הבאות:

    דיסק אזורי

    אם אתם משתמשים בדיסק אזורי, מריצים את הפקודה gcloud compute disks describe באמצעות Google Cloud CLI:

    gcloud compute disks describe DISK_NAME \
    --zone=ZONE_NAME \
    --project=PROJECT_ID

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

    • ‫DISK_NAME: השם של הדיסק שקיבלתם מתיאור PersistentVolume.

    • ‫ZONE_NAME: האזור של הדיסק שקיבלתם מהתיאור של PersistentVolume.

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

    דיסק אזורי

    אם אתם משתמשים בדיסק אזורי, מריצים את הפקודה gcloud compute disks describe באמצעות Google Cloud CLI:

    gcloud compute disks describe DISK_NAME \
    --region=REGION_NAME \
    --project=PROJECT_ID

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

    • ‫DISK_NAME: השם של הדיסק שקיבלתם מתיאור PersistentVolume.

    • ‫REGION_NAME: האזור של הדיסק שמופיע בתיאור PersistentVolume.

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

    אם מופיעה הודעת השגיאה Resource not found או The resource DISK_NAME was not found, הדיסק לא קיים. כדי לפתור את הבעיה, צריך להשתמש באחת מהשיטות הבאות, בהתאם לתרחיש שהכי מתאים לצרכים שלכם:

    • אם הדיסק נמחק בטעות או ששמו שונה בטעות ואתם רוצים לשמור את הנתונים או את PersistentVolumeClaim, או אם PersistentVolume הוגדר עם שם דיסק שגוי, אתם יכולים להשתמש באחת מהשיטות הבאות כדי לפתור את הבעיה:

      • שחזור הדיסק: אם יש לכם גיבוי של הדיסק, שחזרו אותו עם אותו שם ומיקום בדיוק שאליהם מתייחס PersistentVolume.

      • יצירת דיסק חדש: אם שחזור הדיסק לא אפשרי, יוצרים דיסק חדש עם אותו שם ומיקום שמופיעים בהגדרות PersistentVolume.

    • אם אין יותר צורך ב-PersistentVolumeClaim או ב-PersistentVolume, בנתונים שלהם או באפליקציה, מומלץ להסיר את הישות שלא נדרשת:

      • מחיקת PersistentVolumeClaim: מוחקים את PersistentVolumeClaim באמצעות כלי שורת הפקודה kubectl כדי להריץ את הפקודה kubectl delete pvc:
      kubectl delete pvc PVC_NAME -n NAMESPACE

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

      • ‫PVC_NAME: השם של PersistentVolumeClaim שרוצים למחוק.

      • ‫NAMESPACE: מרחב השמות של PersistentVolumeClaim שרוצים למחוק.

    • ה-PersistentVolume עדיין קיים אחרי שמוחקים את ה-PersistentVolumeClaim: אם ה-PersistentVolumeReclaimPolicy של ה-PersistentVolume מוגדר ל-Delete, ה-PersistentVolume נמחק אוטומטית כשמוחקים את ה-PersistentVolumeClaim. אם הערך של persistentVolumeReclaimPolicy הוא Retain, צריך למחוק ידנית את PersistentVolume אחרי שמוחקים את PersistentVolumeClaim. כדי למחוק את PersistentVolume, משתמשים בכלי שורת הפקודה kubectl כדי להריץ את הפקודה kubectl delete pv:

      kubectl delete pv PV_NAME

      מחליפים את PV_NAME בשם של PersistentVolume שרוצים למחוק.

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

שגיאה 100010202: יצירת תמונת מצב של נפח האחסון נכשלה

השגיאה 100010202 מתרחשת כשנכשלת יצירת תמונת מצב של Persistent Disk ב-Compute Engine, וכתוצאה מכך מוצגת הודעת השגיאה Snapshotting volume failed.

פעולת snapshot של Persistent Disk ב-Compute Engine נכשלת אם מצב הצירוף של הדיסק למכונה וירטואלית (VM) משתנה במהלך תהליך יצירת ה-snapshot שהופעל על ידי שירות הגיבוי ל-GKE. דוגמאות לתרחישים נפוצים שגורמים לכך:

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

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

  1. הפעלת תזמון חכם: הגדרת תוכנית הגיבוי באמצעות תזמון חכם (לוח זמנים שמבוסס על RPO). כך המערכת יכולה לנסות שוב באופן אוטומטי שגיאות זמניות בתוך חלון הזמן שצוין, בלי להשפיע על ה-RPO הכולל של תוכנית הגיבוי.

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

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

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

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