פתרון בעיות שגיאות מערכת בגיבוי ל-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. מוודאים שיש הרשאות מתאימות: מוודאים שלסוכן השירות של "גיבוי ל-GKE"‏ ([e-mail]) הוקצה התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter ל-CMEK שנוסף.
4. בדיקה מחדש של פעולת הגיבוי: אחרי שמעדכנים את תוכנית הגיבוי עם CMEK ומעניקים הרשאות, מנסים שוב את פעולת הגיבוי.

שגיאה 100020102: CustomResourceDefinition – יש סכימה לא תקינה – גרסת API v1beta1 לא נתמכת

השגיאה 100020102 מתרחשת כשניסיון לגבות CustomResourceDefinition שהוחל במקור כגרסה apiextensions.k8s.io/v1beta1 נכשל, כי חסרה לו הסכימה המבנית שנדרשת בגרסת ה-API‏ apiextensions.k8s.io/v1. השגיאה הזו מובילה להודעת השגיאה הבאה: CustomResourceDefinition - has an invalid schema. The resource was originally applied as v1beta1, which has been removed from Kubernetes 1.22+.

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

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

במצב לא מתירני או בתוכנית גיבוי מחמירה, פעולת הגיבוי נכשלת אם המערכת נתקלת במשאב שלא ניתן לגבות, כמו CustomResourceDefinition שנוצר באמצעות v1beta1 API. השגיאה הזו מתרחשת כי למשאב חסרה סכימת המבנה שנדרשת על ידי v1 API. הנוכחות של 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. אם באחד מהערכים של spec.versions חסר השדה schema.openAIV3Schema, לא מוגדרת סכימה מבנית לגרסה הזו של CustomResourceDefinition.

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

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

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

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

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

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

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

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

     kubectl delete crd CRD_NAME
     

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

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

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

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

שגיאה 100020103: השאילתה למשאבי ה-API נכשלה

השגיאה 100020103 מתרחשת כש-Backup for GKE לא מצליח לגלות שירותי API מותאמים אישית או מצטברים של Kubernetes לפני יצירת גיבוי, וכתוצאה מכך מוצגת הודעת השגיאה Failed to query API resources. Please check if any API service is unavailable by using 'kubectl get apiservice'. זה קורה אם שירות API מצטבר מוגדר בצורה שגויה, או אם שירותי הגיבוי וה-pods שלו לא תקינים או שלא ניתן להגיע אליהם. במצב לא מתירני, או בתוכנית גיבוי מחמירה, אם שירות הגיבוי ל-GKE נתקל ב-APIService לא זמין, הוא מפסיק את פעולת הגיבוי כדי למנוע תיעוד של מצב לא שלם או לא עקבי של האשכול.

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

1. מריצים את הפקודה הבאה כדי לזהות שירותי API שלא זמינים:

   kubectl get apiservice
   

   בפלט, מחפשים שירותי API שבהם העמודה AVAILABLE היא False.

2. כדי לבדוק את הפרטים של ה-APIService שנכשל, מריצים את הפקודה הבאה:

   kubectl describe apiservice APISERVICE_NAME
   

   מחליפים את הערך APISERVICE_NAME בשם של שירות ה-API שנכשל, לדוגמה, v1beta1.custom.metrics.k8s.io.

   בפלט, בודקים את השדה Service בקטע spec.service ואת הקטע Conditions כדי לזהות את השירות התומך, את מרחב השמות שלו ואת הסיבה לכשל (למשל, נקודות קצה חסרות או יציאת יעד לא נגישה).

3. כדי לפתור את השגיאה, אפשר להשתמש באחת מהשיטות הבאות:

   • שחזור שירות תומך: כדי לוודא שלשירות התומך יש נקודות קצה מוכנות, מריצים את הפקודה הבאה:

     kubectl get endpoints -n NAMESPACE SERVICE_NAME
     

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

     • ‫NAMESPACE: מרחב השמות של שירות תומך.
     • ‫SERVICE_NAME: השם של שירות הגיבוי.

     מוודאים שה-Pods שתומכים בשירות קיימים ושמצבם הוא Running. לפתור בעיות שגורמות לקריסה של קבוצות Pod, לכשלים בשליפת תמונות או לבעיות בהגדרות של מדיניות רשת ב-Kubernetes שמונעות מתעבורת הנתונים להגיע לשירות התומך.

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

     kubectl delete apiservice APISERVICE_NAME
     

     מחליפים את APISERVICE_NAME בשם של שירות ה-API היתום.

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

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

4. מנסים שוב לבצע את פעולת הגיבוי. אם הפעולה ממשיכה להיכשל, אפשר לפנות אל 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 לקבלת עזרה נוספת.

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

• קוראים את דף הסקירה הכללית של קודי השגיאה של Backup for GKE.