פתרון בעיות ב-CRD עם חבילת CA לא תקינה

הגדרות של משאבים בהתאמה אישית (CRD) הן כלים יעילים להרחבת היכולות של Kubernetes. עם זאת, אם CRD מכיל חבילת רשויות אישורים (CA) לא חוקית או פגומה בהגדרת ה-webhook להמרה spec.conversion.webhook.clientConfig.caBundle, הוא עלול לשבש את פעולות האשכול. הבעיה הזו יכולה להתבטא בשגיאות במהלך יצירה, עדכון או מחיקה של משאבים, ולהשפיע על היציבות והביצועים של האשכול.

כדי למנוע את הבעיה הזו, ‏ Google Kubernetes Engine ‏ (GKE) מזהה באופן אוטומטי CRD עם חבילות CA לא תקינות ומפיק המלצה. במסמך הזה מוסבר איך למצוא את ההמלצה, לזהות את הגדרות ה-CRD השגויות ולעדכן אותן.

המידע הזה חשוב לאדמינים ומפעילים של פלטפורמות ולמשתמשים אחרים שמנהלים CRD ומשאבים בהתאמה אישית ב-GKE.

זיהוי האשכולות המושפעים

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

  • משתמשים במסוף Cloud de Confiance .
  • משתמשים ב-Google Cloud CLI או ב-Recommender API ומסננים לפי סוג המשנה K8S_CRD_WITH_INVALID_CA_BUNDLE.

אחרי שמזהים את ה-CRD באמצעות התובנות, פועלים לפי ההוראות לפתרון בעיות בחבילת ה-CA שהוגדרה באופן שגוי.

כש-GKE מזהה הגדרות שגויות של CRD

‫GKE יוצר תובנה והמלצה עם סוג המשנה K8S_CRD_WITH_INVALID_CA_BUNDLE אם באשכול GKE יש CRD אחד או יותר שמדווחים על הגדרה שגויה של caBundle להגדרת הלקוח של ה-webhook ב-spec.conversion.webhook.clientConfig.

פועלים לפי ההוראות לבדיקת CRD עם חבילת CA שהוגדרה בצורה שגויה.

פתרון בעיות שקשורות ל-CRD שזוהו

בקטעים הבאים מפורטות הוראות לפתרון בעיות ב-CRD ש-GKE זיהה כבעלי הגדרה שגויה פוטנציאלית.

אחרי שמיישמים את ההוראות ומגדירים את ה-CRD בצורה נכונה, ההמלצה נפתרת תוך 24 שעות והיא כבר לא מופיעה במסוף. אם עברו פחות מ-24 שעות מאז שיישמתם את ההנחיות שבהמלצה, אתם יכולים לסמן את ההמלצה כ"טופלה". אם אתם לא רוצים ליישם את ההמלצה, אתם יכולים לסגור אותה.

זיהוי של CRD מושפע באשכול

  1. צפייה בתובנות ובהמלצות לגבי סוג המשנה K8S_CRD_WITH_INVALID_CA_BUNDLE, ובחירה של תובנה אחת בכל פעם כדי לפתור בעיות. ‫GKE יוצר תובנה אחת לכל אשכול שיש בו CRD פגום.

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

    kubectl get crd -o custom-columns=NAME:.metadata.name,CABUNDLE:.spec.conversion.webhook.clientConfig.caBundle

    הפלט כולל את:

    • שם: השם של ה-CRD.
    • ‫CaBundle: חבילת ה-CA שמשויכת ל-webhook של ההמרה של ה-CRD, אם קיימת. בודקים את הפלט. אם העמודה caBundle ריקה עבור CRD שאתם יודעים שמנצל תגובה לפעולה מאתר אחר (webhook) של המרה, זה מצביע על בעיה פוטנציאלית ב-caBundle.

יצירה מחדש של ה-CRD

כדי לפתור את השגיאה, צריך ליצור מחדש את ה-CRD המושפע עם חבילת CA תקינה:

  1. אם יש לכם משאבים מותאמים אישית שמשויכים ל-CRD הבעייתי הזה, כדאי לגבות אותם. מריצים את הפקודה הבאה כדי לייצא את המשאבים הקיימים:

      kubectl get <crd-name> -o yaml > backup.yaml

  2. מוחקים את ה-CRD הקיים:

      kubectl delete crd <crd-name>

  3. מוודאים שהשדה caBundle של ה-CRD מכיל אישור PEM תקין בקידוד base64. כדי לעשות את זה, אפשר לערוך ישירות את ה-CRD או לפנות ליוצרים שלו.

  4. משנים את הגדרת ה-YAML של ה-CRD, ומעדכנים את השדה spec.conversion.webhook.clientConfig.caBundle עם נתוני חבילת ה-CA התקינים. התוצאה אמורה להיראות בערך כך:

        spec:
      conversion:
        webhook:
          clientConfig:
            caBundle: <base64-encoded-ca-bundle>

  5. מחילים את ה-CRD המתוקן:

        kubectl apply -f <corrected-crd-file.yaml>

  6. שחזור המשאבים המותאמים אישית:

        kubectl apply -f backup.yaml

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