‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פתרון בעיות ב-Config Connector

בדף הזה מתוארות שיטות לפתרון בעיות נפוצות שאתם עשויים להיתקל בהן במהלך השימוש ב-Config Connector.

בדיקת הסטטוס והתנאים של Config Connector

בדיקת הגרסה של Config Connector

מריצים את הפקודה הבאה כדי לקבל את הגרסה המותקנת של Config Connector, ומצליבים עם נתוני הגרסה כדי לוודא שהגרסה שפועלת תומכת בתכונות ובמשאבים שבהם רוצים להשתמש:

kubectl get ns cnrm-system -o jsonpath='{.metadata.annotations.cnrm\.cloud\.google\.com/version}'

בדיקת הסטטוס והאירועים של המשאב

בדרך כלל, אפשר לזהות את הבעיה במשאבים של Config Connector על ידי בדיקת המצב של המשאבים ב-Kubernetes. בדיקת הסטטוס והאירועים של המשאב עוזרת במיוחד כדי לקבוע אם Config Connector נכשל בהתאמת המשאב, ולמה ההתאמה נכשלה.

מוודאים ש-Config Connector פועל

כדי לבדוק ש-Config Connector פועל, מוודאים שכל ה-Pods שלו הם READY:

kubectl get pod -n cnrm-system

פלט לדוגמה:

NAME                                            READY   STATUS    RESTARTS   AGE
cnrm-controller-manager-0                       1/1     Running   0          1h
cnrm-deletiondefender-0                         1/1     Running   0          1h
cnrm-resource-stats-recorder-77dc8cc4b6-mgpgp   1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-pqwhz           1/1     Running   0          1h
cnrm-webhook-manager-58496b66f9-wdcn4           1/1     Running   0          1h

אם התקנתם את Config Connector במצב מרחב שמות, יהיה לכם פוד אחד של בקר (cnrm-controller-manager) לכל מרחב שמות שאחראי לניהול המשאבים של Config Connector באותו מרחב שמות.

כדי לבדוק את הסטטוס של ה-Pod של הבקר שאחראי למרחב שמות ספציפי, מריצים את הפקודה:

kubectl get pod -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager

מחליפים את NAMESPACE בשם של מרחב השמות.

בדיקת יומני הבקר

ביומנים של ה-Pod של הבקר מופיעים מידע ושגיאות שקשורים להתאמה של משאבי Config Connector.

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

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

אם התקנתם את Config Connector במצב מרחב שמות, הפקודה הקודמת תציג את היומנים של כל ה-Pods של הבקרים ביחד. כדי לבדוק את היומנים של ה-Pod של הבקר במרחב שמות ספציפי, מריצים את הפקודה:

kubectl logs -n cnrm-system \
    -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -c manager

מחליפים את NAMESPACE בשם של מרחב השמות.

איך בודקים את היומנים של Config Connector ושולחים אליהם שאילתות

נטישה ורכישה של המשאב

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

מעדכנים את הגדרת ה-YAML של המשאב של Config Connector ומגדירים את ההערה cnrm.cloud.google.com/deletion-policy לערך abandon.
מחילים את הגדרת ה-YAML המעודכנת כדי לעדכן את המדיניות בנושא מחיקת נתונים של המשאב של Config Connector.
נטישת המשאב של Config Connector.
מעדכנים את השדות הבלתי ניתנים לשינוי שצריך לשנות בהגדרת ה-YAML.
מחילים את הגדרת ה-YAML המעודכנת כדי לרכוש את המשאב שננטש.

פתרון בעיות לפי סוג הבעיה

השתמשו בטבלה הבאה כדי לפתור בעיות בהתאם לסוג תיאור הבעיה.

סוג הבעיה	בעיות נפוצות
התאמה	המשאב מתעדכן כל 5-15 דקות ההתאמה נכשלת או נכנסת ללולאה בגלל עדכוני שדות אוטומטיים ניסיונות חוזרים תכופים במשאבים שנכשלו מנצלים את מכסות ה-API למשאב אין סטטוס ‫KNV2005: סנכרון מעדכן משאב באופן מוגזם משאב שנמחק על ידי Config Connector Controller Pod OOMKilled
מחיקה	מחיקות של מרחבי שמות תקועות במצב `Terminating` מחיקות של משאבים תקועות ב-`DeleteFailed` אחרי שהפרויקט נמחק
הרשאות	המטא-נתונים של Compute Engine לא מוגדרים שגיאה 403: לבקשה לא היו מספיק היקפי הרשאות לאימות ‫403 Forbidden: The caller does not have permission שגיאה 403: לגורם המבקש חסרה הרשאת IAM שגיאת עדכון ב-IAMPolicy, ב-IAMPartialPolicy וב-IAMPolicyMember
התקנה ושדרוגים	גרסה שלא נתמכת בהתקנות של תוסף Config Connector `failed calling webhook` ‫`PodSecurityPolicy` מונע שדרוגים
Configuration	אי אפשר לבצע שינויים בשדות שלא ניתנים לשינוי לא נמצאו התאמות לסוג "`RESOURCE_KIND`" התוויות לא מופצות למשאב Google Cloud שגיאה בגלל תווים מיוחדים בשם המשאב אי אפשר להסיר שדות מהמפרט של המשאב ערך לא תקין "merge" להערה `state-into-spec`

התאמה

בקטע הבא מפורטות בעיות נפוצות שקשורות להתאמת משאבים באמצעות Config Connector.

המשאב מתעדכן כל 5-15 דקות

תיאור הבעיה

הסטטוס של משאב Config Connector משתנה כל הזמן מ-UpToDate ל-Updating כל 5-10 דקות.

מטרה

סביר להניח ש-Config Connector מזהה הבדלים לא מכוונים בין המצב הרצוי של המשאב לבין המצב בפועל, ולכן Config Connector מעדכן את המשאב כל הזמן.

רזולוציה

