בעיות מוכרות ב-Config Sync

בדף הזה מפורטות בעיות ידועות בגרסאות נתמכות של סנכרון תצורות.

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

אם אתם משתתפים ב-Google Developer Program, כדאי לשמור את הדף הזה כדי לקבל התראות כשמתפרסם הערת גרסה שקשורה לדף הזה. מידע נוסף זמין במאמר בנושא דפים שמורים.

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

בוחרים את הגרסה של סנכרון תצורות:

בוחרים את קטגוריית הבעיה:

אפשר גם לסנן את הבעיות הידועות:

קטגוריה הגרסה שזוהתה גרסה קבועה הבעיה והפתרון העקיף
מדדים 1.5.0 1.21.0

תוקנה בעיה: מדדים שדווחו לגבי חבילות שנמחקו

אם מוחקים אובייקט RootSync או RepoSync, אבל לא מוחקים את האובייקט ResourceGroup עם אותו שם, סנכרון תצורות ממשיך לדווח על המדדים הבאים של האובייקט ResourceGroup:

  • rg_reconcile_duration_seconds
  • resource_group_total
  • resource_count
  • ready_resource_count
  • resource_ns_count
  • cluster_scoped_resource_count
  • crd_count
  • kcc_resource_count
  • pipeline_error_observed
האובייקט ResourceGroup נמחק באופן אוטומטי רק אם הפצת המחיקה הופעלה לפני המחיקה של האובייקט RootSync או RepoSync.

פתרון עקיף:

מחיקת האובייקט ResourceGroup:

kubectl delete resourcegroup RESOURCE_GROUP_NAME -n config-management-system

מחליפים את RESOURCE_GROUP_NAME בשם של ResourceGroup האובייקט שצריך למחוק. מידע נוסף על מתן שמות לאובייקטים זמין במאמר ResourceGroup Controller ו-ResourceGroup objects.ResourceGroup
תקינות הרכיבים 1.15.0

אי אפשר לתזמן את הכלי להתאמת נתונים

הכמות של המשאבים שנדרשת ל-Config Sync משתנה בהתאם להגדרות של RootSync או RepoSync. יש הגדרות מסוימות שדורשות יותר משאבים מאחרות.

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

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

פתרון עקיף:

ב-GKE Autopilot או ב-Standard עם הקצאת הרשאות אוטומטית לצמתים, המערכת אמורה לראות כמה משאבים נדרשים וליצור צמתים בגודל מתאים כדי לאפשר תזמון. עם זאת, אם אתם מגדירים את הצמתים או את גודלי המופעים של הצמתים באופן ידני, יכול להיות שתצטרכו לשנות את ההגדרות האלה כדי להתאים אותן לדרישות המשאבים של ה-Pod של מנגנון ההתאמה.
מדדים 1.15.0

הייצוא נכשל. ההרשאה נדחתה

כברירת מחדל, כשהרכיב reconciler-manager מזהה Application Default Credentials, הרכיב otel-collector מוגדר לייצא מדדים אל Prometheus, אל Cloud Monitoring ואל Monarch.

פתרון עקיף:

‫otel-collector מתעד שגיאות אם לא הגדרתם את Cloud Monitoring או התאמתם אישית את מסנני המדדים ו-Cloud Monarch.
מדדים 1.15.0

קריסת otel-collector עם הגדרה בהתאמה אישית

אם מנסים לשנות או למחוק אחד מ-ConfigMaps שמוגדרים כברירת מחדל, otel-collector או otel-collector-google-cloud, יכול להיות שתופיע שגיאה ב-otel-collector או שהוא יקרוס כי הוא לא יוכל לטעון את ה-ConfigMap הנדרש.

פתרון עקיף:

כדי להתאים אישית את הגדרות הייצוא של המדדים, יוצרים ConfigMap בשם otel-collector-custom במרחב השמות config-management-monitoring.
תיקון שגיאות

סנכרון תצורות מתנגש עם עצמו

יכול להיות ש-סנכרון תצורות נמצא במצב של מאבק בין בקרי. עם עצמו. הבעיה הזו מתרחשת אם מגדירים ערך ברירת מחדל לשדה אופציונלי של משאב במאגר Git. לדוגמה, הגדרת apiGroup: "" לנושא של RoleBinding מפעילה את זה כי השדה apiGroup: "" הוא אופציונלי ומחרוזת ריקה היא ערך ברירת המחדל.apiGroup ערכי ברירת המחדל של שדות מסוג מחרוזת, בוליאני ומספר שלם הם "", false ו-0 (בהתאמה).

פתרון עקיף:

מסירים את השדה מהצהרת המשאב.
תיקון שגיאות

התנגשות בין סנכרון תצורות לבין משאבי Config Connector

יכול להיות ש-Config Sync ייראה כאילו הוא נלחם ב-Config Connector על משאב, למשל StorageBucket. הבעיה הזו מתרחשת אם לא מגדירים את הערך של שדה אופציונלי במשאב spec.lifecycleRule.condition.withState במקור האמת.

