בעיות מוכרות
בדף הזה מפורטות בעיות ידועות ב-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.
פתרון עקיף: כדי לבטל באופן מיידי את החסימה של יצירת המשאבים, אתם יכולים לאלץ את הפודים של מנהל ה-webhook לסנכרן ולמשוך את נתוני האישור הנכונים. כדי לעשות את זה, מפעילים מחדש את הפריסה באמצעות הפקודה הבאה: kubectl rollout restart deployment cnrm-webhook-manager -n cnrm-system |
| משאבים | 1.134 | 1.134.2 |
תוקן: SQLInstance תקוע במצב Updating עם שגיאת הערה "merge"יכול להיות שמשאבי
invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation
הבעיה הזו נגרמת כי אימות מחמיר יותר שהוצג בגרסה 1.134.0 דחה בטעות את אסטרטגיית המיזוג של משאבי |
| התאמה ישירה | 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. |
| התקנה, רשתות | Kubernetes בגרסה 1.19 | 1.43 |
תוקן: שגיאה מסוג "הקריאה ל-webhook x509 נכשלה: האישור מסתמך על שדה Common Name מדור קודם"אם מופיעה שגיאה דומה לדוגמה הבאה, יכול להיות שיש בעיה באישורים:
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
הבעיה הזו מתרחשת בגרסאות 1.19 ואילך של Kubernetes. בגרסאות 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" אחרי שתמחקו את המשאבים האלה, האישור הנכון אמור להיווצר מחדש. |