מניעת סחף הגדרות

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

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

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

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

כדי להשתמש במניעת סחף, צריך להפעיל את ממשקי ה-API‏ RootSync ו-RepoSync.

הערה: כל התכונות האלה משתמשות בserver-side apply, כלומר הן מונעות או מבטלות שינויים רק בשדות שצוינו במפורש במקור האמת. מותר לשדות לא מוגדרים להשתנות. הדבר נדרש כי הרבה בקרי Kubernetes מעדכנים את המטא-נתונים ואת שדות המפרט בזמן הריצה, ולא רק את שדות הסטטוס.

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

אם התקנתם בעבר את Google Cloud CLI, תוכלו להריץ את הפקודה gcloud components update כדי לקבל את הגרסה האחרונה.

הפעלת מניעת סחף

אפשר להפעיל את מניעת הסחף באמצעות ה-CLI של gcloud. אי אפשר להפעיל את התכונה למניעת סחף במסוף Google Cloud .

כדי להפעיל את האפשרות למניעת סחף:

1. מעדכנים את המניפסט של מפרט ההחלה כדי להגדיר את השדה spec.configSync.preventDrift בתור true:

   applySpecVersion: 1
   spec:
     configSync:
       enabled: true
       ... existing content ...
       preventDrift: true
   

2. החלת המניפסט המעודכן:

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=MANIFEST_NAME  \
       --project=PROJECT_ID
   

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

   • ‫MEMBERSHIP_NAME: השם של החברות ב-Fleet שבחרתם כשביצעתם רישום של האשכול. מקבלים את השם באמצעות הפקודה gcloud container fleet memberships list.
   • ‫MANIFEST_NAME: השם של מניפסט המפרט שלכם, בדרך כלל apply-spec.yaml.
   • PROJECT_ID: מזהה הפרויקט.

3. מחכים עד שאובייקט סנכרון תצורות ValidateWebhookConfiguration נוצר על ידי ConfigManagement Operator:

   kubectl get validatingwebhookconfiguration admission-webhook.configsync.gke.io
   

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

   NAME                                  WEBHOOKS   AGE
   admission-webhook.configsync.gke.io   0          2m15s
   

4. מבצעים קומיט של שינוי חדש במקור האמת כדי לסנכרן אותו, כך ש-Deployment (פריסה) root-reconciler תוכל להוסיף וווב-הוקים לאובייקט ValidatingWebhookConfiguration של סנכרון תצורות. אפשרות נוספת היא למחוק את root-reconcilier הפריסה כדי להפעיל תהליך של התאמה. הפריסה החדשה root-reconciler Deployment תעדכן את אובייקט ValidatingWebhookConfiguration של סנכרון תצורות.

5. ממתינים עד ששרת ה-webhook יהיה מוכן. יומן הפריסה של ה-webhook של סנכרון תצורות admission צריך לכלול את serving webhook server. הפעולה יכולה להימשך כמה דקות.

   kubectl logs -n config-management-system -l app=admission-webhook --tail=-1 | grep "serving webhook server"
   

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

   I1201 18:05:41.805531       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
   I1201 18:07:04.626199       1 deleg.go:130] controller-runtime/webhook "level"=0 "msg"="serving webhook server"  "host"="" "port"=10250
   

השבתת מניעת סחף

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

כדי להשבית את מניעת הסחף, מבצעים את השלבים הבאים:

1. מעדכנים את המניפסט של מפרט ההחלה כדי להגדיר את השדה spec.configSync.preventDrift בתור false:

   applySpecVersion: 1
   spec:
     configSync:
       enabled: false
       ... existing content ...
       preventDrift: false
   

2. החלת המניפסט המעודכן:

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=MANIFEST_NAME  \
       --project=PROJECT_ID
   

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

   • ‫MEMBERSHIP_NAME: השם של החברות ב-Fleet שבחרתם כשביצעתם רישום של האשכול. מקבלים את השם באמצעות הפקודה gcloud container fleet memberships list.
   • ‫MANIFEST_NAME: השם של מניפסט המפרט שלכם, בדרך כלל apply-spec.yaml.
   • PROJECT_ID: מזהה הפרויקט.

הפעלת ה-webhook של בקרת הכניסה במקורות בהיקף של מרחב שמות

מקורות אמת בהיקף של מרחב שמות לא מוגנים באופן מלא על ידי ה-webhook. לכלי Config Sync reconciler של כל מקור מרחב שמות אין הרשאה לקרוא או לעדכן את האובייקטים של ValidatingWebhookConfiguration ברמת האשכול.

היעדר ההרשאה הזו גורם לשגיאה ביומני ה-reconcilers של מרחב השמות, בדומה לדוגמה הבאה:

Failed to update admission webhook: KNV2013: applying changes to
admission webhook: Insufficient permission. To fix, make sure the reconciler has
sufficient permissions.:
validatingwebhookconfigurations.admissionregistration.k8s.io "admission-
webhook.configsync.gke.io" is forbidden: User "system:serviceaccount:config-
management-system:ns-reconciler-NAMESPACE" cannot update resource
"validatingwebhookconfigurations" in API group "admissionregistration.k8s.io" at
the cluster scope

אפשר להתעלם מהשגיאה הזו אם לא רוצים להשתמש בהגנה על ה-webhook עבור מקור האמת שלכם בהיקף מרחב השמות. עם זאת, אם רוצים להשתמש ב-webhook, צריך להעניק הרשאה למנגנון ההתאמה לכל מקור אמת בהיקף של מרחב שמות, אחרי הגדרת סנכרון מכמה מקורות אמת. יכול להיות שלא תצטרכו לבצע את השלבים האלה אם כבר קיים RoleBinding עבור ns-reconciler-NAMESPACE עם הרשאות ClusterRole cluster-admin.

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

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

   # ROOT_SOURCE/cluster-roles/webhook-role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: admission-webhook-role
   rules:
   - apiGroups: ["admissionregistration.k8s.io"]
     resources: ["validatingwebhookconfigurations"]
     resourceNames: ["admission-webhook.configsync.gke.io"]
     verbs: ["get", "update"]
   

2. לכל מקור בהיקף מרחב השמות שצריך להעניק לו הרשאה ל-webhook של בקרת הכניסה, צריך להצהיר על הגדרת ClusterRoleBinding כדי להעניק גישה ל-webhook של בקרת הכניסה:

   # ROOT_SOURCE/NAMESPACE/sync-webhook-rolebinding.yaml
   kind: ClusterRoleBinding
   apiVersion: rbac.authorization.k8s.io/v1
   metadata:
     name: syncs-webhook
   subjects:
   - kind: ServiceAccount
     name: ns-reconciler-NAMESPACE
     namespace: config-management-system
   roleRef:
     kind: ClusterRole
     name: admission-webhook-role
     apiGroup: rbac.authorization.k8s.io
   

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

3. מבצעים Commit של השינויים למקור האמת הבסיסי. לדוגמה, אם מסנכרנים ממאגר Git:

   git add .
   git commit -m 'Providing namespace repository the permission to update the admission webhook.'
   git push
   
   

4. כדי לוודא, משתמשים ב-kubectl get כדי לוודא ש-ClusterRole ו-ClusterRoleBinding נוצרו:

   kubectl get clusterrole admission-webhook-role
   kubectl get clusterrolebindings syncs-webhook
   

השבתת מניעת סחף למשאבים שהוצאו משימוש

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

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

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

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

אם רוצים למחוק את המשאבים המנוהלים האלה, יש שתי אפשרויות:

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

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

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

• איך פותרים בעיות ב-webhook