קודם כול, ודאו שאין לכם מערכות חיצוניות שמשנות כל הזמן את Config Connector או את המשאב של Google Cloud (לדוגמה, צינורות עיבוד נתונים של CI/CD, בקרים בהתאמה אישית, משימות cron וכו').

אם ההתנהגות לא נובעת ממערכת חיצונית, בודקים אם Google Cloud משנה את הערכים שצוינו במשאב של Config Connector. לדוגמה, במקרים מסוימים, Google Cloud משנה את העיצוב (למשל, אותיות רישיות) של ערכי השדות, מה שמוביל להבדל בין המצב הרצוי של המשאב לבין המצב בפועל.

בודקים את המצב של המשאב Google Cloud באמצעות ה-API בארכיטקטורת REST (לדוגמה, ל-ContainerCluster) או באמצעות Google Cloud CLI. לאחר מכן, משווים את המצב הזה למשאב של Config Connector. מחפשים שדות שהערכים שלהם לא תואמים, ואז מעדכנים את המשאב של Config Connector בהתאם. חשוב במיוחד לבדוק אם יש ערכים ש- Google Cloudשינה את הפורמט שלהם. לדוגמה, ראו את הבעיות ב-GitHub‏ ‎#578 ו-‎#294.

חשוב לציין שזו לא שיטה מושלמת כי מודלי המשאבים של Config Connector ושלGoogle Cloud שונים, אבל היא אמורה לאפשר לכם לזהות את רוב המקרים של הבדלים לא מכוונים.

אם לא הצלחתם לפתור את הבעיה, תוכלו לקבל עזרה נוספת.

ההתאמה נכשלת או נכנסת ללולאה בגלל עדכוני שדות אוטומטיים

הבעיה הזו מתרחשת כש- Google Cloud מעדכן באופן אוטומטי שדה במשאב שמשתמש בהערה cnrm.cloud.google.com/state-into-spec: merge.

תיאור הבעיה

המשאב של Config Connector נכנס לסטטוס UpdateFailed או עובר שוב ושוב לסטטוס Updating אחרי ש- Google Cloud מעדכן באופן אוטומטי שדה שלא ציינתם במניפסט ה-YAML.

לדוגמה, אחרי ש-Cloud SQL מבצע עדכון תחזוקה אוטומטי במשאב SQLInstance, יכול להיות שההתאמה תיכשל ותופיע שגיאה כמו:

Update call failed: error updating: patching SQLInstance ... maintenanceVersion failed: googleapi: Error 400: Invalid request: The requested maintenance version is not an available maintenance version to upgrade. Please refer to the availableMaintenanceVersions on the instance resource to see the available maintenance versions.., invalid

מטרה

למשאב יש את ההערה cnrm.cloud.google.com/state-into-spec: merge. ההערה הזו הייתה ברירת המחדל למשאבים שנוצרו לפני גרסה 1.123.1 של Config Connector, ל-CustomResourceDefinitions ‏ (CRD) שנוספו בגרסה 1.113.0 ובגרסאות קודמות. ההערה הזו עשויה להופיע גם אם השדה spec.stateIntoSpec מוגדר לערך Merge במשאב המותאם אישית (CR) של ConfigConnector או ConfigConnectorContext.

כשההערה cnrm.cloud.google.com/state-into-spec מוגדרת ל-merge, Config Connector מאכלס שדות לא מוגדרים, כמו השדה spec.maintenanceVersion, בשדה spec של המשאב ב-Kubernetes במהלך ההתאמה הראשונית. כשהשדה הזה מתעדכן באופן אוטומטי במשאב הבסיסי על ידי Google Cloud , Config Connector מתייחס לערך הישן שמאוחסן בשדה spec כמצב היעד ומנסה לבטל את השינוי. אם ה-API של Google Cloud דוחה שדרוגים לאחור (כמו שקורה ב-Cloud SQL בשדה spec.maintenanceVersion), ההתאמה נכשלת.

רזולוציה

כדי לפתור את הבעיה, צריך להעביר את המשאב מההתנהגות של Merge להתנהגות של Absent, כדי ש-Config Connector יפסיק לאכלס שדות לא מוגדרים בשדה spec:

במניפסט ה-YAML של המשאב, משמיטים את השדה שמתעדכן אוטומטית (כמו השדה spec.maintenanceVersion) ומגדירים את ההערה cnrm.cloud.google.com/state-into-spec לערך absent.
כדי לנטוש את המשאב ב-Kubernetes ולרכוש אותו מחדש עם מניפסט ה-YAML המעודכן, פועלים לפי השלבים שמפורטים במאמר העברת משאבים מ-Merge אל Absent.

ניסיונות חוזרים תכופים במשאבים שנכשלו מנצלים את מכסות ה-API

הבעיה הזו מתרחשת כשיש כשלים עקביים בהתאמה של משאבים, למשל כשמשאב תלוי במשאב חיצוני חסר ב- Google Cloud או כשההגדרה שלו לא תקינה.

תיאור הבעיה

משאב של Config Connector נמצא בסטטוס UpdateFailed או DependencyNotFound, וניסיונות חוזרים של התאמה יוצרים תנועה מוגזמת ב- Google Cloud API או מנצלים את כל המכסות של Google Cloud API.

מטרה

אם ההתאמה נכשלת, Config Connector מנסה שוב להשתמש במשאב באמצעות השהיה מעריכית לפני ניסיון חוזר (exponential backoff) עם השהיה מקסימלית של 2 דקות כברירת מחדל.

רזולוציה

למשאבים שמנוהלים על ידי בקרים ישירים ב-Config Connector בגרסה 1.160.0 ואילך, מגדירים את ההערה cnrm.cloud.google.com/backoff-max-delay-in-seconds כדי להגדיל את זמן ההשהיה המקסימלי לניסיון חוזר, או מגדירים את ההערה ל-"0" כדי להפסיק את הניסיונות החוזרים האוטומטיים.

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

אם יש בקר ישיר זמין למשאב, צריך לעבור לבקר הישיר ולהשתמש בהערה.
מתקנים את הכשל הבסיסי.
כמוצא אחרון, אפשר להסיר זמנית את המשאב מהניהול על ידי הגדרת ההערה cnrm.cloud.google.com/deletion-policy: "abandon" ומחיקת האובייקט של Kubernetes. לחלופין, אפשר להגדיר את spec.actuationMode: Paused ב-ConfigConnectorContext.

למשאב אין סטטוס

תיאור הבעיה

אין שדה status במשאבים שלך.

מטרה

סביר להניח ש-Config Connector לא פועל כמו שצריך.

רזולוציה

מוודאים ש-Config Connector פועל.

‫KNV2005: סנכרון מעדכן משאב באופן מוגזם

תיאור הבעיה

אתם משתמשים בסנכרון תצורות ומופיעות שגיאות KNV2005 במשאבים של Config Connector, כמו בדוגמה הבאה:

KNV2005: detected excessive object updates, approximately 6 times per
minute. This may indicate Config Sync is fighting with another controller over
the object.

מטרה

סביר להניח שסנכרון תצורות ו-Config Connector מתחרים על המשאב.

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

ברוב התחומים, אין בעיה עם קרבות. שדות שצוינו בסנכרון ההגדרות לא משתנים על ידי Config Connector. באופן דומה, סנכרון תצורות מתעלם משדות שלא צוינו בסנכרון תצורות ומוגדרים כברירת מחדל על ידי Config Connector. לכן, ברוב השדות, אין צורך לעדכן את אותו שדה גם ב-סנכרון תצורות וגם ב-Config Connector.

חריג אחד הוא שדות של רשימות. בדומה לאופן שבו Config Connector עשוי להגדיר כברירת מחדל שדות משנה בשדות של אובייקטים, Config Connector עשוי גם להגדיר כברירת מחדל שדות משנה באובייקטים בתוך רשימות. עם זאת, מכיוון ששדות של רשימות במשאבים של Config Connector הם אטומיים, הגדרת ברירת המחדל של שדות משנה נחשבת לשינוי הערך של הרשימה כולה.

לכן, סנכרון ההגדרות ו-Config Connector "יתחרו" על משאב אם סנכרון ההגדרות מגדיר שדה רשימה ו-Config Connector מגדיר כברירת מחדל שדות משנה כלשהם בתוך הרשימה הזו.

רזולוציה

כדי לעקוף את הבעיה, אתם יכולים:

מעדכנים את מניפסט המשאב במאגר של Config Sync כך שיתאים למה ש-Config Connector מנסה להגדיר במשאב.

אחת מהדרכים לעשות זאת היא להפסיק באופן זמני את סנכרון ההגדרות האישיות, להמתין עד ש-Config Connector יסיים את ההתאמה של המשאב, ואז לעדכן את מניפסט המשאב כך שיתאים למשאב בשרת ה-API של Kubernetes.
כדי למנוע מסנכרון ההגדרות להגיב לעדכונים של המשאב בשרת ה-API של Kubernetes, מגדירים את ההערה client.lifecycle.config.k8s.io/mutation ל-ignore. איך מגדירים שסנכרון ההגדרות יתעלם משינויים באובייקטים
כדי למנוע מ-Config Connector לעדכן את המפרט של המשאב, מגדירים את ההערה cnrm.cloud.google.com/state-into-spec לערך absent במשאב. ההערה הזו לא נתמכת בכל המשאבים. כדי לבדוק אם המשאב תומך בהערה, עיינו בדף העזר של המשאב המתאים. מידע נוסף על ההערה

המשאב נמחק על ידי Config Connector

תיאור הבעיה

משאב נמחק מהאשכול, ואתם חושדים ש-Config Connector מחק אותו.

מטרה

‫Config Connector אף פעם לא מוחק את המשאבים שלכם בלי סיבה חיצונית. לדוגמה, הפעלת kubectl delete, שימוש בכלים לניהול הגדרות כמו Argo CD או שימוש בלקוח API בהתאמה אישית יכולים לגרום למחיקת משאבים.

טעות נפוצה היא ש-Config Connector יזם ומחק חלק מהמשאבים באשכול. לדוגמה, אם אתם משתמשים ב-Config Connector, יכול להיות שתבחינו בבקשות מחיקה ממנהל הבקר של Config Connector לגבי משאבים מסוימים, מהודעות ביומן של הקונטיינר או מיומני הביקורת של אשכול Kubernetes. בקשות המחיקה האלה הן תוצאה של טריגרים חיצוניים, ו-Config Connector מנסה ליישב את בקשות המחיקה.

רזולוציה

כדי להבין למה משאב נמחק, צריך לבדוק את בקשת המחיקה הראשונה שנשלחה למשאב המתאים. הדרך הכי טובה לבדוק את זה היא לבחון את יומני הביקורת של אשכול Kubernetes.

לדוגמה, אם אתם משתמשים ב-GKE, אתם יכולים להשתמש ב-Cloud Logging כדי לשלוח שאילתות ליומני הביקורת של אשכול GKE. לדוגמה, כדי לחפש את בקשות המחיקה הראשוניות של משאב BigQueryDataset בשם my-dataset במרחב השמות my-namespace, מריצים שאילתה כמו זו:

resource.type="k8s_cluster"
resource.labels.project_id="my-project-id"
resource.labels.cluster_name="my-cluster-name"
protoPayload.methodName="com.google.cloud.cnrm.bigquery.v1beta1.bigquerydatasets.delete"
protoPayload.resourceName="bigquery.cnrm.cloud.google.com/v1beta1/namespaces/my-namespace/bigquerydatasets/my-dataset"

בעזרת השאילתה הזו, אתם יכולים לחפש את בקשת המחיקה הראשונה ואז לבדוק את authenticationInfo.principalEmail של הודעת יומן המחיקה כדי לזהות את הסיבה למחיקה.

Controller Pod OOMKilled

תיאור הבעיה

מופיעה השגיאה OOMKilled ב-Pod של בקר Config Connector. הסטטוס של ה-Pod יכול להיות OOMKilled או Terminating.

מטרה

קונטיינר או Pod שלם נסגרו כי הם השתמשו ביותר זיכרון מהמותר. כדי לוודא שההתקנה בוצעה, אפשר להריץ את הפקודה kubectl describe:

kubectl describe pod POD_NAME -n cnrm-system

מחליפים את POD_NAME ב-Pod שבו רוצים לפתור את הבעיה.

בנוסף, בדיקה של יומני האירועים של ה-Pod יכולה לחשוף אירועים שקשורים ל-OOM.

רזולוציה

כדי לפתור את הבעיה, אתם יכולים להשתמש במשאב המותאם אישית ControllerResource כדי להגדיל את בקשת הזיכרון ואת מגבלת הזיכרון של ה-Pod.

מחיקה

בקטע הבא מפורטות בעיות נפוצות שקשורות לפעולות מחיקה שהמשתמשים מבצעים, שעלולות לגרום להתנגשויות עם Config Connector.

מחיקת מרחב השמות נתקעה במצב Terminating (בסיום)

תיאור הבעיה

מחיקת מרחב שמות תקועה בשלב Terminating.

מטרה

הבעיה הזו יכולה לקרות אם Config Connector מותקן במצב מרחב שמות, ואם ה-ConfigConnectorContext של מרחב השמות נמחק לפני שכל המשאבים של Config Connector במרחב השמות הזה נמחקו. כשמוחקים את ConfigConnectorContext של מרחב שמות, Config Connector מושבת במרחב השמות הזה, וכך נמנעת המחיקה של משאבי Config Connector שנותרו במרחב השמות.

רזולוציה

כדי לפתור את הבעיה, צריך לבצע ניקוי מאולץ ואז למחוק ידנית את המשאבים הבסיסיים של Google Cloud .

כדי למנוע את הבעיה הזו בעתיד, צריך למחוק את ConfigConnectorContext רק אחרי שכל המשאבים של Config Connector במרחב השמות שלו נמחקו מ-Kubernetes. אל תמחקו מרחבי שמות שלמים לפני שכל המשאבים של Config Connector במרחב השמות הזה נמחקו, כי יכול להיות ש-ConfigConnectorContext יימחק קודם.

מחיקת המשאב נתקעה במצב DeleteFailed אחרי שהפרויקט נמחק

תיאור הבעיה

מחיקת משאב של Config Connector נכשלת עם הסטטוס DeleteFailed.

מטרה

הבעיה הזו יכולה לקרות אם פרויקט ב- Google Cloud נמחק לפני המשאב.

רזולוציה

כדי לפתור את הבעיה, שחזרו את הפרויקט ב-Google Cloud כדי לאפשר ל-Config Connector למחוק את המשאבים הצאצאים שנותרו מ-Kubernetes. אפשר גם לבצע ניקוי מאולץ.

כדי למנוע את הבעיה הזו בעתיד, מחקו פרויקטים ב- Google Cloud רק אחרי שכל המשאבים הצאצאים של Config Connector נמחקו מ-Kubernetes. אל תמחקו מרחבי שמות שלמים שעשויים להכיל גם משאב Project וגם את משאבי הצאצא שלו ב-Config Connector, כי יכול להיות שמשאב ה-Project יימחק קודם.

הרשאות ואימות

בקטע הבא מפורטות בעיות נפוצות שקשורות להרשאות ולאימות.

המטא-נתונים של Compute Engine לא מוגדרים

תיאור הבעיה

הסטטוס של משאב Config Connector הוא UpdateFailed, ומוצגת הודעה שהמטא-נתונים של Compute Engine לא מוגדרים, בדומה לשגיאה הבאה:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
metadata: Compute Engine metadata "instance/service-accounts/default/token?
scopes=https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)compute%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSIN
G)auth%!F(MISSING)cloud-platform%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)cloud-identity%!C(MISSING)https%!A(MISSING)%!F(MISS
ING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)ndev.clouddns.readwrite%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSIN
G)devstorage.full_control%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)userinfo.email%!C(MISSING)https%!A(MISSING)%!F(MISSING)%!F
(MISSING)www.googleapis.com%!F(MISSING)auth%!F(MISSING)drive.readonly" not
defined, detail:

מטרה

סביר להניח שחשבון השירות של IAM שמשמש את Config Connector לא קיים.

רזולוציה

כדי לפתור את הבעיה, ודאו שחשבון השירות של IAM שמשמש את Config Connector קיים.

כדי למנוע את הבעיה הזו בעתיד, חשוב לפעול לפי הוראות ההתקנה של Config Connector.

שגיאה 403: היקפי ההרשאות לאימות בבקשה לא מספיקים

תיאור הבעיה

למשאב של Config Connector יש סטטוס UpdateFailed עם הודעה שמציינת שגיאה 403 בגלל היקפי הרשאות לא מספיקים, בדומה לשגיאה הבאה:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner-instance": googleapi: Error 403: Request had
insufficient authentication scopes.

מטרה

כנראה שאיחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול GKE.

כדי לוודא שאיחוד זהויות של עומסי עבודה ל-GKE לא מופעל, מבצעים את השלבים הבאים:

שומרים את הגדרת ה-Pod הבאה בתור wi-test.yaml:
```
apiVersion: v1
kind: Pod
metadata:
  name: workload-identity-test
  namespace: cnrm-system
spec:
  containers:
  - image: google/cloud-sdk:slim
    name: workload-identity-test
    command: ["sleep","infinity"]
  serviceAccountName: cnrm-controller-manager
```
אם התקנתם את Config Connector באמצעות מצב מרחב שמות, הערך של serviceAccountName צריך להיות cnrm-controller-manager-NAMESPACE. מחליפים את NAMESPACE במרחב השמות שבו השתמשתם במהלך ההתקנה.
יוצרים את ה-Pod באשכול GKE:
```
kubectl apply -f wi-test.yaml
```

