יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

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

שימוש בתיקון עצמי מובנה ב-סנכרון תצורות (מומלץ, לא נדרשת הגדרה): סנכרון תצורות מזהה באופן אוטומטי סטיות ומבטל אותן. אי אפשר להשבית את התיקון העצמי של Config Sync. התיקון העצמי משפיע על הביצועים באופן מינימלי.
הפעלת התכונה למניעת סחף (בדף הזה): התכונה למניעת סחף משתמשת ב-webhook של הרשאה כדי לחסום שינויים שמתנגשים זה בזה. התכונה הזו עלולה לגרום לשימוש גבוה בזיכרון ולשגיאות של חוסר זיכרון (OOM), במיוחד באשכולות עם הרבה CustomResourceDefinitions (CRDs).

למה לא מומלץ למנוע סחף

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

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

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

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

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

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

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

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

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

החלת המניפסט המעודכן:
```
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: מזהה הפרויקט.

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

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

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

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

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

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

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

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

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

החלת המניפסט המעודכן:
```
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 ברמת האשכול.

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

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.

במקור האמת הבסיסי, מגדירים הגדרה חדשה של 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"]

לכל מקור עם היקף מרחב שמות שצריך להעניק לו הרשאה של 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 במרחב השמות שבו יצרתם את המקור בהיקף מרחב השמות.

מבצעים Commit של השינויים למקור האמת הבסיסי. לדוגמה, אם מסנכרנים ממאגר Git:
```
git add .
git commit -m 'Providing namespace repository the permission to update the admission webhook.'
git push
```
כדי לוודא, משתמשים ב-kubectl get כדי לוודא ש-ClusterRole ו-ClusterRoleBinding נוצרו:
```
kubectl get clusterrole admission-webhook-role
kubectl get clusterrolebindings syncs-webhook
```

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

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