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

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

שגיאה 200010301: הפעולה 'שחזור' לא הושלמה בגלל שירות webhook של קבלה שלא זמין

השגיאה 200010301 מתרחשת כשניסיון להשלים פעולת שחזור נכשל כי שירות של webhook להרשאה, שנקרא גם קריאה חוזרת (callback) של HTTP, לא זמין. כתוצאה מכך מוצגת הודעת השגיאה הבאה. הודעת השגיאה מציינת ששרת ה-API של GKE ניסה ליצור קשר עם webhook של בקרת כניסה בזמן ניסיון לשחזר משאב, אבל השירות שתומך ב-webhook לא היה זמין או לא נמצא:

  resource [/example-group/ClusterSecretStore/example-store] restore failed:

  Internal error occurred: failed calling webhook "example-webhook.io":
  failed to call webhook: Post "https://example-webhook.example-namespace.svc:443/validate-example": service "example-webhook" not found.

השגיאה הזו מתרחשת כשמשאב ValidatingAdmissionWebhook או MutatingAdmissionWebhook GKE פעיל באשכול היעד, אבל שרת GKE API לא יכול להגיע לנקודת הקצה שהוגדרה ב-webhook. ה-webhooks של בקרת הכניסה מיירטים בקשות לשרת GKE API, וההגדרה שלהם מציינת איך שרת GKE API צריך לשלוח שאילתות לבקשות.

ה-clientConfig של ה-webhook מציין את ה-backend שמטפל בבקשות הגישה, שיכול להיות שירות אשכול פנימי או כתובת URL חיצונית. הבחירה בין שתי האפשרויות האלה תלויה בדרישות התפעוליות והארכיטקטוניות הספציפיות של ה-webhook. יכול להיות שפעולת השחזור נכשלה מהסיבות הבאות, בהתאם לסוג האפשרות:

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

• כתובות URL חיצוניות: נקודת הקצה החיצונית לא זמינה באופן זמני בגלל בעיות בקישוריות לרשת בין אשכול GKE לבין נקודת הקצה החיצונית, או בגלל בעיות בפענוח DNS או בכללי חומת אש.

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

1. מזהים את ה-webhook שנכשל שמוזכר בהודעת השגיאה. לדוגמה, failed calling webhook "...".

2. בודקים את ה-webhook באמצעות הפקודה kubectl get validatingwebhookconfigurations:

   kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   מחליפים את WEBHOOK_NAME בשם של ה-webhook שזוהה בהודעת השגיאה.

   אפשר גם להריץ את הפקודה kubectl get mutatingwebhookconfigurations כדי לבדוק את ה-webhook:

   kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   מחליפים את WEBHOOK_NAME בשם של ה-webhook שזוהה בהודעת השגיאה.

3. מבצעים את השלבים הבאים לפתרון בעיות בהתאם לסוג ההגדרה:

   מבוסס על שירותים clientConfig

   כדי להגדיר סדר שחזור מותאם אישית, משנים את המשאב RestorePlan כך שיכלול RestoreOrder עם GroupKindDependency רשומות. כך ניתן לשחזר את הרכיבים שתומכים ב-webhook, כמו Deployment,‏ StatefulSet או Service, ולהכין אותם לפני ValidatingWebhookConfiguration או MutatingWebhookConfiguration.

   הוראות להגדרת סדר שחזור מותאם אישית מופיעות במאמר הגדרת סדר שחזור של משאבים במהלך השחזור.

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

   1. יוצרים משאב Restore באמצעות הגיבוי על ידי הגדרת פעולת השחזור עם מסנן שחזור מפורט שיכלול את המשאבים הספציפיים שנדרשים כדי שה-webhook יפעל, למשל Namespaces,‏ Deployments,‏ StatefulSets או Services.

      מידע נוסף על הגדרת השחזור באמצעות מסנן שחזור מפורט זמין במאמר הפעלת שחזור מפורט.

   2. יוצרים עוד משאב Restore לפעולת הגיבוי ומגדירים את שאר המשאבים שבחרתם.

   clientConfig על סמך כתובת URL

   1. צריך לוודא שנקודת הקצה החיצונית של HTTPS פעילה, נגישה ופועלת בצורה תקינה.

   2. מוודאים שיש קישוריות לרשת מהצמתים ומישור הבקרה של אשכול GKE לכתובת ה-URL החיצונית. יכול להיות שתצטרכו גם לבדוק את כללי חומת האש, למשל אם אתם משתמשים בענן וירטואלי פרטי, בשרת מקומי או בספק שירותי ענן שמארח את ה-webhook, את מדיניות הרשת ואת פענוח ה-DNS.

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