פותחים סשן אינטראקטיבי ב-Pod:

kubectl exec -it workload-identity-test \
    --namespace cnrm-system \
    -- /bin/bash

ציינו את הזהות שלכם:
```
gcloud auth list
```
מוודאים שהזהות שמופיעה ברשימה תואמת לחשבון השירות של Google שמקושר למשאבים שלכם.

אם מופיע חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, סימן שאיחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול או במאגר הצמתים של GKE.
יוצאים מהסשן האינטראקטיבי ומוחקים את ה-Pod מאשכול ה-GKE:
```
kubectl delete pod workload-identity-test \
    --namespace cnrm-system
```

רזולוציה

כדי לפתור את הבעיה, ודאו שאיחוד זהויות של עומסי עבודה ל-GKE מופעל באשכול.

אם השגיאה עדיין מופיעה, ודאו שהפעלתם את איחוד הזהויות של עומסי עבודה ל-GKE במאגרי הצמתים של האשכול.

‫403 אסור: למבצע הקריאה אין הרשאה

תיאור הבעיה

למשאב של Config Connector יש סטטוס UpdateFailed עם הודעה שמציינת שגיאת 403 בגלל איחוד זהויות של עומסי עבודה ל-GKE, בדומה לשגיאה הבאה:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": Get
"https://spanner.googleapis.com/v1/projects/my-project/instances/my-spanner-instance?alt=json":
compute: Received 403 `Unable to generate access token; IAM returned 403
Forbidden: The caller does not have permission
This error could be caused by a missing IAM policy binding on the target IAM
service account.
For more information, refer to the Workload Identity documentation:
  https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#creating_a_relationship_between_ksas_and_gsas

מטרה

לחשבון השירות של Config Connector ב-Kubernetes אין את הרשאות ה-IAM המתאימות כדי להתחזות לחשבון השירות שלכם ב-IAM כמשתמש של איחוד זהויות של עומסי עבודה ל-GKE.

רזולוציה

כדי לפתור את הבעיה ולמנוע אותה בעתיד, קראו את הוראות ההתקנה של Config Connector.

שגיאה 403: חסרה הרשאת IAM לגורם המזמן

תיאור הבעיה

הסטטוס של המשאב של Config Connector הוא UpdateFailed, עם הודעה שלפיה למבצע הקריאה החוזרת חסרה הרשאת IAM, בדומה לשגיאה הבאה:

Update call failed: error fetching live state: error reading underlying
resource: summary: Error when reading or editing SpannerInstance
"my-project/my-spanner- instance": googleapi: Error 403: Caller is missing IAM
permission spanner.instances.get on resource
projects/my-project/instances/my-spanner-instance., detail:

מטרה

בחשבון השירות של IAM שמשמש את Config Connector חסרה הרשאת IAM שצוינה בהודעה, שנדרשת כדי לנהל את המשאב Google Cloud .

רזולוציה

אם השגיאה עדיין מופיעה אחרי שהקציתם לחשבון השירות ב-IAM את ההרשאות המתאימות, ודאו שהמשאב נוצר בפרויקט הנכון. בודקים את השדה spec.projectRef של המשאב של Config Connector (או את ההערה cnrm.cloud.google.com/project-id אם המשאב לא תומך בשדה spec.projectRef) ומוודאים שהמשאב מפנה לפרויקט הנכון. שימו לב: אם לא מציינים פרויקט יעד במשאב או במרחב השמות, Config Connector משתמש בשם של מרחב השמות כמזהה הפרויקט. איך מגדירים את פרויקט היעד למשאבים ברמת הפרויקט

אם עדיין מופיעה אותה שגיאה, בודקים אם איחוד זהויות של עומסי עבודה ל-GKE מופעל באשכול GKE.

כדי למנוע את הבעיה הזו בעתיד, חשוב לפעול לפי הוראות ההתקנה של Config Connector.

שגיאת עדכון ב-IAMPolicy, ב-IAMPartialPolicy וב-IAMPolicyMember

תיאור הבעיה

הסטטוס UpdateFailed מופיע עם הודעת שגיאה שמציינת שגיאה 400 כי חשבון השירות לא קיים:

Update call failed: error setting policy member: error applying changes: summary: Request `Create IAM Members roles/[MYROLE] serviceAccount:[NAME]@[PROJECT_ID]. for project \"projects/[PROJECT_ID]\"` returned error: Error applying IAM policy for project \"projects/[PROJECT_ID]\": Error setting IAM policy for project \"projects/[PROJECT_ID]\": googleapi: Error 400: Service account [NAME]@[PROJECT_ID]. does not exist., badRequest

