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

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

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

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

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

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

סוג הבעיה בעיות נפוצות
התאמה
מחיקה
הרשאות
התקנה ושדרוגים
Configuration

התאמה

בקטע הבא מפורטות בעיות נפוצות שקשורות להשוואה בין מקורות מידע על ידי 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:

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

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

תיאור הבעיה

למשאבים שלכם אין שדה 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 מגדיר כברירת מחדל שדות משנה כלשהם בתוך הרשימה הזו.

רזולוציה

כדי לפתור את הבעיה, אפשר לנסות את האפשרויות הבאות:

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

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

  2. כדי למנוע מסנכרון תצורות להגיב לעדכונים של המשאב בשרת ה-API של Kubernetes, מגדירים את האנוטציה client.lifecycle.config.k8s.io/mutation לערך ignore. קראו עוד על איך מגדירים ל-סנכרון תצורות להתעלם משינויים באובייקטים

  3. כדי למנוע מ-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

תיאור הבעיה

מחיקת מרחב שמות נתקעה בשלב 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 לא מופעל:

  1. שומרים את הגדרת ה-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 במרחב השמות שבו השתמשתם במהלך ההתקנה.

  2. יוצרים את ה-Pod באשכול GKE:

    kubectl apply -f wi-test.yaml

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

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

  4. ציינו את הזהות שלכם:

    gcloud auth list

  5. מוודאים שהזהות שמופיעה ברשימה תואמת לחשבון השירות של Google שקשור למשאבים שלכם.

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

  6. יוצאים מהסשן האינטראקטיבי, ואז מוחקים את ה-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

מטרה

לחשבון השירות של 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 את הרשאות ה-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.

רזולוציה

כדי לפתור את השגיאה, צריך קודם למחוק את ה-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 Pods.

מטרה

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

כדי לוודא שכללי 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) (דוגמה)

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

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

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

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

תיאור הבעיה

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

מטרה

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

רזולוציה

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

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

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

כדי לבדוק אילו סוגי משאבים נתמכים בגרסאות השונות של Config Connector, אפשר לעיין במאגר של GitHub (לדוגמה, כאן מפורטים הסוגים שנתמכים ב-Config Connector בגרסה 1.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])?)*')

מטרה

תווים מיוחדים לא חוקיים בשדה 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: "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: ""

  • בשדות מסוג אובייקט, אתם יכולים לנסות להגדיר את שדות המשנה של סוג האובייקט כריקים או כברירת מחדל, לפי ההנחיות בקטע הקודם, ולבדוק אם זה עובד. עם זאת, לא בטוח שזה יעבוד.

הערך "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 ב-ConfigConnector או ב-ConfigConnectorContext CR. כדי לבדוק אם סוג המשאב תומך בהתנהגות של Merge, קראו את המאמר סוגים עם תמיכה ב-Merge. אם ההערה כבר קיימת במשאב באשכול, פועלים לפי השלבים שמפורטים בקטע העברת משאבים מ-Merge אל Absent.
  • אתם משתמשים במשאב SQLInstance קיים ב-Config Connector בגרסה 1.134.0 או 1.134.1: צריך לשדרג את 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 ואז לשמור את הקובץ כדי לשמור את השינויים בשרת Kubernetes API.

מחיקת ה-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 .