שגיאה 200010302: השלמת פעולת השחזור נכשלה בגלל בקשה ליצירת משאב שנדחתה

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

  [KubeError]; e.g. resource

  [/example-namespace/example-api/ExampleResource/example-name]

  restore failed: admission webhook "example-webhook.example.com" denied the request: {reason for denial}

השגיאה הזו נגרמת בגלל ההגדרה שמוגדרת באשכול GKE של היעד, שיש לו ValidatingAdmissionWebhook או MutatingAdmissionWebhook שמחילים כללים ספציפיים על יצירה ושינוי של משאבים, וחוסמים את בקשת יצירת המשאבים. לדוגמה, webhook מונע יצירה של משאב כי משאב קשור אבל סותר כבר קיים באשכול. לדוגמה, יכול להיות ש-webhook יסרב ליצור פריסה אם היא כבר מנוהלת על ידי משאב HorizontalPodAutoscaler GKE API.

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

1. מזהים את ה-webhook שדוחה את הבקשה באמצעות הודעת השגיאה שמופיעה כשפעולת השחזור נכשלת. לדוגמה, webhook WEBHOOK_NAME denied the request הודעת השגיאה מכילה את הפרטים הבאים:

   • השם של ה-webhook: השם של ה-webhook שדחה את הבקשה.

   • הסיבה לדחייה: הסיבה הספציפית לדחיית הבקשה.

2. בודקים את ה-webhook באמצעות הפקודה kubectl get validatingwebhookconfigurations:

   kubectl get validatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   מחליפים את WEBHOOK_NAME בשם של ה-webhook שצוין בהודעת השגיאה.

   אפשר גם להריץ את הפקודה kubectl get mutatingwebhookconfigurations כדי לבדוק את ה-webhook:

   kubectl get mutatingwebhookconfigurations WEBHOOK_NAME -o yaml
   

   מחליפים את WEBHOOK_NAME בשם של ה-webhook שזיהיתם בהודעת השגיאה.

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

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

שגיאה 200060202: המערכת לא הצליחה להשלים את פעולת השחזור בגלל משאב GKE חסר במהלך אימות עומס העבודה

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

  Workload Validation Error: [KIND] "[NAME]" not found

לדוגמה, Example: Workload Validation Error: pods "jenkins-0" not found

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

• מחיקה ידנית: משתמש או אדמין מחקו ידנית את המשאב באמצעות kubectl או כלים אחרים Cloud de Confiance by S3NS .

• אוטומציה חיצונית: בקרי GitOps כמו Config Sync,‏ ArgoCD,‏ Flux, סקריפטים בהתאמה אישית או כלים אחרים לניהול אשכולות ביטלו את השינוי במשאב או מחקו אותו כדי להתאים למצב הרצוי במאגר.

• בקרי GKE: בקר GKE מחק משאב כי הוא מתנגש עם משאבים או מדיניות אחרים, או ששרשרת OwnerReference מובילה לאיסוף פסולת, או שתהליך הניקוי האוטומטי של GKE מחק משאבים תלויים כשמשאב owner שלהם נמחק.

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

1. מזהים את המשאב שחסר באמצעות הודעת השגיאה שמופיעה כשפעולת השחזור לא מסתיימת.

