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

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

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

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

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

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

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

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. משתמשים בכלי להשוואת קבצים כדי להשוות את הפלט.

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

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

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

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

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

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

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

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

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

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

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

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