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

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

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

למה לא מומלץ להשתמש במניעת חריגה

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

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

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

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

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

הפעלת מניעת חריגה

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

כדי להפעיל את מניעת החריגה, מבצעים את השלבים הבאים:

1. מעדכנים את מניפסט המפרט של apply כדי להגדיר את השדה 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. מבצעים שינוי חדש במקור המידע האמין שצריך לסנכרן, כדי שהפריסה של root-reconciler תוכל להוסיף תגובות לפעולה מאתר אחר (webhooks) לאובייקט ValidatingWebhookConfiguration של סנכרון תצורות. אפשרות אחרת היא למחוק את ה-Deployment של root-reconcilier כדי להפעיל התאמה. הפריסה החדשה של root-reconciler תעדכן את האובייקט ValidatingWebhookConfiguration של סנכרון ההגדרות.

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

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

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

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

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 לאימות של סנכרון ההגדרות באשכול.

1. במקור האמת ברמה הבסיסית (root), מגדירים 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. מבצעים את השינויים במקור האמת הבסיסי. לדוגמה, אם מסנכרנים ממאגר 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
   

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

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