2. כדי לאתר את מרחב השמות שאליו המשאב שייך, משתמשים באחת מהשיטות הבאות:

   • יומני ביקורת של GKE: בודקים את יומני הביקורת של GKE שנוצרו כשניסיתם לבצע את פעולת השחזור. אפשר לסנן את היומנים כדי לראות פעולות מחיקה במשאבים Kind ו-Name. הרשומה ביומן הביקורת מכילה את מרחב השמות המקורי.

   • פרטי הגיבוי: בודקים את היקף פעולת השחזור ואת התוכן של הגיבוי. באינדקס הגיבוי מוצג מרחב השמות המקורי של המשאב. אפשר גם לבדוק אם RestorePlan מכיל TransformationRule שמציין כללים לשחזור המשאב במרחב השמות שתבחרו.

   • חיפוש בכל מרחבי השמות: מריצים את הפקודה kubectl get כדי לחפש את המשאב בכל מרחבי השמות:

     kubectl get KIND --all-namespaces | grep NAME
     

     מחליפים את KIND ואת NAME בערכים מהודעת השגיאה. אם המשאב עדיין קיים, הפקודה הזו תציג את מרחב השמות שלו.

3. מריצים את הפקודה kubectl get כדי לוודא שהמחיקה בוצעה:

   kubectl get KIND NAME -n [NAMESPACE]
   

   מחליפים את KIND ואת NAME בערכים מהודעת השגיאה. אמורה להופיע הודעת שגיאה.not found

4. כדי לבדוק את הסיבה למחיקה, אפשר להשתמש באחת מהשיטות הבאות:

   • יומני ביקורת של GKE: זיהוי הישות שהנפיקה את בקשת המחיקה. לדוגמה, המשתמש, חשבון השירות או הבקר.

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

   • בדיקת אירועים קשורים: כדי לבדוק אירועים של GKE במרחב השמות שנקבע, מריצים את הפקודה kubectl get events:

     kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'
     

     מחליפים את NAMESPACE_NAME בשם של מרחב השמות.

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

6. אפשר לשחזר את המשאב החסר באחת מהשיטות הבאות:

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

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

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

שגיאה 200060201: הפעולה נכשלה בגלל פסק זמן לאימות עומס העבודה

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

Workload Validation Error: Timedout waiting for workloads to be ready - [namespace/workload_name, ...]

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

• בלוקאל Pods: ‏status.Phase הוא Running

• במאפיין Deployments: הערך status.ReadyReplicas שווה לערך spec.Replicas

• במאפיין StatefulSets: הערך status.ReadyReplicas שווה לערך spec.Replicas

• במאפיין DaemonSets: הערך status.NumberReady שווה לערך status.DesiredNumberScheduled

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

1. מזהים את עומסי העבודה שלא נמצאים במצב ready בהודעת השגיאה שבה מפורטים עומסי העבודה ומרחבי השמות שלהם שלא הצליחו להיכנס למצב ready.

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

   kubectl describe WORKLOAD_TYPE WORKLOAD_NAME -n NAMESPACE_NAME
   kubectl get pods -n NAMESPACE_NAME -l SELECTOR_FOR_WORKLOAD
   

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

   • ‫WORKLOAD_TYPE: סוג עומס העבודה, לדוגמה: Deployment,‏ StatefulSet או DaemonSet.

   • ‫WORKLOAD_NAME: השם של מופע עומס העבודה הספציפי.

   • ‫NAMESPACE_NAME: מרחב השמות שבו נמצא עומס העבודה.

   • ‫SELECTOR_FOR_WORKLOAD: בורר התוויות כדי למצוא את Pods שמשויך לעומס העבודה. לדוגמה, app=my-app.

   לפודים בתוך סוגי עומסי עבודה של Deployments או StatefulSets, בודקים את הסטטוס של פודים ספציפיים על ידי הפעלת הפקודה kubectl describe pod:

   kubectl describe pod POD_NAME -n NAMESPACE_NAME
   

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

   • ‫POD_NAME: השם של הפוד הספציפי.

   • ‫NAMESPACE_NAME: מרחב השמות שבו נמצא ה-Pod.

