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

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

אובייקט באשכול מנוהל על ידי סנכרון תצורות אם יש לו את האנוטציה 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 key מלבד 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. מחכים כמה רגעים עד שסנכרון תצורות יזהה את השמירה החדשה ויחיל אותה.

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:

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

אם רוצים למנוע מ-Config Sync למחוק את האובייקט כשההגדרה שלו מוסרת ממאגר 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".