מטרה

אם תמחקו משאב של IAMServiceAccount ב-Config Connector לפני שתנקו את המשאבים של IAMPolicy,‏ IAMPartialPolicy ו-IAMPolicyMember שתלויים בחשבון השירות הזה, Config Connector לא יוכל לאתר את חשבון השירות שאליו מפנים משאבי ה-IAM האלה במהלך ההתאמה.

רזולוציה

כדי לפתור את הבעיה, צריך לבדוק את חשבונות השירות ולראות אם חשבון השירות שנדרש למשאבי ה-IAM האלה נמחק. אם חשבון השירות נמחק, צריך לנקות גם את המשאבים הקשורים של IAM Config Connector. ב-IAMPolicyMember, מוחקים את כל המשאב. ב-IAMPolicy וב-IAMParitialPolicy, מסירים רק את הקישורים שכוללים את חשבון השירות שנמחק. עם זאת, הניקוי הזה לא מסיר מיידית את קישורי התפקידים שלGoogle Cloud . קישורי התפקידים של Google Cloud נשמרים למשך 60 יום בגלל השמירה בחשבון השירות שנמחק. מידע נוסף זמין במאמרי העזרה של IAM בנושא מחיקת חשבון שירות Google Cloud.

כדי למנוע את הבעיה הזו, תמיד צריך לנקות את המשאבים של IAMPolicy,‏ IAMPartialPolicy,‏ IAMPolicyMember Config Connector לפני שמוחקים את IAMServiceAccount שאליו הם מפנים.

משאב אחד (`ServiceIdentity`) נכשל עם `Invalid service producer`

תיאור הבעיה

הסטטוס של המשאב ServiceIdentity הוא UpdateFailed, עם הודעת שגיאה דומה לזו:

Update call failed: error applying desired state: summary: Error creating Service Identity: Invalid service producer: ...

מטרה

השגיאה הזו מציינת שהמשאב שצוין לא תומך ביצירת זהות שירות על פי דרישה.

רזולוציה

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

gcloud beta services identity create --service SERVICE_NAME.googleapis.com

מחליפים את SERVICE_NAME בשם השירות, לדוגמה spanner.

אם הפקודה מצליחה, Config Connector יכול ליצור זהות לאותו שירות. אם הפקודה נכשלת, סימן ש-Config Connector לא יכול ליצור זהות לאותו שירות.

התקנה ושדרוגים

בקטע הבא מפורטות בעיות נפוצות שקשורות להתקנה או לשדרוג של גרסת Config Connector.

הגרסה לא נתמכת בהתקנות של תוסף Config Connector

תיאור הבעיה

אם לא הצלחתם להפעיל את התוסף Config Connector, תופיע הודעת השגיאה הבאה: Node version 1.15.x-gke.x s unsupported.

הודעת השגיאה מופיעה גם אם איחוד זהויות של עומסי עבודה ל-GKE או GKE Monitoring מושבתים.

מטרה

גרסת אשכול GKE לא עומדת בדרישות או שהתכונות הנדרשות מושבתות.

רזולוציה

כדי לפתור את השגיאה, ודאו שהגרסה של אשכול GKE עומדת בדרישות של הגרסה והתכונות. מוודאים שאיחוד הזהויות של עומסי העבודה ל-GKE ול-GKE Monitoring מופעל.

כדי לקבל את כל הגרסאות התקינות של האשכולות, מריצים את הפקודה הבאה:

gcloud container get-server-config --format "yaml(validMasterVersions)" \
    --zone ZONE

מחליפים את ZONE באזור של Compute Engine.

בוחרים גרסה מהרשימה שעומדת בדרישות.

`failed calling webhook`

תיאור הבעיה

אי אפשר להסיר את Config Connector, ומופיעה שגיאה דומה לזו:

error during reconciliation: error building deployment objects: error finalizing the deletion of Config Connector system components deployed by ConfigConnector controller: error waiting for CRDs to be deleted: error deleting CRD accesscontextmanageraccesslevels.accesscontextmanager.cnrm.cloud.google.com: Internal error occurred: failed calling webhook "abandon-on-uninstall.cnrm.cloud.google.com": failed to call webhook: Post "https://abandon-on-uninstall.cnrm-system.svc:443/abandon-on-uninstall?timeout=3s": service "abandon-on-uninstall" not found

