ניהול אובייקטים קיימים באשכול

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

אובייקט באשכול מנוהל על ידי סנכרון תצורות אם יש לו את ההערה configmanagement.gke.io/managed: enabled וההערה configsync.gke.io/resource-id, שכוללת את פרטי הקבוצה, הסוג, מרחב השמות והשם של האובייקט, נכונה.

הפורמט של ההערה configsync.gke.io/resource-id הוא GROUP_KIND_NAMESPACE_NAME לאובייקט בהיקף של מרחב שמות, ו-GROUP_KIND_NAME לאובייקט בהיקף של אשכול.

בתרשים הזרימה הבא מתוארות כמה סיטואציות שגורמות לאובייקט להיות מנוהל או לא מנוהל:

התרשים מכיל שלושה תהליכים נפרדים: 1) התחלת ניהול של אובייקט, 2) הפסקת הניהול של אובייקט ו-3) מחיקה של אובייקט מנוהל.

1. אני רוצה להתחיל לנהל אובייקט. האם לאובייקט יש מניפסט? במילים אחרות, האם לאובייקט יש הגדרה במאגר?
   • לא: צריך ליצור הגדרה לאובייקט. ‫סנכרון תצורות מגדיר את ההערה configmanagement.gke.io/managed: enabled, מגדיר את ההערה configsync.gke.io/resource-id כך שתתאים לאובייקט ומתחיל לנהל את האובייקט.
   • כן: האם ההגדרה קובעת את ההערה הבאה? configmanagement.gke.io/managed: disabled
     • לא: האובייקט מנוהל כברירת מחדל.
     • כן: עורכים את ההגדרה כדי להסיר את ההערה configmanagement.gke.io/managed: disabled. כשדוחפים את השינוי למאגר המקור, סנכרון תצורות מזהה את השינוי, מחיל את ההערה configmanagement.gke.io/managed: enabled ואת ההערה configsync.gke.io/resource-id, ומחיל את ההגדרה.
2. אני רוצה להפסיק לנהל אובייקט אבל לא למחוק אותו.
   • עורכים את ההגדרה של האובייקט במאגר ומגדירים את ההערה configmanagement.gke.io/managed: disabled. כשמזוהה שינוי בהגדרה, סנכרון תצורות מפסיק לנהל את האובייקט.
3. אני רוצה להפסיק לנהל אובייקט ולמחוק אותו.
   • מוחקים את ההגדרה של האובייקט מהמאגר. כשמוחקים הגדרה של אובייקט שנוהל בעבר, סנכרון תצורות מוחק את האובייקט מכל האשכולות או מרחבי השמות שההגדרה חלה עליהם.

בנוסף להערה configmanagement.gke.io/managed: enabled ולהערה configsync.gke.io/resource-id, התווית app.kubernetes.io/managed-by: configmanagement.gke.io מוחלת על כל האובייקטים שמנוהלים על ידי סנכרון ההגדרות. התווית הזו מאפשרת לכם ליצור בקלות רשימה של כל האובייקטים לפי סנכרון תצורות.

למה לא להוסיף את ההערה באופן ידני?

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

לפני שמתחילים

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

הצגת רשימה של כל האובייקטים המנוהלים

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

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

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

kubectl get object-type -n namespace -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

לדוגמה, הפקודה הזו מציגה רשימה של RoleBindings במרחב השמות gamestore שמנוהלים על ידי סנכרון תצורות:

kubectl get rolebindings -n gamestore \
    -l "app.kubernetes.io/managed-by=configmanagement.gke.io"

הפלט אמור להיראות כך:

NAME                              ROLE                                          AGE
configsync.gke.io:ns-reconciler   ClusterRole/configsync.gke.io:ns-reconciler   34h
gamestore-admin                   ClusterRole/admin                             34h
gamestore-webstore-admin          ClusterRole/webstore-admin                    34h

הפקודה הזו מציגה רשימה של RoleBindings במרחב השמות kube-system שלא מנוהלים על ידי סנכרון תצורות:

kubectl get rolebindings -n kube-system \
    -l "app.kubernetes.io/managed-by!=configmanagement.gke.io"

הפלט אמור להיראות כך:

NAME                                             AGE
fluentd-gcp-scaler-binding                       2d21h
gce:cloud-provider                               2d21h
heapster-binding                                 2d21h
metrics-server-auth-reader                       2d21h
system::leader-locking-kube-controller-manager   2d21h
system::leader-locking-kube-scheduler            2d21h
system:controller:bootstrap-signer               2d21h
system:controller:cloud-provider                 2d21h
system:controller:token-cleaner                  2d21h

התחלת ניהול של אובייקט קיים

אפשר ליצור קובץ הגדרה לאובייקט קיים של Kubernetes, כמו מרחב שמות שכבר קיים באשכול לפני שמתקינים את סנכרון תצורות. עם זאת, המערכת מתעלמת מההגדרה הזו אלא אם האובייקט מכיל את ההערה configmanagement.gke.io/managed: enabled ואת ההערה הנכונה configsync.gke.io/resource-id. כדי להוסיף הערה לאובייקט קיים, צריך להוסיף אותה באופן ידני.