3. בקטע Events, מנתחים את האירועים והיומנים בפלט describe ומאתרים את המידע הבא:

   • ‫ImagePullBackOff / ErrImagePull: מציין שיש בעיות באחזור תמונות של קונטיינרים.

   • ‫CrashLoopBackOff: מציין שהקונטיינרים מתחילים לפעול וקורסים.

4. בקטע Containers, מנתחים את היומנים של מאגר התגים בפלט describe כדי למצוא את שם מאגר התגים באמצעות הפעלת הפקודה kubectl logs:

   kubectl logs POD_NAME -n NAMESPACE_NAME -c CONTAINER_NAME
   

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

   • ‫POD_NAME: השם של הפוד הספציפי.

   • ‫NAMESPACE_NAME: מרחב השמות שבו נמצא ה-Pod.

   • ‫CONTAINER_NAME: השם של הקונטיינר ב-Pod.

   לפי הפלט של describe, יש כמה סיבות לכך שה-pod לא מופיע בפלט של המשאב, כולל:

   • כשלים בבדיקת המוכנות: בדיקות המוכנות של הקונטיינר לא מצליחות.

   • בעיות במשאבים: אין מספיק מעבד (CPU), זיכרון או משאבים אחרים באשכול, או שהגעתם למגבלות המכסה.

   • בעיות בקונטיינר init: כשלים בקונטיינרים init שמונעים את ההפעלה של הקונטיינרים הראשיים.

   • שגיאות הגדרה: שגיאות ב-ConfigMaps, ב-Secrets או במשתני הסביבה.

   • בעיות ברשת: Pods לא מצליחים לתקשר עם השירותים הנדרשים.

5. בודקים את המשאבים של אשכול GKE כדי לוודא שיש לאשכול GKE מספיק קיבולת של צמתים, מעבד וזיכרון להרצת עומסי העבודה ששוחזרו. באשכולות Autopilot, הקצאת צמתים אוטומטית (NAP) עשויה להימשך זמן נוסף, ולכן מומלץ לבדוק אם יש מגבלות או שגיאות בהתאמה לעומס של צמתים. מטפלים בבעיות הבסיסיות על סמך הממצאים, ופותרים את הבעיות שמונעות מעומסי העבודה להיכנס למצב ready. הגישה הזו יכולה לכלול תיקון של קובצי מניפסט, התאמה של בקשות או מגבלות משאבים, תיקון של מדיניות רשת או וידוא שהתלות מתקיימת.

6. אחרי שפותרים את הבעיות הבסיסיות, מחכים שעומסי העבודה יעברו למצב ready. לא צריך להפעיל שוב את פעולת השחזור.

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

שגיאה 200060102: השלמת פעולת השחזור נכשלה בגלל שגיאת אימות של עוצמת הקול

השגיאה 200060102 מתרחשת כי אחד או יותר מהמשאבים VolumeRestore, שמנהלים את תהליך השחזור של נתונים מ-VolumeBackup אל PersistentVolume, נכנסו למצב failed או deleting במהלך שלב אימות הנפח של פעולת השחזור. שחזור הנפח שנכשל גורם להודעת השגיאה הבאה בשדה stateReason של משאב השחזור:

Volume Validation Error: Some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

בהודעת השגיאה מפורטים השמות המלאים של המשאבים שנכשלו VolumeRestore, כולל שם היעד PersistentVolumeClaim ומרחב השמות. הודעת השגיאה מציינת שתהליך שחזור הנתונים של PersistentVolumeClaim המושפע לא הושלם בהצלחה כש-Backup for GKE הפעיל משאבי VolumeRestore כדי להקצות PersistentVolumes מ-VolumeBackups, ויצירת הדיסק הקשיח הבסיסי מהתמונה נכשלה. יכולות להיות כמה סיבות לכשלים ב-VolumeRestore:

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

