בעיות מוכרות
בדף הזה מפורטות בעיות מוכרות ב-Config Connector.
רבות מהבעיות שמפורטות כאן נפתרו. בעמודה Fixed version (גרסה שבה הבעיה תוקנה) מצוינת הגרסה שבה התיקון הוטמע. כדי לקבל את התיקון הזה, צריך לשדרג לגרסה שמופיעה ברשימה או לגרסה חדשה יותר.
אם אתם חלק מ-Google Developer Program, שמרו את הדף הזה כדי לקבל התראות כשמתפרסמים נתוני גרסה שקשורים לדף הזה. מידע נוסף זמין במאמר בנושא דפים שמורים.
כדי לסנן את הבעיות הידועות לפי גרסת מוצר או קטגוריה, בוחרים את המסננים מהתפריטים הנפתחים הבאים.
בוחרים את הגרסה של Config Connector:
בוחרים את קטגוריית הבעיה:
אפשר גם לסנן את הבעיות הידועות:
| קטגוריה | הגרסה המוקדמת ביותר שזוהתה | גרסה קבועה | הבעיה והפתרון העקיף |
|---|---|---|---|
| משאבים | 1.126.0 | 1.134.1 |
תוקן: יצירת משאבים נחסמה בגלל שגיאת TLS ב-webhook: 'x509: certificate signed by unknown authority'כשמנסים ליצור או להחיל משאבים חדשים של Config Connector, שרת ה-API של Kubernetes דוחה את הבקשה ומונע את יצירת המשאב. לא תוכלו לפרוס משאבים חדשים, אבל יכול להיות שהמשאבים הקיימים ימשיכו להסתנכרן כרגיל. הבעיה הזו נגרמת בגלל מרוץ תהליכים ידוע ברכיב יכול להיות שתראו שגיאה דומה לזו שמופיעה בהמשך בפלט של הפריסה או ביומנים של שרת ה-API:
failed calling webhook "container-annotation-handler.cnrm.cloud.google.com": failed to call webhook: Post "https://cnrm-validating-webhook.cnrm-system.svc:443/...": tls: failed to verify certificate: x509: certificate signed by unknown authority
בנוסף, יכול להיות שיוצגו ביומני ה-Pod הנתונים הבאים:
http: TLS handshake error ... remote error: tls: bad certificate.
פתרון עקיף: כדי לבטל את החסימה של יצירת משאבים באופן מיידי, אפשר להפעיל מחדש את הפריסה באמצעות הפקודה הבאה כדי לאלץ את תרמילי ה-Pod של מנהל ה-webhook לבצע סנכרון ולשלוף את נתוני האישור הנכונים: kubectl rollout restart deployment cnrm-webhook-manager -n cnrm-system |
| משאבים | 1.134 | 1.134.2 |
תוקן: SQLInstance נתקע במצב 'מתבצע עדכון' עם שגיאת הערה מסוג 'מיזוג'יכול להיות שמשאבי
invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation
הבעיה הזו מתרחשת כי אימות מחמיר יותר שהוצג בגרסה 1.134.0 דחה באופן שגוי את אסטרטגיית המיזוג של משאבי |
| Direct Reconciler | 1.131 | 1.134 |
תוקן: בעיות בכלי השוואה ישיריםבגרסה 1.132.0 של Config Connector נוספו בעיות שמשפיעות על משאבים שמשתמשים בכלי ההתאמה הישיר. שגיאה: שם בקר כפולבגרסה 1.132.0, יכול להיות שמשאבים כמו
error registering controller: error adding direct controller for SpannerInstance to a manager: error creating new controller: controller with name spannerinstance-controller already exists.
שגיאה ב-SecretManagerSecret last-applied-configurationאם מפעילים את כלי ההתאמה הישיר ל-
[kubectl.kubernetes.io/last-applied-configuration] must follow pattern [a-z0-9A-Z]+([_\.\-]*[a-z0-9A-Z]+)*), be less than 64 characters, and must have a UTF encoding of less than 128 bytes
השגיאה הזו מתרחשת כי Config Connector מנסה להעביר הערות פנימיות של Kubernetes כתוויות ל-Secret Manager API, אבל בצורה שגויה. |
| התקנה, Networking | Kubernetes 1.19 | 1.43 |
תוקן: השגיאה 'הפעלת webhook x509 נכשלה: האישור מסתמך על שדה שם נפוץ מדור קודם'אם מופיעה שגיאה שדומה לדוגמה הבאה, יכול להיות שיש בעיה עם האישורים:
Error from server (InternalError): error when creating "/mnt/set-weaver-dns-record.yml": Internal error occurred: failed calling webhook "annotation-defaulter.cnrm.cloud.google.com": Post "https://cnrm-validating-webhook.cnrm-system.svc:443/annotation-defaulter?timeout=30s": x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0
הבעיה הזו מתרחשת ב-Kubernetes בגרסה 1.19 ואילך. גרסאות 1.43 ואילך של Config Connector תומכות ביצירה אוטומטית של האישור, מה שאמור למנוע את הבעיה הזו. פתרון עקיף: כדי לעקוף את הבעיה, אפשר למחוק את האישורים הרלוונטיים ואת ה-Pods: kubectl delete -n cnrm-system secrets cnrm-webhook-cert-abandon-on-uninstall kubectl delete -n cnrm-system secrets cnrm-webhook-cert-cnrm-validating-webhook kubectl delete -n cnrm-system pods -l "cnrm.cloud.google.com/component=cnrm-webhook-manager" אחרי שתמחקו את המשאבים האלה, האישור הנכון ייווצר מחדש. |