במרחבי שמות ספציפיים, סנכרון תצורות כן מחיל הגדרות שיוצרות אובייקטים חדשים במרחב שמות ללא הערות, ומחיל את ההערות configmanagement.gke.io/managed: enabled ו-configsync.gke.io/resource-id על האובייקטים האלה. עם זאת, סנכרון תצורות לא ישנה או יסיר אובייקט לא מוער עם היקף אשכול מאשכול. האיור הזה מופיע בתרשים שבמאמר עבודה עם הגדרות לאורך זמן.

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

1. יוצרים את התפקיד myrole במרחב השמות gamestore:

   kubectl create role -n gamestore myrole --verb=get --resource=pods

2. כדי לראות את ההרשאות שניתנו לתפקיד myrole:

   kubectl describe role -n gamestore myrole

   Name:         myrole
   Labels:       <none>
   Annotations:  <none>
   PolicyRule:
     Resources  Non-Resource URLs  Resource Names  Verbs
     ---------  -----------------  --------------  -----
     pods       []                 []              [get]
   

   לתפקיד יש הרשאה רק ל-get Pods.

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

   1. במסוף, עוברים לשיבוט המקומי של המאגר.

   2. כדי ליצור קובץ מניפסט YAML בשם myrole ולשמור אותו בקובץ חדש בשם gamestore-myrole.yaml, משתמשים בפקודה הבאה:

      kubectl get role myrole -n gamestore -o yaml > gamestore-myrole.yaml
      

   3. עורכים את קובץ gamestore-myrole.yaml.

      1. מסירים את כל השדות מתחת למפתח metadata, מלבד name ו-namespace.
      2. מוסיפים את הפועל list אחרי get בשדה הרשימה rules.verbs.

      שומרים את השינויים. הקובץ שמתקבל מכיל את התוכן הבא:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: myrole
        namespace: gamestore
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - get
        - list
      

   4. מבצעים Commit של השינוי למאגר.

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

      kubectl describe role myrole -n gamestore
      

שימו לב להערה configmanagement.gke.io/managed: enabled, שמציינת שהאובייקט מנוהל על ידי סנכרון תצורות, ולהערה configsync.gke.io/resource-id, שעוקבת אחרי המידע על הקבוצה, סיווג, מרחב השמות והשם. שימו לב גם להערות שמציגות את הנתיב ואת שם הקובץ במאגר שגרם לשינוי התצורה האחרון באובייקט, ואת הגיבוב של Git שמייצג את השמירה.

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

הפסקת הניהול של אובייקט מנוהל

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

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

1. עורכים את קובץ config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml בשיבוט המקומי של המאגר ומוסיפים קטע annotations: שתואם לטקסט המודגש שלמטה:

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      annotations:
        configmanagement.gke.io/managed: disabled
      name: gamestore-webstore-admin
      namespace: gamestore
    subjects:
    - kind: ServiceAccount
      name: ns-reconciler-gamestore
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: webstore-admin
      apiGroup: rbac.authorization.k8s.io
   

   שומרים את הקובץ.

2. יוצרים commit ב-Git עם השינויים שביצעתם, ודוחפים את ה-commit אל ה-repo.

3. מחכים כמה רגעים עד ש-Config Sync יזהה את הקומיט החדש ויחיל אותו.

4. משתמשים בפקודה הבאה כדי לוודא שההערות והתוויות של gamestore-webstore-admin RoleBinding ריקות. ‫סנכרון תצורות לא מגדיר את ההערה configmanagement.gke.io/managed ל-disabled באובייקט.

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml
   

   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     annotations:
     name: gamestore-webstore-admin
     namespace: gamestore
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-gamestore
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: webstore-admin
     apiGroup: rbac.authorization.k8s.io
   

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

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

המשך ניהול של אובייקט שלא נוהל בעבר

בדוגמה הזו אפשר לראות איך לחדש את הניהול של אובייקט שהוסר בעבר מהניהול, כמו בדוגמה הפסקת הניהול של אובייקט קיים. ההנחה היא שלא הסרתם את ההגדרה של gamestore-webstore-admin RoleBinding.

1. אם מחקתם את gamestore-webstore-admin RoleBinding מהמאגר שלכם בהתחייבות האחרונה, מבצעים את השלבים הבאים.

   1. כדי לבטל את השינויים האחרונים שבוצעו באמצעות commit, משתמשים בפקודה git revert:

      git revert HEAD~1
      

      תתבקשו לאשר את פעולת החזרה.

   2. שולחים את פעולת הביטול למאגר.

      git push
      

2. עורכים את הקובץ config-sync-quickstart/multirepo/root/rolebinding-gamestore-webstore-admin.yaml בעותק המקומי של המאגר ומסירים את ההערה configmanagement.gke.io/managed: disabled. שומרים את הקובץ.

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

   • הודעות על שינויים
   • ההערות configmanagement.gke.io/managed: enabled ו-configsync.gke.io/resource-id מוחלות, והאובייקט מנוהל.
   • ההגדרה תחול, כמו בכל אובייקט מנוהל.