• בעיות בהרשאות: לחשבון השירות שבו משתמשים ב-Backup for GKE חסרות ההרשאות הנדרשות ליצירת דיסקים או לגישה לתמונות מצב.

• בעיות ברשת: יש בעיות זמניות או קבועות ברשת שמפריעות לתהליך יצירת הדיסק.

• Invalid snapshot (קובץ snapshot לא תקין): המקור VolumeBackup או קובץ ה-snapshot הבסיסי של Persistent Disk פגום או לא נגיש.

• אילוצי משאבים: אילוצים אחרים של משאבי אשכול מעכבים את הקצאת הנפח.

• שגיאות פנימיות: יש בעיות פנימיות בשירות Persistent Disk.

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

1. מזהים את PersistentVolumeClaims שנכשלו שמופיעים בהודעת השגיאה, שבה מפורטים שמות המשאבים המלאים של אובייקטים מסוג VolumeRestore שנכשלו.

2. כדי לקבל פרטים על כל משאב VolumeRestore שנכשל, מריצים את הפקודה gcloud beta container backup-restore volume-restores describe:

   gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
   --project=PROJECT_ID \
   --location=LOCATION \
   --restore-plan=RESTORE_PLAN_ID \
   --restore=RESTORE_ID
   

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

   • ‫VOLUME_RESTORE_ID: המזהה של משאב VolumeRestore שנכשל.

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

   • ‫LOCATION: Cloud de Confiance by S3NS המיקום של השחזור.

   • ‫RESTORE_PLAN_ID: המזהה של תוכנית השחזור.

   • ‫RESTORE_ID: המזהה של פעולת השחזור.

3. בודקים את השדות state ו-stateMessage בפלט כדי לקבל פרטים על הכשל.

   .

4. בודקים את המצב של יעד PersistentVolumeClaim על ידי הפעלת הפקודה kubectl get pvc:

   kubectl get pvc PVC_NAME -n NAMESPACE_NAME -o yaml
   

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

   • ‫PVC_NAME: השם של PersistentVolumeClaim המשאב.

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

5. מוודאים שבקטע status.phase של הפלט מצוין שלב Pending. בשלב הזה, PersistentVolumeClaim עדיין לא מקושר ל-PersistentVolume, וזה צפוי אם VolumeRestore נכשל.

6. בודקים את הקטע Events בפלט ה-YAML כדי לראות הודעות שקשורות לכשלים בהקצאת משאבים, כמו ProvisioningFailed. לדוגמה:

   Cloud KMS error when using key projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY:  Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied  on resource 'projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY' (or it may not exist).
   

   הפלט מציין שיש בעיה בהרשאות בזמן הגישה למפתח ההצפנה במהלך יצירת הדיסק. כדי לספק את ההרשאה הרלוונטית לגישה למפתח, צריך לפעול לפי ההוראות שמתוארות במסמכי התיעוד של Backup for GKE בנושא הפעלת הצפנת CMEK.compute service agent

7. בודקים את האירועים ב-GKE במרחב השמות PersistentVolumeClaim, שכוללים הודעות שגיאה מפורטות מהבקר PersistentVolume או מנהל ה-CSI, על ידי הפעלת הפקודה kubectl get events:

   kubectl get events -n NAMESPACE_NAME --sort-by='.lastTimestamp'
   

   מחליפים את NAMESPACE_NAME במרחב השמות של PersistentVolumeClaim,

8. זיהוי אירועים שקשורים לשם PersistentVolumeClaim, שמכיל מילות מפתח כמו FailedProvisioning או ExternalProvisioning. האירועים יכולים לכלול גם שגיאות מספק האחסון, כמו pd.csi.storage.gke.io.

