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

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

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

השגיאה 200010301 מתרחשת כשניסיון להשלים פעולת שחזור נכשל כי שירות webhook של הרשאה, שנקרא גם קריאה חוזרת של 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 פעיל באשכול היעד, אבל שרת ה-API של GKE לא מצליח להגיע לנקודת הקצה שהוגדרה ב-webhook. ה-webhooks של בקרת הכניסה מיירטים בקשות לשרת GKE API, וההגדרה שלהם מציינת איך שרת GKE API צריך לשלוח שאילתות לבקשות.

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

  • שירותים בתוך האשכול: שירות GKE והפודים שמגבים אותו לא משוחזרים או מוכנים כששרת ה-API של GKE מנסה לקרוא ל-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 לפעולת הגיבוי ומגדירים את שאר המשאבים שבוחרים.

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

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

    2. מוודאים שיש קישוריות רשת מהצמתים וממישור הבקרה של אשכול GKE לכתובת ה-URL החיצונית. יכול להיות שתצטרכו לבדוק גם את כללי חומת האש, למשל אם אתם משתמשים בענן וירטואלי פרטי (VPC), במשאבים מקומיים או בספק שירותי ענן שמארח את ה-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 יסרב ליצור פריסה אם היא כבר מנוהלת על ידי משאב GKE API‏ HorizontalPodAutoscaler.

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

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

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

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

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

    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 או כלים אחרים של Google Cloud .

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

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

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

  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.

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

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

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

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

    • ‫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: השם של pod ספציפי.

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

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

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

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

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

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

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

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

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

  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, והיצירה של Persistent Disk הבסיסי מתמונת המצב נכשלה. יכולות להיות כמה סיבות לכשלים ב-VolumeRestore:

  • מכסה לא מספיקה: אין מספיק מכסת Persistent Disk שהוקצתה בפרויקט או באזור, לדוגמה, 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: מזהה הפרויקט ב- Google Cloud .

    • ‫LOCATION: Google Cloud המיקום של השחזור.

    • ‫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).

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

  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 מתרחשת בשלב אימות הנפח של פעולת שחזור, כש-"גיבוי ל-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 מתחיל להקצות VolumeRestore משאבים ל-PersistentVolumes מ-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: מזהה Google Cloud הפרויקט.

    • ‫LOCATION: Google Cloud המיקום של השחזור.

    • ‫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: מזהה הפרויקט ב- Google Cloud .

    • ‫LOCATION: Google Cloud המיקום של השחזור.

    • ‫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 לקבלת עזרה נוספת.

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