Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

פתרון בעיות ב-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 במצב מרחב שמות, יהיה לכם Pod אחד של בקר (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 דקות למשאב אין סטטוס KNV2005: syncer excessively updating resource מקור מידע נמחק על ידי Config Connector Controller Pod OOMKilled
מחיקה	מחיקות של מרחבי שמות תקועות ב-`Terminating` מחיקות של משאבים תקועות ב-`DeleteFailed` אחרי שהפרויקט נמחק
הרשאות	לא הוגדרו מטא-נתונים של Compute Engine שגיאה 403: לבקשה לא צורפו היקפי אימות מספיקים 403 Forbidden: The caller does not have permission שגיאה 403: ליישות שקוראת ל-API חסרה הרשאת IAM שגיאת עדכון ב-IAMPolicy, ב-IAMPartialPolicy וב-IAMPolicyMember
התקנה ושדרוגים	הגרסה לא נתמכת בהתקנות של תוסף Config Connector `failed calling webhook` `PodSecurityPolicy` מונע שדרוגים
Configuration	אי אפשר לבצע שינויים בשדות שלא ניתן לשנות לא נמצאו התאמות לסוג Foo התוויות לא מועברות למשאב Google Cloud שגיאה בגלל תווים מיוחדים בשם המשאב לא ניתן להסיר שדות ממפרט המשאב

התאמה

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

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

תיאור הבעיה

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

מטרה

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

רזולוציה

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

אם הבעיה לא נובעת ממערכת חיצונית, בודקים אם 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 הם שונים, אבל היא אמורה לעזור לכם לזהות את רוב המקרים של הבדלים לא מכוונים.

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

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

תיאור הבעיה

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

מטרה

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

רזולוציה

בודקים ש-Config Connector פועל.

KNV2005: syncer excessively updating resource

תיאור הבעיה

אתם משתמשים ב-סנכרון תצורות ורואים שגיאות 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 Connector יסיים את ההתאמה של המשאב ואז לעדכן את מניפסט המשאב כך שיתאים למשאב בשרת Kubernetes API.
כדי למנוע מ-סנכרון תצורות להגיב לעדכונים של המשאב ב-Kubernetes API Server, מגדירים את האנוטציה client.lifecycle.config.k8s.io/mutation לערך ignore. מידע נוסף על הגדרת Config Sync כך שיתעלם משינויים באובייקטים
כדי למנוע מ-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 בשם foo במרחב השמות bar, מריצים שאילתה כמו הבאה:

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/bar/bigquerydatasets/foo"

באמצעות השאילתה הזו, תוכלו לחפש את בקשת המחיקה הראשונה ואז לבדוק את 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.

מטרה

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

רזולוציה

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

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

מחיקת משאב נתקעת במצב 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 באמצעות namespaced mode,‏ 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 Forbidden: למתקשר אין הרשאה

תיאור הבעיה

למשאב 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

מטרה

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

רזולוציה

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

שגיאה 403: ליישות שקוראת ל-API חסרה הרשאת 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 את הרשאות ה-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].iam.gserviceaccount.com 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].iam.gserviceaccount.com 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.

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

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.

רזולוציה

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

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 Pods.

מטרה

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

כדי לוודא ש-PodSecurityPolicies מונעים את השדרוג, בודקים את האירועים של 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 זמן קצר אחרי שיוצרים או מקבלים משאב באמצעות Config Connector: Google Cloud

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

יכול להיות שהמשמעות היא שלא עדכנתם את המשאב בפועל, אלא ש- Google Cloud API ביצע שינוי בשדה שלא ניתן לשינוי שנוהל על ידכם במשאב 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 המעודכנות כדי להשיג את המשאב הנטוש.

אין התאמות לסוג 'Foo'

תיאור הבעיה

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

מטרה

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

רזולוציה

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

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

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

בודקים במאגר GitHub אילו סוגי משאבים נתמכים על ידי גרסאות Config Connector שונות (לדוגמה, אלה הסוגים שנתמכים על ידי Config Connector v1.44.0).

התוויות לא מועברות ל- Google Cloud resource

תיאור הבעיה

התוויות בקובץ ה-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])?)*')

מטרה

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

רזולוציה

אם רוצים לתת למשאב שם שהוא לא שם תקף ב-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: "foo-bar@foo-project.iam.gserviceaccount.com"
    - external: "bar@foo-project.iam.gserviceaccount.com"
```
כדי להסיר את השדה הזה, צריך להגדיר את הערך כריק:
```
spec:
  targetServiceAccounts: []
```
בשדה מסוג פרימיטיבי, כדי להגדיר את השדה כריק, משתמשים באחת מהאפשרויות הבאות:

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

מחרוזת ""

bool ‫"false"

מספר שלם 0

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

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

הפעלת Config Connector נכשלת בצמתים מבוססי-Arm

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

תסמינים

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

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

רזולוציה

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

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

שימוש ברישום ביומן לחיפוש מתקדם ביומן

אם אתם משתמשים ב-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 דקות

תיאור הבעיה

מטרה

רזולוציה

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

תיאור הבעיה

מטרה

רזולוציה

KNV2005: syncer excessively updating resource

תיאור הבעיה

מטרה

רזולוציה

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

תיאור הבעיה

מטרה

רזולוציה

Controller Pod OOMKilled

תיאור הבעיה

מטרה

רזולוציה

מחיקה

מחיקת מרחב שמות נתקעת במצב 'סיום'

תיאור הבעיה

מטרה

רזולוציה

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

תיאור הבעיה

מטרה

רזולוציה

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

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

תיאור הבעיה

מטרה

רזולוציה

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

תיאור הבעיה

מטרה

רזולוציה

‫403 Forbidden: למתקשר אין הרשאה

תיאור הבעיה

מטרה

רזולוציה

שגיאה 403: ליישות שקוראת ל-API חסרה הרשאת IAM

תיאור הבעיה

מטרה

רזולוציה

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

תיאור הבעיה

מטרה

רזולוציה

משאב ServiceIdentity נכשל עם Invalid service producer

תיאור הבעיה

מטרה

רזולוציה

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

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

תיאור הבעיה

מטרה

רזולוציה

failed calling webhook

תיאור הבעיה

מטרה

רזולוציה

PodSecurityPolicy מניעת שדרוגים

תיאור הבעיה

מטרה

רזולוציה

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

אי אפשר לשנות שדות שלא ניתן לערוך

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

אין התאמות לסוג 'Foo'

משאב `ServiceIdentity` נכשל עם `Invalid service producer`

`failed calling webhook`

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