9. בודקים את יומני Persistent Disk ביומני הביקורת של Cloud וב-Cloud Logging כדי לראות אם יש שגיאות שקשורות לפעולות של יצירת דיסק בסביבות הזמן של הכשל.

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

    • אם מצוין, מגדילים את המכסות של דיסק אחסון מתמיד (persistent disk), למשל (QUOTA_EXCEEDED}: Quota SSD_TOTAL_GB exceeded.

    • בודקים ומתקנים את ההרשאות ב-IAM.

    • בודקים את הבעיות ברשת ופותרים אותן.

    • כדי לפתור בעיות שקשורות לתמונת המצב או לשירות Persistent Disk, צריך לפנות ל-Cloud Customer Care.

    • הסטטוס של PersistentVolumeClaim נשאר Pending.

    • תהליך השחזור לא מנסה אוטומטית לשחזר את VolumeRestore. כדי לפתור את הבעיה, צריך להפעיל פעולת שחזור עבור עומס העבודה Deployment או StatefulSet שמשתמש ב-PersistentVolumeClaim המושפע.

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

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

שגיאה 200060101: פעולת השחזור לא הושלמה בגלל פסק זמן לאימות עוצמת הקול

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

הודעת השגיאה בשדה stateReason של המשאב Restore מציגה את רשימת המשאבים VolumeRestore שנמצאו אבל עדיין לא היו במצב succeeded כשנבדק פסק הזמן. הוא כולל את השם של משאב היעד PersistentVolumeClaim ואת מרחב השמות שלו עבור משאבי VolumeRestore האלה, לדוגמה:

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME), ...]

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

Volume Validation Error: Timed out waiting for volume restore [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_NAME/restores/RESTORE_NAME/volumeRestores/VOLUME_RESTORE_ID (PVC: PVC_NAMESPACE/PVC_NAME), ...] and some of the volume restores failed - [projects/PROJECT_ID/locations/LOCATION/restorePlans/RESTORE_PLAN_ID/restores/RESTORE_ID/volumeRestores/VOLUME_RESTORE_ID (PVC: NAMESPACE/PVC_NAME), ...]

הגיבוי ל-GKE יוזם הקצאה של משאבי VolumeRestorePersistentVolumes מ-VolumeBackups. השגיאה מציינת שיצירת דיסק האחסון המתמיד (persistent disk) הבסיסי מתוך ה-snapshot והקישור הבא של PersistentVolumeClaim אל PersistentVolume נמשכו יותר מהזמן הקצוב לתפוגה שחושב עבור VolumeRestores שצוין. יכול להיות שגם פעולות שחזור אחרות עם אותו VolumeRestores יהיו במצב לא הושלם.

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

כדי לפתור את הבעיה, צריך לפעול לפי ההוראות הבאות:

1. מזהים את השם ואת מרחב השמות של PersistentVolumeClaim שחלף הזמן הקצוב לתגובה שלו בהודעת השגיאה. לדוגמה, (PVC: PVC_NAMESPACE/PVC_NAME).

2. כדי לראות את הסטטוסים הנוכחיים של כל VolumeRestores שמשויכים לפעולת השחזור, מריצים את הפקודה gcloud beta container backup-restore volume-restores list:

   gcloud beta container backup-restore volume-restores list \
   --project=PROJECT_ID \
   --location=LOCATION \
   --restore-plan=RESTORE_PLAN_NAME \
   --restore=RESTORE_NAME
   

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

   • ‫PROJECT_ID: מזהה Cloud de Confiance by S3NS הפרויקט.

   • ‫LOCATION: Cloud de Confiance by S3NS המיקום של השחזור.

   • ‫RESTORE_PLAN_NAME: השם של תוכנית השחזור.

   • ‫RESTORE_NAME: השם של פעולת השחזור.

3. מאתרים את VolumeRestores שלא נמצאים במצב succeeded.

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

