פתרון בעיות שקשורות לאחסון בגיבוי ל-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 מציינת דיסק קשיח קבוע ב-Compute Engine. עם זאת, לא ניתן למצוא בפרויקט Cloud de Confiance by S3NS את הדיסק בפועל עם השם והמיקום שצוינו בהגדרה PersistentVolume. לכן, אי אפשר להמשיך את הגיבוי ל-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. כדי לוודא שהדיסק קיים ב Cloud de Confiance by S3NS פרויקט, אפשר להשתמש באחת מהשיטות הבאות:

    דיסק אזורי

    אם אתם משתמשים בדיסק אזורי, מריצים את הפקודה 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: מזהה הפרויקט ב- Cloud de Confiance by S3NS .

    דיסק אזורי

    אם אתם משתמשים בדיסק אזורי, מריצים את הפקודה 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: מזהה הפרויקט ב- Cloud de Confiance by S3NS .

    אם מופיעה הודעת השגיאה 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 מתרחשת כשנכשלת יצירה של צילום מצב של דיסק קשיח ב-Compute Engine, וכתוצאה מכך מוצגת הודעת השגיאה Snapshotting volume failed.

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

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

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

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

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

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

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

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