מטרה

הבעיה הזו יכולה לקרות כשמשתמשים בתוסף Config Connector ומשביתים את Config Connector לפני שמסירים את ה-CRD של Config Connector.

רזולוציה

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

kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true

לאחר מכן אפשר להסיר את Config Connector.

‫`PodSecurityPolicy` מונע שדרוגים

תיאור הבעיה

אחרי מעבר מהתוסף Config Connector להתקנה ידנית ושדרוג של Config Connector לגרסה חדשה, פודים של cnrm לא מתעדכנים.

מטרה

השימוש ב-PodSecurityPolicies יכול למנוע עדכון של Pods ב-cnrm.

כדי לוודא שכללי המדיניות של PodSecurityPolicy מונעים את השדרוג, בודקים את האירועים של config-connector-operator ומחפשים שגיאה שדומה לזו:

create Pod configconnector-operator-0 in StatefulSet configconnector-operator failed error: pods "configconnector-operator-0" is forbidden: PodSecurityPolicy: unable to admit pod: [pod.metadata.annotations[seccomp.security.alpha.kubernetes.io/pod]: Forbidden: seccomp may not be set pod.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: Forbidden: seccomp may not be set]

רזולוציה

כדי לפתור את הבעיה, צריך לציין את ההערה ב-PodSecurityPolicy שתואמת להערה שמוזכרת בשגיאה. בדוגמה הקודמת, ההערה היא seccomp.security.alpha.kubernetes.io.

הגדרות אישיות

בקטע הבא מפורטות בעיות נפוצות שקשורות להגדרת משאבים.

אי אפשר לשנות שדות שלא ניתנים לשינוי

‫Config Connector דוחה עדכונים לשדות שלא ניתנים לשינוי בזמן הקבלה.

לדוגמה, אם תנסו לעדכן שדה שלא ניתן לשינוי באמצעות kubectl apply, הפקודה תיכשל מיד.

זה אומר שכלים שמחילים מחדש משאבים באופן רציף (לדוגמה, GitOps) עלולים להיתקע בזמן עדכון משאב אם הם לא מטפלים בשגיאות קבלה.

מכיוון ש-Config Connector לא מאפשר עדכונים לשדות שלא ניתנים לשינוי, הדרך היחידה לבצע עדכון כזה היא למחוק את המשאב וליצור אותו מחדש.

שגיאה בעדכון השדות שלא ניתנים לשינוי כשאין עדכון

יכול להיות שתראו את השגיאות הבאות בסטטוס של משאב Config Connector זמן קצר אחרי שתיצרו או תרכשו משאב Google Cloud באמצעות Config Connector:

Update call failed: error applying desired state: infeasible update: ({true \<nil\>}) would require recreation (דוגמה)
Update call failed: cannot make changes to immutable field(s) (דוגמה)

יכול להיות שלא עדכנתם את המשאב, אבל ה-API של Google Cloud ביצע שינוי בשדה שלא ניתן לשינוי, שנוהל על ידכם במשאב של Config Connector. זה גרם לחוסר התאמה בין המצב הרצוי לבין המצב בפועל של השדות שלא ניתנים לשינוי.

כדי לפתור את הבעיה, צריך לעדכן את הערכים של השדות הבלתי ניתנים לשינוי במשאב של Config Connector כך שיתאימו למצב בפועל. כדי לעשות את זה, צריך לבצע את הפעולות הבאות:

מעדכנים את הגדרת ה-YAML של המשאב של Config Connector ומגדירים את ההערה cnrm.cloud.google.com/deletion-policy לערך abandon.
מחילים את הגדרת ה-YAML המעודכנת כדי לעדכן את המדיניות בנושא מחיקת נתונים של המשאב של Config Connector.
נטישת המשאב של Config Connector.
מדפיסים את המצב הפעיל של המשאב התואם של Google Cloud באמצעות ה-CLI של gcloud.
מוצאים את חוסר ההתאמה בין הפלט של ה-CLI של gcloud לבין הגדרת ה-YAML של המשאב של Config Connector, ומעדכנים את השדות האלה בהגדרת ה-YAML.
מחילים את הגדרות ה-YAML המעודכנות כדי לרכוש את המשאב שננטש.

לא נמצאו התאמות לסוג "`RESOURCE_KIND`"

תיאור הבעיה

מוצגת השגיאה No matches for kind "RESOURCE_KIND".

מטרה

באשכול Kubernetes לא מותקן ה-CRD לסוג המשאב RESOURCE_KIND.

רזולוציה

מוודאים שסוג המשאב נתמך על ידי Config Connector.

אם הסוג נתמך, סימן שההתקנה של Config Connector לא מעודכנת או לא תקינה.

אם התקנתם את Config Connector באמצעות התוסף של GKE, ההתקנה אמורה להשתדרג באופן אוטומטי. אם התקנתם את Config Connector באופן ידני, תצטרכו לבצע שדרוג ידני.

כדי לבדוק אילו סוגי משאבים נתמכים בגרסאות השונות של Config Connector, אפשר לעיין במאגר של GitHub (לדוגמה, כאן מפורטים הסוגים שנתמכים ב-Config Connector בגרסה 1.44.0).

התוויות לא מופצות למשאב Google Cloud

תיאור הבעיה

התוויות בקובץ ה-YAML לא מופיעות במשאב Google Cloud .

מטרה

אי אפשר להוסיף תוויות לחלק מהמשאבים של Google Cloud .

רזולוציה

‫Config Connector מעביר את התוויות שנמצאות ב-metadata.labels למשאבGoogle Cloud הבסיסי. כדי לבדוק אם המשאב תומך בתוויות, צריך לעיין במאמרי העזרה של ה-API בארכיטקטורת REST של המשאב (לדוגמה, מאמרי העזרה של ה-API של PubSubTopic).

שגיאה בגלל תווים מיוחדים בשם המשאב

תיאור הבעיה

מוצגת שגיאה שקשורה לתווים לא חוקיים ב-metadata.name:

a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

מטרה

אי אפשר להשתמש בתווים מיוחדים בשדה metadata.name של Kubernetes.

רזולוציה

אם רוצים לתת למשאב שם שלא תקין ב-Kubernetes, אבל תקין ב- Google Cloud , אפשר להשתמש בשדה resourceID, כמו בדוגמה הבאה:

apiVersion: sql.cnrm.cloud.google.com/v1beta1
kind: SQLUser
metadata:
  name: 'test'
spec:
  instanceRef:
    name: sqlinstance-sample-postgresql
  host: "%"
  type: CLOUD_IAM_USER
  resourceID: test.example@example-project.iam

ההגדרה הזו גורמת ל-Config Connector להשתמש ב-resourceID במקום ב-metadata.name כשם המשאב.

אי אפשר להסיר שדות מהמפרט של המשאב

תיאור הבעיה

אם מסירים שדה מהמפרט של משאב Config Connector, הוא לא מוסר מהמשאב.

מטרה

אם מסירים שדה מהמפרט של משאב שמנוהל על ידי Config Connector, השדה לא מתרוקן או חוזר לערך ברירת המחדל. במקום זאת, השדה הזה הופך למנוהל באופן חיצוני.

רזולוציה

אם רוצים לשנות את הערך של שדה לריק או לברירת מחדל במשאבGoogle Cloud הבסיסי, צריך לאפס את השדה במפרט המשאב של Config Connector:

בשדה מסוג רשימה, מגדירים את השדה לרשימה ריקה באמצעות [].

בדוגמה הבאה מוצג השדה targetServiceAccounts שאנחנו רוצים להסיר:
```
spec:
  targetServiceAccounts:
    - external: "example-sa-1@example-project."
    - external: "example-sa-2@example-project."
```
כדי להסיר את השדה הזה, צריך להגדיר את הערך כריק:
```
spec:
  targetServiceAccounts: []
```
בשדה מסוג פרימיטיבי, מגדירים את השדה כריק באמצעות אחת מהאפשרויות הבאות:

סוג לא צוין ערך

מחרוזת ""

bool "false"

מספר שלם 0

בדוגמה הבאה מוצג השדה identityNamespace שאנחנו רוצים להסיר:
```
spec:
  workloadIdentityConfig:
    identityNamespace: "example-project."
```
כדי להסיר את השדה הזה, צריך להגדיר את הערך כריק:
```
spec:
  workloadIdentityConfig:
    identityNamespace: ""
```
בשדות מסוג אובייקט, אתם יכולים לנסות להגדיר את שדות המשנה של סוג האובייקט כריקים או כברירת מחדל, לפי ההנחיות בקטע הקודם, ולבדוק אם זה עובד. עם זאת, לא בטוח שזה יעבוד.

סוג	לא צוין ערך
מחרוזת	""
bool	"false"
מספר שלם	0

ערך לא תקין "merge" להערה `state-into-spec`

הבעיה הזו מתרחשת כשמשאב משתמש בהערה cnrm.cloud.google.com/state-into-spec: merge, אבל סוג המשאב או הגרסה של Config Connector דוחים את הערך merge.

תיאור הבעיה

המשאב של Config Connector לא מצליח לבצע התאמה, ומופיעה הודעת שגיאה דומה לזו:

Update call failed: error applying desired state: invalid value "merge" for "cnrm.cloud.google.com/state-into-spec" annotation

מטרה

השגיאה הזו מתרחשת בגלל אחת מהסיבות הבאות:

סוג המשאב לא תומך בהתנהגות Merge, אבל למשאב יש את ההערה cnrm.cloud.google.com/state-into-spec: merge. יכול להיות שההערה הזו מוגדרת ישירות במשאב או עוברת בירושה מההגדרה spec.stateIntoSpec: Merge ב-CR של ConfigConnector או ConfigConnectorContext. הגדרות CRD שנוספו ב-Config Connector בגרסה 1.114.0 ואילך תומכות רק בהתנהגות של Absent.
שדרגתם לגרסה 1.134.0 או 1.134.1 של Config Connector, ויש לכם משאב SQLInstance קיים עם ההערה cnrm.cloud.google.com/state-into-spec: merge כברירת מחדל מגרסה קודמת. בגרסאות 1.134.0 ו-1.134.1 הייתה בעיה ידועה שדחתה את הערך merge במשאבי SQLInstance.

רזולוציה

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

סוג המשאב לא תומך בהתנהגות של Merge: מגדירים את ההערה cnrm.cloud.google.com/state-into-spec: absent במניפסט ה-YAML של המשאב, ומגדירים את השדה spec.stateIntoSpec לערך Absent ב-CR של ConfigConnector או ConfigConnectorContext. כדי לבדוק אם סוג המשאב תומך בהתנהגות של Merge, קראו את המאמר סוגים עם תמיכה ב-Merge. אם ההערה כבר קיימת במשאב קיים באשכול, פועלים לפי השלבים שמפורטים בקטע העברת משאבים מ-Merge ל-Absent.
אתם משתמשים במשאב SQLInstance קיים בגרסה 1.134.0 או 1.134.1 של Config Connector: שדרגו את Config Connector לגרסה 1.134.2 ואילך. לחלופין, אפשר להעביר את המשאב SQLInstance להערה cnrm.cloud.google.com/state-into-spec: absent לפי השלבים שמפורטים במאמר העברת משאבים מ-Merge ל-Absent.

‫Config Connector לא מופעל בצמתים שמבוססים על Arm

אם האשכול מכיל מאגרי צמתים שמשתמשים בארכיטקטורת Arm (כמו סדרות המכונות C4A,‏ N4A או Tau T2A), יכול להיות שהרכיבים של Config Connector לא יפעלו. זו מגבלה ידועה, כי Config Connector לא תומך במערכות שמבוססות על Arm.

תסמינים

אם המכונה של Config Connector מושפעת מהבעיה הזו, יכול להיות שתיתקלו בתופעות הבאות:

פודים במרחב השמות cnrm-system נשארים במצב Pending.
יכול להיות שיוצג CrashLoopBackOff לפודים עם הודעת שגיאה ביומנים, בדומה ל: exec user process caused "exec format error".
תיאור ה-Pod חושף כשלים בתזמון או חוסר התאמה בארכיטקטורה.

רזולוציה

כדי לפתור את הבעיה, ודאו שרכיבי Config Connector מתוזמנים בצמתים עם ארכיטקטורת x86:

הוספת מאגר צמתים של x86: אם האשכול מכיל רק צומתי Arm, צריך להוסיף לפחות מאגר צמתים אחד באמצעות סוג מכונה של x86 (כמו e2-standard-2) כדי לארח את הפודים של הבקר של Config Connector.
אימות של פגמי הצמתים: בדרך כלל צומתי GKE Arm פגומים עם kubernetes.io/arch=arm64:NoSchedule כדי למנוע תזמון של עומסי עבודה מסוג x86 בלבד. חשוב לוודא שלא הוספתם טולרנטיות לפריסות של Config Connector, שיאפשרו להן לפעול בצמתים האלה.