5. כדי לקבל פרטים על VolumeRestore שמוזכר בשגיאה ועל VolumeRestores אחרים שלא נמצאים במצב succeeded, מריצים את הפקודה gcloud beta container backup-restore volume-restores describe:

   gcloud beta container backup-restore volume-restores describe VOLUME_RESTORE_ID \
   --project=PROJECT_ID \
   --location=LOCATION \
   --restore-plan=RESTORE_PLAN_NAME \
   --restore=RESTORE_NAME
   

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

   • ‫VOLUME_RESTORE_ID: המזהה של משאב VolumeRestore.

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

   • ‫LOCATION: Cloud de Confiance by S3NS המיקום של השחזור.

   • ‫RESTORE_PLAN_NAME: השם של תוכנית השחזור.

   • ‫RESTORE_NAME: השם של פעולת השחזור.

6. בודקים את השדות state וstateMessage. הערך בשדה state הוא כנראה creating או restoring. בשדה stateMessage עשוי להיות הקשר נוסף ופרטים על PersistentVolumeClaim היעד.

7. בודקים את המצב של יעד PersistentVolumeClaims שזוהה על ידי הרצת הפקודה kubectl get pvc:

   kubectl get pvc PVC_NAME -n PVC_NAMESPACE -o yaml
   

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

   • ‫PVC_NAME: השם של PersistentVolumeClaim.

   • ‫PVC_NAMESPACE: מרחב השמות של PersistentVolumeClaim.

   הערך של PersistentVolumeClaim's status.phase יהיה כנראה Pending. בודקים את הקטע Events כדי לראות אם מופיעות בו השגיאות הבאות:

   • ‫Waiting for first consumer to be created before binding: מציין שStorageClass כולל volumeBindingMode: WaitForFirstConsumer.

     הקצאת ההרשאות של PersistentVolume מתעכבת עד שנוצרת ומתוזמנת Pod שמשתמשת בPersistentVolumeClaim. יכול להיות שהבעיה היא בתזמון Pod ולא בהקצאת נפח האחסון עצמה. לכן, מומלץ לבדוק למה לא מתבצע תזמון של Pods שצורכים את PersistentVolumeClaim או למה הם לא מתחילים.

   • ‫FailedProvisioning או שגיאות ממנהל הקצאות האחסון: לדוגמה, pd.csi.storage.gke.io.

8. בודקים את האירועים ב-GKE במרחבי השמות הרלוונטיים על ידי הפעלת הפקודה kubectl get events:

   kubectl get events -n PVC_NAMESPACE --sort-by='.lastTimestamp'
   

   מחליפים את PVC_NAMESPACE במרחב השמות של PersistentVolumeClaim.

   מחפשים אירועים שקשורים לשמות PersistentVolumeClaim, כמו הודעות או שגיאות של הקצאת הרשאות.

9. בודקים את יומני הביקורת של Cloud ואת יומני Persistent Disk ב-Cloud Logging.

10. מעקב אחרי הסטטוס של כל VolumeRestores ב-creating ובמצבים restoring שונים.

    אחרי שהבעיה נפתרת, הסטטוס של VolumeRestores יכול להשתנות לסטטוס succeeded או failed. אם VolumeRestoresמגיעים למצב succeeded, PersistentVolumeClaims אמור להפוך לBound ועומסי העבודה אמורים לפעול. אם נפח האחסון VolumeRestore עובר למצב failed, צריך לבצע פעולות לפתרון בעיות כדי לפתור את שגיאת האימות של נפח האחסון. מידע נוסף זמין במאמר שגיאה 200060102: הפעולה 'שחזור' לא הושלמה בגלל שגיאת אימות נפח

אם VolumeRestores נשארים במצבים creating או restoring למשך זמן ממושך מדי, פנו אל Cloud Customer Care לקבלת עזרה נוספת.

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

• במאמר הזה מוסבר על קודי שגיאה של פעולות גיבוי שנכשלו ב-Backup for GKE.