פתרון עקיף:

כדי להימנע מהבעיה הזו, צריך להוסיף את השדה withState=ANY להצהרת המשאב. אפשרות אחרת היא לוותר על המשאב ואז לרכוש אותו מחדש באמצעות ההערה cnrm.cloud.google.com/state-into-spec: absent.

מקור מידע אמין 1.13.0 1.20.1

תוקן: אי אפשר ליצור טוקן גישה למקור OCI

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

הבעיה הזו נגרמת בגלל שהספרייה oauth2 מרעננת את טוקן האימות רק אחרי שהתוקף שלו פג.

יכול להיות שהודעת השגיאה תכלול את הטקסט הבא: "oauth2/google: unable to generate access token" או "ID Token issued at (xxx) is stale to sign-in."

פתרון עקיף:

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

אם סנכרון תצורות נכשל מספר פעמים, הניסיונות החוזרים מתבצעים בתדירות נמוכה יותר. כדי לאלץ את סנכרון תצורות לנסות שוב מוקדם יותר, צריך למחוק את ה-Pod של ה-reconciler. הפעולה הזו גורמת ל-סנכרון תצורות ליצור מחדש את ה-Pod של ה-reconciler ולשלוף באופן מיידי מהמקור המהימן:

    kubectl delete pod -n config-management-system RECONCILER_NAME
מחליפים את RECONCILER_NAME בשם של האובייקט RootSync או RepoSync.
מקור מידע אמין 1.20.0 1.21.3

git-sync container crash loops after a Git lock file is orphaned

אם אתם רואים שהלולאה של קריסת מאגר התגים git-sync כוללת שגיאות שדומות לאלה שמופיעות ביומן של מאגר התגים git-sync, יכול להיות שקריאה קודמת של git נכשלה והשאירה קובץ נעילה יתום במאגר התגים:

    {"logger":""..."msg":"repo contains lock file","error":null,"path":"/repo/source/.git/shallow.lock"}
    ...runtime error: invalid memory address or nil pointer dereference

פתרון עקיף:

כדי לעקוף את הבעיה הזו, מפעילים מחדש את ה-Pod של הכלי לתיאום שהושפע מהבעיה כדי לתת לו נפח זמני חדש:

    kubectl delete pod -n config-management-system RECONCILER_NAME
מחליפים את RECONCILER_NAME בשם של האובייקט RootSync או RepoSync.
מקור מידע אמין 1.19.0 1.20.0

תוקן: קובץ נעילה של Git נשאר

אם מופיעה שגיאה דומה לזו שבהמשך מהמאגר git-sync, יכול להיות שקריאה קודמת של git נכשלה והשאירה קובץ נעילה במאגר:

    KNV2004: error in the git-sync container: ... fatal: Unable to create '/repo/source/.git/shallow.lock': File exists. ...

פתרון עקיף:

כדי לעקוף את הבעיה הזו, מפעילים מחדש את ה-Pod של הכלי לתיאום שהושפע מהבעיה כדי לתת לו נפח זמני חדש:

    kubectl delete pod -n config-management-system RECONCILER_NAME
מחליפים את RECONCILER_NAME בשם של האובייקט RootSync או RepoSync.
סנכרון 1.7.0 1.21.0

תוקן: הערת שינוי מסוג 'התעלמות' לא כובדה

באג בכלי Config Sync reconciler גורם לו להחיל שינויים מהגדרות מוצהרות גם כשההערה client.lifecycle.config.k8s.io/mutation קיימת. יכול להיות שהפעולה הזו תגרום להחלפת הסטטוס של האובייקט באשכול.

פתרון עקיף:

אפשר להפסיק לנהל את האובייקט המנוהל על ידי הוספת ההערה configmanagement.gke.io/managed: disabled. עם זאת, השבתת הניהול מונעת מ-סנכרון תצורות ליצור מחדש את האובייקט אם הוא נמחק מהאשכול. בנוסף, היא מונעת החלה של עדכונים נוספים במקור האמת.
סנכרון 1.5.0 1.20.1

תוקן: שגיאות ב-API Discovery עלולות לגרום לסימון שגוי של אובייקטים מנוהלים כ-Not Found

אם העורף של שירות API לא תקין, יכול להיות שתהיה שגיאה באיתור ה-API. אם זה קורה בזמן שה-ResourceGroup Controller מתחיל לפעול, אחרי שהוא עודכן או שנקבע לו מועד חדש, מטמון המשאבים לא יאותחל, ולכן כל האובייקטים המנוהלים ידווחו כ-Not Found בסטטוס של ResourceGroup.

הבעיה הזו מתרחשת לעיתים קרובות כשסטטוס הבריאות של metrics-server הוא לא תקין.

פתרון עקיף:

מפעילים מחדש את resource-group-controller Pod אחרי ש-metrics-server חוזר למצב תקין:

    kubectl delete pod -n resource-group-system RESOURCE_GROUP_CONTROLLER_NAME
