פתרון בעיות שגיאות מערכת בגיבוי ל-GKE

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

שגיאה 100010108: הגיבוי של PersistentVolumeClaim נכשל – חסר CMEK של תוכנית גיבוי לדיסק מוצפן

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

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

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

failed to create snapshot as disk "pvc-1" is encrypted with CMEK "projects/proj1/locations/us-east1/keyRings/keyring1/cryptoKeys/key1/cryptoKeyVersions/1", but no Backup Plan CMEK is provided. Please add CMEK to the Backup Plan.

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

  1. מזהים את הגדרת ה-CMEK החסרה: הודעת השגיאה מאשרת שה-PVC שמגבים מוצפן, אבל בהגדרות של תוכנית הגיבוי חסר מפתח הצפנה.
  2. הוספת מפתח CMEK לתוכנית הגיבוי: מעדכנים את הגדרות תוכנית הגיבוי כדי לכלול מפתח הצפנה בניהול הלקוח (CMEK). המפתח הזה ישמש להצפנת נתוני הגיבוי, כולל גיבויים של נפחים בהיקף אזורי.
  3. מוודאים שההרשאות מתאימות: בודקים שלסוכן השירות של Backup for GKE‏ (service-PROJECT_NUMBER@gcp-sa-gkebackup.s3ns-system.iam.gserviceaccount.com) מוקצה התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter עבור ה-CMEK שנוסף.
  4. בדיקה מחדש של פעולת הגיבוי: אחרי שמעדכנים את תוכנית הגיבוי עם CMEK ומעניקים הרשאות, מנסים שוב את פעולת הגיבוי.

שגיאה 100020102: מצב הרשאה מחמיר – הגיבוי של CRD נכשל – גרסת API לא נתמכת v1beta1

השגיאה 100020102 מתרחשת כשמנסים לגבות CustomResourceDefinition שהוחל במקור כגרסה apiextensions.k8s.io/v1beta1, אבל הגיבוי נכשל כי חסרה סכימה מבנית שנדרשת בגרסת apiextensions.k8s.io/v1 של ה-API. השגיאה הזו מובילה להודעת השגיאה הבאה: Strict permissive mode - Failed to backup CRD - Unsupported v1beta1 API Version.

השגיאה הזו מתרחשת כי גרסת apiextensions.k8s.io/v1 API הוסרה ב-Google Kubernetes Engine גרסה 1.22. מידע נוסף על הסרת ה-API ב-GKE גרסה 1.22 זמין במאמר הסרות של API ב-GKE v1.22.

התנהגות של פעולת גיבוי במצב לא מתירני

במצב לא מתירני, או בתוכנית גיבוי מחמירה, פעולת הגיבוי נכשלת אם היא נתקלת במשאב שלא ניתן לגבות, כמו CustomResourceDefinition שנוצר באמצעות v1beta1 API. השגיאה הזו מתרחשת כי למשאב חסרה סכימת המבנה שנדרשת על ידי API‏ v1. הנוכחות של CustomResourceDefinition נחשבת לשגיאה קריטית כי יכול להיות שהיא לא תשוחזר בצורה תקינה לאשכול חדש יותר.

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

  1. מריצים את הפקודה kubectl get crd כדי לזהות את CustomResourceDefinition הבעייתי:

    kubectl get crd CRD_NAME

    מחליפים את CRD_NAME בשם של CustomResourceDefinition מהודעת השגיאה.

  2. בפלט של YAML, מאתרים את התנאים הבאים כדי לוודא שההמרה של CustomResourceDefinition מ-vbeta1 API ל-v1 API בוצעה בצורה תקינה:

    1. ‫spec.versions: מאתרים את התנאי spec.versions על ידי עיון בכל גרסה שמופיעה בשדה spec.versions. אם חסר השדה schema.openAIV3Schema באחד מה-spec.versions, לא מוגדרת סכימה מבנית ל-CustomResourceDefinition בגרסה הזו.

    2. ‫status.conditions: מאתרים את התנאי status.conditions על ידי חיפוש התנאי type:NonStructuralSchema. אם הערך של status.conditions's status הוא true, זה מאשר באופן מפורש שהסכימה לא מבנית.

  3. כדי לשדרג את CustomResourceDefinition לגרסה v1 של API, צריך לבצע את השלבים הבאים:

    1. עורכים את CustomResourceDefinition הקיים כדי להתאים אותו לתקן v1. לשם כך, מוסיפים סכימה מבנית שמגדירה כל שדה ואת הסוג שלו במשאב המותאם אישית. מידע נוסף על הוספת סכימה מבנית זמין במאמר הגדרת סכימה מבנית.

    2. מחילים את המניפסט התואם v1 על האשכול.

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

    • אם לא נעשה שימוש ב-CustomResourceDefinition באשכול, מוחקים אותו על ידי הרצת הפקודה kubectl delete crd.CustomResourceDefinition

      kubectl delete crd CRD_NAME

      מחליפים את CRD_NAME בשם של CustomResourceDefinition שרוצים למחוק.

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

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

שגיאה 100040102: מרחב השמות לא נמצא

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

Namespace [NAMESPACE_NAME] is not found.

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

  1. כדי לוודא שהמרחב לשמות הוזן בצורה נכונה, בודקים את הרשימה selectedNamespaces בהגדרות של BackupPlan.

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

    kubectl get namespace NAMESPACE_NAME

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

    אם מרחב השמות לא קיים, מוצגת הודעה שמרחב השמות לא נמצא, למשל Error from server (NotFound): namespaces "[NAMESPACE_NAME]" not found.

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

  4. אחרי שתבצעו את התיקונים הנדרשים ב-BackupPlan, נסו שוב לבצע את פעולת הגיבוי והתחילו גיבוי חדש.

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

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