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

‫Custom Resource Definitions (CRDs) הם כלים יעילים להרחבת היכולות של 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. מריצים את הפקודה הבאה כדי לתאר את השירות ולמצוא חבילות של אישורים דיגיטליים (CA) שעלולות לגרום לבעיות:

    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

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