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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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