4. כדי לוודא שהאובייקט מנוהל עכשיו, מציגים את ההערות שלו:

   kubectl get rolebinding gamestore-webstore-admin -n gamestore -o yaml

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     annotations:
       configmanagement.gke.io/cluster-name: my-cluster
       configmanagement.gke.io/managed: enabled
       configsync.gke.io/resource-id: rbac.authorization.k8s.io_rolebinding_gamestore_gamestore-webstore-admin
   ...
   

הפסקת הניהול של מרחב שמות

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

1. מוסיפים את ההערה configmanagement.gke.io/managed:disabled להגדרות של מרחב השמות ולכל ההגדרות באותו מרחב שמות. כל האובייקטים במרחב השמות צריכים לכלול את ההערה הזו.

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

2. שומרים ודוחפים את השינויים למאגר. מחכים שה-Operator יסתנכרן עם המאגר.

3. מוחקים את המשאבים הלא מנוהלים מהמאגר.

   אזהרה: בעיה ידועה היא שאם אתם לא משתמשים ב-RootSync וב-RepoSync APIs, מחיקת מרחב השמות הלא מנוהל מהמאגר גורמת למחיקת מרחב השמות מהאשכול הפעיל. אם נמחקו בטעות משאבים לא מנוהלים, צריך להוסיף אותם בחזרה לאשכול באופן ידני, למשל באמצעות kubectl apply. כדי להשתמש בממשקי RootSync ו-RepoSync API, צריך להעביר את אובייקט ConfigManagement.

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

מחיקת משאבים מנוהלים

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

מחיקת אובייקטים בודדים

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

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

• שימוש ב-nomos status.
• שימוש ב-kubectl לבדיקת משאבים
• שימוש במרכז הבקרה של סנכרון תצורות

מחיקת כמות גדולה של אובייקטים

גרסת טרום-השקה

השימוש במוצר הזה או בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

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

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

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

אפשרויות להפצת המחיקה

הפצת המחיקה מושבתת כברירת מחדל. כדי להפעיל את העברת המחיקה, מוסיפים את ההערה configsync.gke.io/deletion-propagation-policy: Foreground לאובייקט RootSync או RepoSync, כמו בדוגמה הבאה:

# example-rootsync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: example-rootsync
  namespace: config-management-system
  annotations:
    configsync.gke.io/deletion-propagation-policy: Foreground
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
    branch: main
    dir: config-sync-quickstart/multirepo/root
    auth: none
    period: 30s

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

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

מחליפים את ROOTSYNC_NAME בשם של RootSync שרוצים לעדכן.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'

מחליפים את REPOSYNC_NAME בשם של RepoSync שרוצים לעדכן.

כדי להשבית את העברת המחיקה, מסירים את ההערה או משנים את הערך ל-configsync.gke.io/deletion-propagation-policy: Orphan:

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

RootSync

kubectl patch RootSync ROOTSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

מחליפים את ROOTSYNC_NAME בשם של RootSync שרוצים לעדכן.

RepoSync

kubectl patch RepoSync REPOSYNC_NAME \
  --namespace config-management-system \
  --type merge \
  --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Orphan"}}}'

הפצת מחיקת אובייקט

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

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

RootSync

1. כדי להפעיל את העברת המחיקה, מחילים את ההערה על אובייקט RootSync:

   kubectl patch RootSync example-rootsync \
     --namespace config-management-system \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. מוחקים את אובייקט RootSync ומחכים ש'סנכרון תצורות' ימחק אותו:

   kubectl delete RootSync example-rootsync --namespace config-management-system --wait
   

   יכול להיות שיעברו כמה דקות עד שהמחיקה של RootSync תושלם.

RepoSync

1. כדי להפעיל את העברת המחיקה, מחילים את ההערה על אובייקט RepoSync:

   kubectl patch RepoSync example-reposync \
     --namespace example-namespace \
     --type merge \
     --patch '{"metadata":{"annotations":{"configsync.gke.io/deletion-propagation-policy":"Foreground"}}}'
   

2. מוחקים את אובייקט RepoSync ומחכים שסנכרון תצורות ימחק אותו:

   kubectl delete RepoSync example-reposync --namespace example-namespace --wait
   

   יכול להיות שיעברו כמה דקות עד שהמחיקה של RepoSync תושלם.

מניעת מחיקה של אובייקטים ב-Kubernetes

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

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

1. מוסיפים את ההערה client.lifecycle.config.k8s.io/deletion: detach להגדרת האובייקט במאגר Git.

2. שומרים ודוחפים את השינוי במאגר Git.

3. מחכים שהשינוי יסונכרן עם האשכול.

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

התעלמות מאובייקט במקור האמת

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

כדי שסנכרון תצורות יתעלם מאובייקטים מסוימים, מוסיפים את ההערה config.kubernetes.io/local-config: "true" לאובייקט. אחרי שמוסיפים את ההערה הזו, סנכרון תצורות מתעלם מהאובייקט הזה כאילו הוא הוסר ממקור האמת. משאבים עם הערה local-config שמוגדרת לערך כלשהו שאינו "false" נחשבים כאילו הערך שלה הוא "true", והמערכת מתעלמת מהם.