מחליפים את RESOURCE_GROUP_CONTROLLER_NAME בשם של בקר ResourceGroup, שהוא זהה לשם של RootSync או RepoSync עבור החבילה הזו.
סנכרון 1.15.0

מספר גבוה של בקשות לא יעילות PATCH ביומני הביקורת

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

פתרון עקיף:

יומן הביקורת לא מבדיל בין בקשות של הרצה יבשה לבין בקשות רגילות, ולכן אפשר להתעלם מבקשות PATCH.
סנכרון 1.7.0 1.21.0

תוקן: הכתיבה של המלאי המעודכן לאשכול נכשלה

אם סנכרון תצורות לא מצליח לעדכן את הסטטוס של אובייקט ResourceGroup, יכול להיות שתיתקלו בשגיאה לסירוגין ביומני ה-reconciler, שדומה לשגיאה הבאה:

    KNV2009: task failed (action: "Inventory", name: "inventory-set-0"): failed to write updated inventory to cluster: Operation cannot be fulfilled on resourcegroups.kpt.dev "root-sync": the object has been modified; please apply your changes to the latest version and try again

השגיאה הזו נובעת ממרוץ תהליכים בין הכלי להשוואה בין מצבים לבין בקר ResourceGroup. יכול להיות שה-Controller של ResourceGroup יעודכן את הסטטוס של ResourceGroup לפני שה-reconciler יוכל לעדכן את המפרט של ResourceGroup, וכך תופיע השגיאה KNV2009.

פתרון עקיף:

אין פתרון עקיף לבעיה הזו. השגיאה אמורה להיפתר מעצמה.
Terraform ‫Terraform גרסה 5.41.0

אי אפשר להתקין או לשדרג את סנכרון תצורות באמצעות Terraform

ב-Terraform גרסה 5.41.0 נוסף שדה חדש למשאב google_gke_hub_feature_membership: config_sync.enabled. ערך ברירת המחדל של השדה הזה הוא false. אם השדה הזה לא מוגדר במפורש ל-true, התקנות או שדרוגים של סנכרון תצורות נכשלים כשמשתמשים ב-Terraform בגרסה 5.41.0 ואילך. יכול להיות שתוצג גם הודעת שגיאה עם הכיתוב git spec not included in configmanagement spec אם הבעיה הזו מתרחשת.

פתרון עקיף:

  • אם משתמשים במשאב google_gke_hub_feature_membership, צריך להגדיר באופן ידני את הערך config_sync.enabled ל-true.
  • אם אתם משתמשים במודול המשנה acm, מומלץ לעבור לדרך חלופית להתקנת סנכרון תצורות. אם אין לכם אפשרות לעבור לגרסה החדשה, אתם צריכים לשדרג לגרסה v33.0.0.

מסוףGoogle Cloud

שגיאות לגבי נתונים חסרים בלוח הבקרה של סנכרון תצורות ב Google Cloud מסוף

יכול להיות שיוצגו לכם שגיאות כמו 'נתונים חסרים' או 'פרטי כניסה לא חוקיים לאשכול' לגבי אשכולות של סנכרון תצורות בלוחות בקרה ב Google Cloud מסוף. הבעיה הזו יכולה להתרחש אם לא נכנסתם לאשכולות GDC‏ (VMware) או GDC‏ (bare metal).

פתרון עקיף:

אם אתם רואים שגיאות מהסוגים האלה ב Google Cloud מסוף באשכולות GDC ‏ (VMware) או GDC ‏ (bare metal), ודאו שאתם מחוברים לאשכולות באמצעות GKE Identity Service או connect gateway.

סנכרון 1.21.0

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

לפני גרסה 1.21.0, אובייקט RootSync או RepoSync שנמחק יכול להשאיר אחריו כמה תוויות והערות ש-סנכרון תצורות משתמש בהן כדי לעקוב אחרי אובייקטים של משאבים.

התוויות וההערות האלה יכולות לגרום לתופעות הלוואי הבאות אחרי שמחיקת אובייקט RootSync או RepoSync:

  • אובייקטים אחרים של RepoSync לא יכולים לקבל בעלות על אובייקטים שנוהלו בעבר.
  • אם מניעת סחיפה מופעלת, יכול להיות ש-סנכרון תצורות ידחה שינויים במשאבים נטושים.
כלי שורת הפקודה nomos 1.17.0

‫nomos CLI לא תומך בפלאגין האימות oidc

יכול להיות שיופיעו שגיאות כמו no Auth Provider found for name "oidc" כשמשתמשים בכלי nomos של שורת הפקודה. הבעיה הזו עלולה להתרחש כשמשתמשים בתוסף האימות oidc.

פתרון עקיף:

אין פתרון עקיף. תוסף האימות oidc יתווסף מחדש בגרסה עתידית.

חזרה למעלה

המאמרים הבאים

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