פתרון בעיות ב-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.

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

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

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

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

רזולוציה

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

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

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

  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 בשם 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.

מטרה

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

מטרה

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

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

לא נמצאו התאמות לסוג "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.iam.gserviceaccount.com"
    - external: "example-sa-2@example-project.iam.gserviceaccount.com"

    כדי להסיר את השדה הזה, מגדירים את הערך כריק:

    spec:
  targetServiceAccounts: []

  • בשדה מסוג פרימיטיבי, מגדירים את השדה כריק באמצעות אחת מהאפשרויות הבאות:

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

    בדוגמה הבאה מוצג השדה identityNamespace שאנחנו רוצים להסיר:

    spec:
  workloadIdentityConfig:
    identityNamespace: "example-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 ב-ConfigConnector או ב-ConfigConnectorContext CR. ‫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 ושומרים את הקובץ כדי שהשינויים יישמרו בשרת ה-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 .