ניקוי נתונים מאולץ

אם משאבי Config Connector תקועים במחיקה ואתם רק רוצים להיפטר מהם באשכול Kubernetes, אתם יכולים לאלץ את המחיקה שלהם על ידי מחיקת ה-finalizers שלהם.

כדי למחוק את ה-finalizers של משאב, עורכים את המשאב באמצעות kubectl edit, מוחקים את השדה metadata.finalizers ושומרים את הקובץ כדי שהשינויים יישמרו בשרת ה-API של Kubernetes.

מחיקת ה-finalizers של משאב מאפשרת למחוק אותו באופן מיידי מאשכול Kubernetes, ולכן יכול להיות ש-Config Connector לא יספיק להשלים את המחיקה של המשאב הבסיסי ב-Google Cloud . לכן, יכול להיות שתרצו למחוק ידנית את המשאבים של Google Cloud לאחר מכן.

מעקב

מעקב אחרי Config Connector ועיון ביומנים שלו יכולים לעזור לכם לזהות את מקור הבעיות ולהבין טוב יותר התנהגות לא צפויה.

מדדים

אתם יכולים להשתמש ב-Prometheus כדי לאסוף ולהציג מדדים מ-Config Connector.

רישום ביומן

כל ה-Pods של Config Connector מוציאים יומנים מובְנים בפורמט JSON.

היומנים של Pods של הבקר שימושיים במיוחד לניפוי באגים בבעיות שקשורות להתאמה של משאבים.

כדי לשלוח שאילתות על יומנים של משאבים ספציפיים, אפשר לסנן לפי השדות הבאים בהודעות ביומן:

‫logger: מכיל את סוג המשאב באותיות קטנות. לדוגמה, למשאבים של PubSubTopic יש logger של pubsubtopic-controller.
‫resource.namespace: מכיל את מרחב השמות של המשאב.
‫resource.name: מכיל את שם המשאב.

שימוש ב-Logging לשאילתות מתקדמות ביומנים

אם אתם משתמשים ב-GKE, אתם יכולים להשתמש ב-Cloud Logging כדי לשלוח שאילתות ליומנים של משאב ספציפי באמצעות השאילתה הבאה:

# Filter to include only logs coming from the controller Pods
resource.type="k8s_container"
resource.labels.container_name="manager"
resource.labels.namespace_name="cnrm-system"
labels.k8s-pod/cnrm_cloud_google_com/component="cnrm-controller-manager"

# Filter to include only logs coming from a particular GKE cluster
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.location="GKE_CLUSTER_LOCATION"

# Filter to include only logs for a particular Config Connector resource
jsonPayload.logger="RESOURCE_KIND-controller"
jsonPayload.resource.namespace="RESOURCE_NAMESPACE"
jsonPayload.resource.name="RESOURCE_NAME"

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

‫GKE_CLUSTER_NAME בשם של אשכול GKE שבו פועל Config Connector
‫GKE_CLUSTER_LOCATION עם המיקום של אשכול GKE שבו פועל Config Connector. לדוגמה, us-central1.
‫RESOURCE_KIND עם סוג המשאב באותיות קטנות. לדוגמה, pubsubtopic.
RESOURCE_NAMESPACE במרחב השמות של המשאב.
‫RESOURCE_NAME בשם המשאב.

עזרה נוספת

כדי לקבל עזרה נוספת, אתם יכולים לדווח על בעיה ב-GitHub או לפנות לתמיכה שלGoogle Cloud .

פתרון בעיות ב-Config Connector

בדיקת הסטטוס והתנאים של Config Connector

בדיקת הגרסה של Config Connector

בדיקת הסטטוס והאירועים של המשאב

מוודאים ש-Config Connector פועל

בדיקת יומני הבקר

נטישה ורכישה של המשאב

פתרון בעיות לפי סוג הבעיה

התאמה

המשאב מתעדכן כל 5-15 דקות

תיאור הבעיה

מטרה

רזולוציה

ההתאמה נכשלת או נכנסת ללולאה בגלל עדכוני שדות אוטומטיים

תיאור הבעיה

מטרה

רזולוציה

ניסיונות חוזרים תכופים במשאבים שנכשלו מנצלים את מכסות ה-API

תיאור הבעיה

מטרה

רזולוציה

למשאב אין סטטוס

תיאור הבעיה

מטרה

רזולוציה

‫KNV2005: סנכרון מעדכן משאב באופן מוגזם

תיאור הבעיה

מטרה

רזולוציה

המשאב נמחק על ידי Config Connector

תיאור הבעיה

מטרה

רזולוציה

Controller Pod OOMKilled

תיאור הבעיה

מטרה

רזולוציה

מחיקה

מחיקת מרחב השמות נתקעה במצב Terminating (בסיום)

תיאור הבעיה

מטרה

רזולוציה

מחיקת המשאב נתקעה במצב DeleteFailed אחרי שהפרויקט נמחק

תיאור הבעיה

מטרה

רזולוציה

הרשאות ואימות

המטא-נתונים של Compute Engine לא מוגדרים

תיאור הבעיה

מטרה

רזולוציה

שגיאה 403: היקפי ההרשאות לאימות בבקשה לא מספיקים

תיאור הבעיה

מטרה

רזולוציה

‫403 אסור: למבצע הקריאה אין הרשאה

תיאור הבעיה

מטרה

רזולוציה

שגיאה 403: חסרה הרשאת IAM לגורם המזמן

תיאור הבעיה

מטרה

רזולוציה

שגיאת עדכון ב-IAMPolicy, ב-IAMPartialPolicy וב-IAMPolicyMember

תיאור הבעיה

מטרה

רזולוציה

משאב אחד (ServiceIdentity) נכשל עם Invalid service producer

תיאור הבעיה

מטרה

רזולוציה

התקנה ושדרוגים

הגרסה לא נתמכת בהתקנות של תוסף Config Connector

תיאור הבעיה

מטרה

רזולוציה

failed calling webhook

תיאור הבעיה

מטרה

רזולוציה

משאב אחד (`ServiceIdentity`) נכשל עם `Invalid service producer`

`failed calling webhook`

‫`PodSecurityPolicy` מונע שדרוגים

לא נמצאו התאמות לסוג "`RESOURCE_KIND`"

ערך לא תקין "merge" להערה `state-into-spec`