פתרון בעיות שקשורות למאבקים על השליטה

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

הכלי Config Sync עוקב אחרי האובייקטים שהוא מחיל על האשכול ומבטל שינויים שבוצעו בערכים שהוצהרו במקור האמת. אם השינויים האלה יבוצעו על ידי נאמן מידע אחר, יכול להיות שהמשאב יעבור הלוך ושוב בין המצבים הרצויים לנאמני המידע המתחרים. אחד מהסימפטומים של ההתנהגות הזו הוא שהערכים בשדות metadata.generation ו-metadata.resourceVersion גדלים במהירות. לכן, אם אובייקט מנוהל מתעדכן יותר מחמש פעמים בדקה, Config Sync מזהה את הקונפליקט, מתעד את השינוי ומדווח על השגיאה בסטטוס האובייקט RootSync או RepoSync.

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

זיהוי של קרבות בין בקרים

אפשר לבדוק את השגיאות של הקרב באמצעות הפקודה nomos status או על ידי בדיקת שדה הסטטוס באובייקט RootSync או RepoSync.

אם לא התקנתם את כלי שורת הפקודה nomos, תוכלו לעיין ביומנים של RootSync reconciler על ידי הרצת הפקודה הבאה:

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-name=root-sync" \
    --container reconciler

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

kubectl logs -n config-management-system \
    --selector "app=reconciler,configsync.gke.io/sync-namespace=NAMESPACE" \
    --container reconciler

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

אם מופיע KNV2005 בתוצאות, סימן שיש מאבק שליטה.

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

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

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

כדי לקבל מידע נוסף על כל מאבק של בקר, מריצים את הפקודה הבאה כדי לצפות בעדכונים של קובץ ה-YAML של המשאב:

 kubectl get RESOURCE OBJECT_NAME \
     --namespace NAMESPACE \
     --watch -o yaml

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

  • ‫RESOURCE: סוג המשאב שעליו מתנהל המאבק.
  • ‫OBJECT_NAME: השם של האובייקט שעליו מתנהל המאבק.
  • ‫NAMESPACE: מרחב השמות שבו נמצא המשאב שעליו מתנהל המאבק.

בתוצאות היומן מצוינים המשאב, שם האובייקט ומרחב השמות שצריך להוסיף.

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

פתרון בעיות שקשורות לבקרים

יש כמה דרכים לפתור את הבעיה של התנגשות בין בקרים. בוחרים את האפשרות שהכי מתאימה להגדרת Config Sync:

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

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

לחלופין, אם לא רוצים ש-Config Sync יחזיר שינויים לאובייקטים מנוהלים באשכול, אפשר להוסיף את ההערה client.lifecycle.config.k8s.io/mutation: ignore לאובייקט שרוצים ש-Config Sync יתעלם ממוטציות בו. הסבר איך לעשות זאת אפשר למצוא במאמר בנושא התעלמות משינויים באובייקטים.

פתרון בעיות שקשורות להתנגשויות בין בקרים במרחבי שמות משתמעים

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

יש כמה דרכים לפתור את הבעיות שנוצרות בגלל מרחב שמות משתמע. בוחרים את האפשרות שהכי מתאימה להגדרה של Config Sync:

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

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

  • אם הבעיות נמשכות, כדאי לבדוק אם הבעיה שנתקלתם בה היא בעיה מוכרת.

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