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

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

הגדרת סנכרון מכמה מקורות מידע אמינים

בדף הזה מוסבר איך להגדיר יותר משורש אחד ומקור אמת בהיקף של מרחב שמות על ידי יצירת אובייקטים של RootSync ו-RepoSync.

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

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

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

יוצרים מקור לא מובנה של נתוני אמת, או מוודאים שיש לכם גישה למקור כזה, שיכול להכיל את ההגדרות ש-סנכרון תצורות מסנכרן אליו. ‫סנכרון תצורות תומך במאגרי Git, בתרשימי Helm ובתמונות OCI כמקור האמת. מקורות אמת בהיקף מרחב שמות חייבים להיות בפורמט לא מובנה.
יוצרים אשכול או מוודאים שיש לכם גישה לאשכול שנמצא בפלטפורמה ובגרסה שנתמכות ב-Google Kubernetes Engine ועומד בדרישות של סנכרון תצורות.

יצירת RoleBinding

נדרש RoleBinding כדי להעניק הרשאות ל-RepoSync שיוצרים במדריך הזה. כדי ליצור את RoleBinding:

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

RoleBinding יכול להפנות אל Role באותו מרחב שמות. לחלופין, RoleBinding יכול להפנות אל ClusterRole ולקשור את ClusterRole למרחב השמות של RoleBinding. מומלץ להקפיד על העקרון של הרשאות מינימליות ולהעניק הרשאות מפורטות ל-Role שהוגדר על ידי המשתמש. עם זאת, אפשר להגדיר ClusterRole או להשתמש בתפקידים גלויים למשתמשים, ולהפנות לאותו ClusterRole בכמה RoleBindings במרחבי שמות שונים.

הערה: RoleBinding עם הפניה ל-ClusterRole מאפשר גישה רק למרחב השמות של RoleBinding, ולא גישה ברמת האשכול.
Default ClusterRoles
שומרים את קובץ RoleBinding המניפסט שמפנה אל ClusterRole ברירת המחדל, למשל admin או edit, בתור FILENAME:
```
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: CLUSTERROLE_NAME
  apiGroup: rbac.authorization.k8s.io
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫FILENAME: השם של מניפסט RoleBinding.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫SERVICE_ACCOUNT_NAME: מוסיפים את השם של חשבון השירות של הכלי להשוואה. אם השם של RepoSync הוא repo-sync, SERVICE_ACCOUNT_NAME הוא ns-reconciler-NAMESPACE. אחרת, הערך הוא ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. לדוגמה, אם שם ה-RepoSync הוא prod, אז SERVICE_ACCOUNT_NAME יהיה ns-reconciler-NAMESPACE-prod-4. המספר השלם 4 משמש כ-prod כי הוא מכיל 4 תווים.
- ‫CLUSTERROLE_NAME: מוסיפים את השם של ClusterRole שמוגדר כברירת מחדל.
תפקידים שהוגדרו על ידי משתמש
אפשר להגדיר ClusterRole או Role על ידי הענקת רשימה של הרשאות לכל משאב שמנוהל על ידי אובייקט RepoSync. כך אפשר להגדיר הרשאות פרטניות. פרטים נוספים זמינים במאמר בנושא הפניה למשאבים.

לדוגמה, ההרשאות ClusterRole או Role הבאות מעניקות הרשאות לניהול אובייקטים Deployment ו-ServiceAccount:
```
# ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ROLE_KIND
metadata:
  namespace: NAMESPACE # only set this field for a 'Role'
  name: RECONCILER_ROLE
rules:
# Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["*"]
```
שומרים את RoleBinding קובץ המניפסט שמפנה אל ClusterRole או אל Role כמו FILENAME:
```
# ROOT_REPO/namespaces/NAMESPACE/FILENAME.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ROLE_KIND
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫FILENAME: השם של מניפסט RoleBinding.
- ROLE_KIND: הגדרת ClusterRole או Role.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫SERVICE_ACCOUNT_NAME: מוסיפים את השם של חשבון השירות של הכלי להשוואה. אם השם של RepoSync הוא repo-sync, SERVICE_ACCOUNT_NAME הוא ns-reconciler-NAMESPACE. אחרת, הערך הוא ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. לדוגמה, אם שם ה-RepoSync הוא prod, אז SERVICE_ACCOUNT_NAME יהיה ns-reconciler-NAMESPACE-prod-4. המספר השלם 4 משמש כ-prod כי הוא מכיל 4 תווים.
- ‫RECONCILER_ROLE: מוסיפים את השם של ClusterRole או Role.
החלת ה-RoleBinding:
```
kubectl apply -f FILENAME
```

מגבלות

‫NamespaceSelectors (כולל הערות שמפנות לרכיבי Selector) פועלות רק במקור אמת בסיסי.
אם התקנתם את סנכרון תצורות באמצעות מסוף Cloud de Confiance או Google Cloud CLI, מערכת סנכרון תצורות יצרה אוטומטית אובייקט RootSync בשם root-sync. לכן, אי אפשר לתת לאובייקטים של RootSync את השם root-sync.

בחירת שיטת ההגדרה המועדפת

בוחרים אחת משתי השיטות להגדרת המקורות:

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

שליטה במקורות במקור מידע אמין ברמת הבסיס

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

שליטה במקורות הבסיסיים במקור בסיסי של מידע אמין

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

כדי להשתמש בשיטה הזו, צריך לבצע את הפעולות הבאות:

שומרים אחד מהקובצי המניפסט הבאים בשם root-sync.yaml. משתמשים בגרסת המניפסט שמתאימה לסוג המקור של ההגדרות.
Git
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ROOT_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git לשימוש כמאגר הבסיסי. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫ROOT_REVISION: מוסיפים את הגרסה של Git (תג או גיבוב) או את ההסתעפות שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
- ‫ROOT_BRANCH: מוסיפים את ההסתעפות של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. מומלץ להשתמש בשדה revision כדי לציין שם של ענף, כדי לפשט את התהליך. אם מציינים גם את השדה revision וגם את השדה branch, השדה revision מקבל עדיפות על פני השדה branch.
- ROOT_DIRECTORY: מוסיפים את הנתיב במאגר Git לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫ssh: שימוש בזוג מפתחות SSH
  - cookiefile: שימוש ב-cookiefile
  - ‫token: שימוש בטוקן
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת ל-Cloud Source Repositories.
  - ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת אל Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
  מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישת קריאה בלבד ל-Git ב-סנכרון תצורות.
  
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, צריך להוסיף את המפתח הציבורי של הסוד לספק Git. השדה הזה הוא אופציונלי.
- ‫ROOT_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Git כמקור.
OCI
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ‫ROOT_IMAGE: כתובת ה-URL של תמונת OCI שבה רוצים להשתמש כמאגר הבסיס, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נמשכת מהתג latest, אבל אפשר למשוך תמונות באמצעות התגים TAG או DIGEST. מציינים TAG או DIGEST במאפיין PACKAGE_NAME:
  - כדי למשוך לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - כדי למשוך לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
זהירות: סנכרון תצורות דורש ששכבת ה-OCI תידחס בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר מ-REPO תקין לתמונת OCI עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.
- ‫ROOT_DIRECTORY: מוסיפים את הנתיב במאגר לספריית הרמה הבסיסית (root) שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש בתמונה של OCI כמקור.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: unstructured
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ‫ROOT_HELM_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫HELM_CHART_NAME: מוסיפים את השם של תרשים Helm. חובה למלא את השדה הזה.
- ‫HELM_CHART_VERSION: הגרסה של התרשים. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש בגרסה האחרונה.
- ‫HELM_RELEASE_NAME: השם של מהדורת Helm. השדה הזה הוא אופציונלי.
- ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. היא מגדירה מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש במרחב השמות שמוגדר כברירת מחדל config-management-system.
- ‫HELM_INCLUDE_CRDS: צריך להגדיר את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא תציינו ערך, ברירת המחדל היא false ולא ייווצר CRD.
- ‫VALUE: ערכים לשימוש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. הפורמט של השדה הזה צריך להיות זהה לפורמט של קובץ values.yaml של תרשים helm. השדה הזה הוא אופציונלי.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫token: משתמשים בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Helm שלכם חייב להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Helm כמקור.

מבצעים Commit של השינויים למקור האמת הבסיסי:

 git add .
 git commit -m 'Setting up a new root source of truth.'
 git push

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

שליטה באובייקטים בהיקף מרחב השמות במקור האמת הבסיסי

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

כדי להשתמש בשיטה הזו, צריך לבצע את הפעולות הבאות:

במקור האמת הראשי, מגדירים את ההגדרה namespace:
```
# ROOT_SOURCE/namespaces/NAMESPACE/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: NAMESPACE
```
מחליפים את NAMESPACE בשם של מרחב השמות.
במקור האמת הבסיסי, יוצרים אחד מהאובייקטים הבאים RepoSync באותו מרחב שמות. משתמשים במניפסט שמתאים לסוג המקור של ההגדרות:
Git
```
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git לשימוש כמאגר מרחב שמות. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, ‫https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. אם לא מזינים פרוטוקול, המערכת מתייחסת לכתובת ה-URL כאל כתובת URL מסוג HTTPS. חובה למלא את השדה הזה.
- ‫NAMESPACE_REVISION: מוסיפים את הגרסה של Git (תג או גיבוב) או את ההסתעפות שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
- ‫NAMESPACE_BRANCH: מוסיפים את ההסתעפות של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. מומלץ להשתמש בשדה revision כדי לציין שם של ענף, כדי לפשט את התהליך. אם מציינים גם את השדה revision וגם את השדה branch, השדה revision מקבל עדיפות על פני השדה branch.
- ‫NAMESPACE_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫ssh: שימוש בזוג מפתחות SSH
  - cookiefile: שימוש ב-cookiefile
  - ‫token: שימוש בטוקן
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories.
  - ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
    
    מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישת קריאה בלבד ל-Git ב-סנכרון תצורות.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כNAMESPACE_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_SECRET_NAME: מוסיפים את השם שרוצים לתת ל-Secret. השדה הזה הוא אופציונלי.
- ‫NAMESPACE_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RepoSync.
OCI
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_IMAGE: כתובת ה-URL של תמונת OCI לשימוש כמקור של מרחב השמות, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נמשכת מהתג latest, אבל אפשר למשוך תמונות באמצעות התגים TAG או DIGEST. מציינים את TAG או DIGEST בPACKAGE_NAME:
  - כדי למשוך לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - כדי למשוך לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  זהירות: סנכרון תצורות דורש ששכבת ה-OCI תידחס בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר מ-REPO תקין לתמונת OCI עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.
- ‫NAMESPACE_DIRECTORY: מוסיפים את הנתיב במקור לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן אליה. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המקור.
- ‫NAMESPACE_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.
Helm
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫HELM_CHART_NAME: מוסיפים את השם של תרשים Helm. חובה למלא את השדה הזה.
- ‫HELM_CHART_VERSION: הגרסה של התרשים. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש בגרסה האחרונה.
- ‫HELM_RELEASE_NAME: השם של מהדורת Helm. השדה הזה הוא אופציונלי.
- ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. היא מגדירה מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש במרחב השמות שמוגדר כברירת מחדל config-management-system.
- ‫HELM_INCLUDE_CRDS: צריך להגדיר את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא תציינו ערך, ברירת המחדל היא false ולא ייווצר CRD.
- ‫VALUE: ערכים לשימוש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. הפורמט של השדה הזה צריך להיות זהה לפורמט של קובץ values.yaml של תרשים helm. השדה הזה הוא אופציונלי.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫token: משתמשים בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_SECRET_NAME: מוסיפים את השם של הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Helm שלכם חייב להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.
אם אתם משתמשים ב-gcpserviceaccount כסוג האימות ולא הפעלתם את התכונה 'איחוד זהויות של עומסי עבודה' ב-GKE, אתם צריכים ליצור קשר בין מדיניות IAM בין חשבון השירות של Kubernetes לבין חשבון השירות של Google עבור כל מרחב שמות. הוראות ליצירת הקישור הזה מופיעות במאמר בנושא הענקת גישה ל-Git.

מבצעים Commit של השינויים למקור האמת הבסיסי:

 git add .
 git commit -m 'Setting up a new namespace-scoped source of truth.'
 git push

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

הסוד צריך לעמוד בדרישות הבאות:
- יוצרים את הסוד באותו מרחב שמות כמו RepoSync.
- השם של הסוד חייב להיות זהה לשם spec.git.secretRef שהגדרתם ב-repo-sync.yaml.
- צריך להוסיף את המפתח הציבורי של הסוד לספק Git.
כדי לאמת את ההגדרה, משתמשים ב-kubectl get באחד מהאובייקטים במקור של מרחב השמות. לדוגמה:
```
kubectl get rolebindings -n NAMESPACE
```
אם אתם צריכים להגדיר יותר ממקור אחד בהיקף של מרחב שמות, אתם יכולים לחזור על השלבים שלמעלה.

שליטה במקורות בהיקף מרחב שמות במקור בהיקף מרחב שמות

‫סנכרון תצורות תומך בסנכרון מיותר ממקור אמת אחד בהיקף של מרחב שמות לכל מרחב שמות. אפשר לנהל מקורות אמת שמוגבלים למרחב שמות במקור אמת שמוגבל למרחב שמות באותו מרחב שמות.

כדי להשתמש בשיטה הזו, צריך לבצע את הפעולות הבאות:

במקור האמת שמוגבל למרחב השמות, יוצרים אחד מהאובייקטים הבאים באותו מרחב שמות.RepoSync משתמשים במניפסט שמתאים לסוג המקור של ההגדרות:
Git
```
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git לשימוש כמאגר מרחב שמות. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, ‫https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. אם לא מזינים פרוטוקול, המערכת מתייחסת לכתובת ה-URL כאל כתובת URL מסוג HTTPS. חובה למלא את השדה הזה.
- ‫NAMESPACE_REVISION: מוסיפים את הגרסה של Git (תג או גיבוב) או את ההסתעפות שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
- ‫NAMESPACE_BRANCH: מוסיפים את ההסתעפות של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. מומלץ להשתמש בשדה revision כדי לציין שם של ענף, כדי לפשט את התהליך. אם מציינים גם את השדה revision וגם את השדה branch, השדה revision מקבל עדיפות על פני השדה branch.
- ‫NAMESPACE_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫ssh: שימוש בזוג מפתחות SSH
  - cookiefile: שימוש ב-cookiefile
  - ‫token: שימוש בטוקן
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories.
  - ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
    
    מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישת קריאה בלבד ל-Git ב-סנכרון תצורות.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כNAMESPACE_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_SECRET_NAME: מוסיפים את השם שרוצים לתת ל-Secret. השדה הזה הוא אופציונלי.
- ‫NAMESPACE_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RepoSync.
OCI
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_IMAGE: כתובת ה-URL של תמונת OCI לשימוש כמקור של מרחב השמות, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נמשכת מהתג latest, אבל אפשר למשוך תמונות באמצעות התגים TAG או DIGEST. מציינים את TAG או DIGEST בPACKAGE_NAME:
  - כדי למשוך לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - כדי למשוך לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  זהירות: סנכרון תצורות דורש ששכבת ה-OCI תידחס בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר מ-REPO תקין לתמונת OCI עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.
- ‫NAMESPACE_DIRECTORY: מוסיפים את הנתיב במקור לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן אליה. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המקור.
- ‫NAMESPACE_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.
Helm
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫HELM_CHART_NAME: מוסיפים את השם של תרשים Helm. חובה למלא את השדה הזה.
- ‫HELM_CHART_VERSION: הגרסה של התרשים. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש בגרסה האחרונה.
- ‫HELM_RELEASE_NAME: השם של מהדורת Helm. השדה הזה הוא אופציונלי.
- ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. היא מגדירה מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש במרחב השמות שמוגדר כברירת מחדל config-management-system.
- ‫HELM_INCLUDE_CRDS: צריך להגדיר את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא תציינו ערך, ברירת המחדל היא false ולא ייווצר CRD.
- ‫VALUE: ערכים לשימוש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. הפורמט של השדה הזה צריך להיות זהה לפורמט של קובץ values.yaml של תרשים helm. השדה הזה הוא אופציונלי.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫token: משתמשים בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_SECRET_NAME: מוסיפים את השם של הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Helm שלכם חייב להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.
אם אתם משתמשים ב-gcpserviceaccount כסוג האימות ולא הפעלתם את התכונה 'איחוד זהויות של עומסי עבודה' ב-GKE, אתם צריכים ליצור קשר בין מדיניות IAM בין חשבון השירות של Kubernetes לבין חשבון השירות של Google עבור כל מרחב שמות. הוראות ליצירת הקישור הזה מופיעות במאמר בנושא הענקת גישה ל-Git.

מבצעים Commit של השינויים למקור האמת הבסיסי:

 git add .
 git commit -m 'Setting up a new namespace-scoped source of truth.'
 git push

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

הסוד צריך לעמוד בדרישות הבאות:
- יוצרים את הסוד באותו מרחב שמות כמו RepoSync.
- השם של הסוד חייב להיות זהה לשם spec.git.secretRef שהגדרתם ב-repo-sync.yaml.
- צריך להוסיף את המפתח הציבורי של הסוד לספק Git.
כדי לאמת את ההגדרה, משתמשים ב-kubectl get באחד מהאובייקטים במקור האמת שמוגבל למרחב השמות. לדוגמה:
```
kubectl get rolebindings -n NAMESPACE
```
אפשר לחזור על השלבים שלמעלה אם צריך להגדיר יותר ממקור אחד בהיקף של מרחב שמות.

שליטה במקור האמת באמצעות Kubernetes API

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

שליטה ביותר ממקור אחד קובע

אדמינים אחרים יכולים לשלוט במקור האמת הבסיסי על ידי השלמת המשימות הבאות:

שומרים אחד מהקובצי המניפסט הבאים בשם root-sync.yaml. משתמשים בגרסת המניפסט שמתאימה לסוג המקור של ההגדרות.
Git
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ROOT_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git לשימוש כמאגר הבסיסי. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫ROOT_REVISION: מוסיפים את הגרסה של Git (תג או גיבוב) או את ההסתעפות שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
- ‫ROOT_BRANCH: מוסיפים את ההסתעפות של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. מומלץ להשתמש בשדה revision כדי לציין שם של ענף, כדי לפשט את התהליך. אם מציינים גם את השדה revision וגם את השדה branch, השדה revision מקבל עדיפות על פני השדה branch.
- ROOT_DIRECTORY: מוסיפים את הנתיב במאגר Git לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫ssh: שימוש בזוג מפתחות SSH
  - cookiefile: שימוש ב-cookiefile
  - ‫token: שימוש בטוקן
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת ל-Cloud Source Repositories.
  - ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת אל Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
  מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישת קריאה בלבד ל-Git ב-סנכרון תצורות.
  
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, צריך להוסיף את המפתח הציבורי של הסוד לספק Git. השדה הזה הוא אופציונלי.
- ‫ROOT_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Git כמקור.
OCI
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ‫ROOT_IMAGE: כתובת ה-URL של תמונת OCI שבה רוצים להשתמש כמאגר הבסיס, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נמשכת מהתג latest, אבל אפשר למשוך תמונות באמצעות התגים TAG או DIGEST. מציינים TAG או DIGEST במאפיין PACKAGE_NAME:
  - כדי למשוך לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - כדי למשוך לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
זהירות: סנכרון תצורות דורש ששכבת ה-OCI תידחס בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר מ-REPO תקין לתמונת OCI עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.
- ‫ROOT_DIRECTORY: מוסיפים את הנתיב במאגר לספריית הרמה הבסיסית (root) שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש בתמונה של OCI כמקור.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: unstructured
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
- ‫ROOT_HELM_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫HELM_CHART_NAME: מוסיפים את השם של תרשים Helm. חובה למלא את השדה הזה.
- ‫HELM_CHART_VERSION: הגרסה של התרשים. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש בגרסה האחרונה.
- ‫HELM_RELEASE_NAME: השם של מהדורת Helm. השדה הזה הוא אופציונלי.
- ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. היא מגדירה מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש במרחב השמות שמוגדר כברירת מחדל config-management-system.
- ‫HELM_INCLUDE_CRDS: צריך להגדיר את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא תציינו ערך, ברירת המחדל היא false ולא ייווצר CRD.
- ‫VALUE: ערכים לשימוש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. הפורמט של השדה הזה צריך להיות זהה לפורמט של קובץ values.yaml של תרשים helm. השדה הזה הוא אופציונלי.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫token: משתמשים בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫ROOT_SECRET_NAME: מוסיפים את השם של הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.
- ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Helm שלכם חייב להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים

הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

קובץ המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Helm כמקור.
מחילים את השינויים:
```
kubectl apply -f root-sync.yaml
```
אם אתם צריכים להגדיר יותר ממקור אמת בסיסי אחד, אתם יכולים לחזור על השלבים שלמעלה.

שליטה במקורות מידע אמינים בהיקף מרחב השמות

משימות של אדמין מרכזי

האדמין המרכזי מבצע את המשימות הבאות:

במקור האמת הראשי, מגדירים namespace למקורות בהיקף מרחב השמות.
```
# ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
 apiVersion: v1
 kind: Namespace
 metadata:
   name: NAMESPACE
```
מחליפים את NAMESPACE בשם של מרחב השמות.
במקור האמת הבסיסי, מכריזים על RoleBinding כדי לתת הרשאות למפעילים של האפליקציה. כדי לוודא שאופרטור האפליקציה לא יוכל להחיל מאוחר יותר קישור תפקידים עם הרשאות שלא הוענקו על ידי קישור התפקידים הזה, אפשר להשתמש במניעת הסלמת RBAC.

כדי להצהיר על RoleBinding, יוצרים את המניפסט הבא:
```
# ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml
 kind: RoleBinding
 # Add RBAC escalation prevention
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: operator
   namespace: NAMESPACE
 subjects:
 - kind: User
   name: USERNAME
   apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: ClusterRole
   name: OPERATOR_ROLE
   apiGroup: rbac.authorization.k8s.io
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NAMESPACE: מוסיפים את מרחב השמות שיצרתם למקור האמת הבסיסי.
- ‫USERNAME: מוסיפים את שם המשתמש של מפעיל האפליקציה.
- ‫OPERATOR_ROLE: בתור האדמין המרכזי, אתם יכולים להגדיר את OPERATOR_ROLE כדי לאכוף את סוגי ההגדרות שאפשר לסנכרן ממקור בהיקף מרחב השמות. אפשר לבחור באחד מהתפקידים הבאים:
  - ‫ClusterRole שמוגדר כברירת מחדל:
    - admin
    - edit
    מידע נוסף זמין במאמר בנושא תפקידים שמוצגים למשתמשים.
  - תפקיד או תפקיד אשכולי שהוגדרו על ידי המשתמש והוצהרו במקור האמת הבסיסי. התפקיד הזה מאפשר להגדיר הרשאות פרטניות.

מבצעים Commit של השינויים למקור האמת הבסיסי:

 git add .
 git commit -m 'Setting up new namespace-scoped source of truth.'
 git push

משימות של מפעיל אפליקציה

מפעיל האפליקציה יכול לשלוט במקורות בהיקף מרחב השמות על ידי השלמת המשימות הבאות:

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

כדי להצהיר על RoleBinding, יוצרים את המניפסט הבא:
```
# sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫NAMESPACE: מוסיפים את מרחב השמות שיצרתם למקור האמת הבסיסי.
- ‫SERVICE_ACCOUNT_NAME: מוסיפים את השם של חשבון השירות של הכלי להשוואה. אם השם של RepoSync הוא repo-sync, SERVICE_ACCOUNT_NAME הוא ns-reconciler-NAMESPACE. אחרת, הערך הוא ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
- ‫RECONCILER_ROLE: כמפעיל האפליקציה, אתם יכולים להגדיר את RECONCILER_ROLE כדי לאכוף את סוגי ההגדרות שאפשר לסנכרן מהמקור בהיקף מרחב השמות. אתם יכולים רק להגביל עוד יותר את קבוצת ההרשאות שהאדמין המרכזי העניק לכם. כתוצאה מכך, התפקיד הזה לא יכול להיות בעל הרשאות רחבות יותר מההרשאות של OPERATOR_ROLE שהאדמין המרכזי הצהיר עליהן בקטע הקודם.
החלת ההגדרה RoleBinding:
```
kubectl apply -f sync-rolebinding.yaml
```
אם נדרש, יוצרים סוד על סמך שיטת האימות המועדפת. אם השתמשתם ב-none כסוג האימות, אתם יכולים לדלג על השלב הזה.

הסוד צריך לעמוד בדרישות הבאות:
- יוצרים את הסוד באותו מרחב שמות כמו RepoSync.
- השם של הסוד חייב להיות זהה לשם spec.git.secretRef שהגדרתם ב-root-sync.yaml.
- צריך להוסיף את המפתח הציבורי של הסוד לספק Git.
הצהרה על הגדרה של RepoSync:
Git
```
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git לשימוש כמאגר מרחב שמות. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, ‫https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. אם לא מזינים פרוטוקול, המערכת מתייחסת לכתובת ה-URL כאל כתובת URL מסוג HTTPS. חובה למלא את השדה הזה.
- ‫NAMESPACE_REVISION: מוסיפים את הגרסה של Git (תג או גיבוב) או את ההסתעפות שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
- ‫NAMESPACE_BRANCH: מוסיפים את ההסתעפות של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. מומלץ להשתמש בשדה revision כדי לציין שם של ענף, כדי לפשט את התהליך. אם מציינים גם את השדה revision וגם את השדה branch, השדה revision מקבל עדיפות על פני השדה branch.
- ‫NAMESPACE_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫ssh: שימוש בזוג מפתחות SSH
  - cookiefile: שימוש ב-cookiefile
  - ‫token: שימוש בטוקן
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories.
  - ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
    
    מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישת קריאה בלבד ל-Git ב-סנכרון תצורות.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כNAMESPACE_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_SECRET_NAME: מוסיפים את השם שרוצים לתת ל-Secret. השדה הזה הוא אופציונלי.
- ‫NAMESPACE_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RepoSync.
OCI
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_IMAGE: כתובת ה-URL של תמונת OCI לשימוש כמקור של מרחב השמות, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נמשכת מהתג latest, אבל אפשר למשוך תמונות באמצעות התגים TAG או DIGEST. מציינים את TAG או DIGEST בPACKAGE_NAME:
  - כדי למשוך לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - כדי למשוך לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  זהירות: סנכרון תצורות דורש ששכבת ה-OCI תידחס בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר מ-REPO תקין לתמונת OCI עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.
- ‫NAMESPACE_DIRECTORY: מוסיפים את הנתיב במקור לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן אליה. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המקור.
- ‫NAMESPACE_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.
Helm
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫REPO_SYNC_NAME: מוסיפים את השם של אובייקט RepoSync. השם צריך להיות ייחודי במרחב השמות.
- ‫NAMESPACE: מוסיפים את השם של מרחב השמות.
- ‫NAMESPACE_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או פרוטוקול SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
- ‫HELM_CHART_NAME: מוסיפים את השם של תרשים Helm. חובה למלא את השדה הזה.
- ‫HELM_CHART_VERSION: הגרסה של התרשים. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש בגרסה האחרונה.
- ‫HELM_RELEASE_NAME: השם של מהדורת Helm. השדה הזה הוא אופציונלי.
- ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. היא מגדירה מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא תציינו ערך, נשתמש במרחב השמות שמוגדר כברירת מחדל config-management-system.
- ‫HELM_INCLUDE_CRDS: צריך להגדיר את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא תציינו ערך, ברירת המחדל היא false ולא ייווצר CRD.
- ‫VALUE: ערכים לשימוש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. הפורמט של השדה הזה צריך להיות זהה לפורמט של קובץ values.yaml של תרשים helm. השדה הזה הוא אופציונלי.
- ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:
  - ‫none: לא להשתמש באימות
  - ‫token: משתמשים בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לאימג' ב-Artifact Registry. בוחרים באפשרות הזו רק אם התכונה איחוד זהויות של עומסי עבודה ל-GKE לא מופעלת באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  חובה למלא את השדה הזה.
- ‫NAMESPACE_EMAIL: אם הוספתם את gcpserviceaccount כROOT_AUTH_TYPE, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.s3ns.iam.gserviceaccount.com.
- ‫NAMESPACE_SECRET_NAME: מוסיפים את השם של הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.
- ‫NAMESPACE_CA_CERT_SECRET_NAME: מוסיפים את השם של הסוד. אם השדה הזה מוגדר, ספק Helm שלכם חייב להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור רשות האישורים (CA) תחת מפתח בשם cert. השדה הזה אופציונלי.
  
  מידע נוסף על הגדרת אובייקט Secret לאישור CA זמין במאמר הגדרת רשות אישורים
הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.
מחילים את ההגדרה RepoSync:
```
kubectl apply -f repo-sync.yaml
```
כדי לאמת את ההגדרה, משתמשים ב-kubectl get באחד מהאובייקטים במקור שמוגבל למרחב השמות. לדוגמה:
```
kubectl get rolebindings -n NAMESPACE
```
אם אתם צריכים להגדיר כמה מקורות אמת בהיקף של מרחב שמות, אתם יכולים לחזור על השלבים שלמעלה .

אימות סטטוס הסנכרון של מקור האמת

אפשר להשתמש בפקודה nomos status כדי לבדוק את סטטוס הסנכרון של מקור האמת:

nomos status

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

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  git@github.com:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

בפלט לדוגמה הזה, המקור שמוגבל למרחב השמות, במקרה הזה מאגר Git, מוגדר למרחב שמות בשם bookstore.

אימות ההתקנה של RootSync

כשיוצרים אובייקט RootSync, ‏ סנכרון תצורות יוצר כלי לתיקון שגיאות עם הקידומת root-reconciler. תהליך הגישור הוא Pod שמתבצע כפריסה. הוא מסנכרן מניפסטים ממקור מידע אמין לאשכול.

כדי לוודא שאובייקט RootSync פועל בצורה תקינה, בודקים את הסטטוס של הפריסה של root-reconciler:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

מחליפים את ROOT_SYNC_NAME בשם של RootSync.

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

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

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

אימות ההתקנה של RepoSync

כשיוצרים אובייקט RepoSync, ‏ סנכרון תצורות יוצר reconciler עם הקידומת ns-reconciler-NAMESPACE, כאשר NAMESPACE הוא מרחב השמות שבו יצרתם את אובייקט RepoSync.

כדי לוודא שאובייקט RepoSync פועל בצורה תקינה, צריך לבדוק את הסטטוס של פריסת namespace reconciler:

kubectl get -n config-management-system deployment \
  -l configsync.gke.io/sync-name=REPO_SYNC_NAME \
  -l configsync.gke.io/sync-namespace=NAMESPACE

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

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

הסרת מקור מידע אמין

בוחרים בכרטיסייה שיטת בקרה מרכזית או בכרטיסייה שיטת Kubernetes API כדי לראות את ההוראות הרלוונטיות.

שיטת בקרה מרכזית

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

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

שיטת Kubernetes API

אם השתמשתם בשיטה שליטה במקורות אמת בהיקף של מרחב שמות באמצעות Kubernetes API, מפעילים של אפליקציות יכולים לבצע את השלבים הבאים כדי להסיר מקור אמת בהיקף של מרחב שמות:

מחליטים אם רוצים למחוק או לשמור את המשאבים שמנוהלים באמצעות אובייקטים של RootSync ו-RepoSync.
- כדי למחוק את כל המשאבים שמנוהלים על ידי אובייקטים של RootSync או RepoSync, צריך לסנכרן את האובייקט של RootSync או RepoSync עם מקור ריק. לדוגמה, מאגר GitHub ללא הגדרות. אם אובייקט RootSync או RepoSync מכיל אובייקט RootSync או RepoSync אחר, צריך קודם לסנכרן את אובייקט RootSync או RepoSync הפנימי למאגר Git ריק.
- אם הפעלתם את ה-webhook ואתם רוצים לשמור את המשאבים, צריך להשבית את מניעת הסחף למשאבים שהוצאו משימוש. אם לא הפעלתם את ה-webhook, לא צריך לבצע פעולות נוספות כדי לשמור את המשאבים.
מריצים את הפקודה הבאה כדי למחוק את האובייקט RootSync או RepoSync:
```
kubectl delete -f FILE_NAME
```
מחליפים את FILE_NAME בשם של קובץ התצורה של RootSync או RepoSync. לדוגמה, root-sync.yaml.

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

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

הגדרת סנכרון מכמה מקורות מידע אמינים

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

יצירת RoleBinding

Default ClusterRoles

תפקידים שהוגדרו על ידי משתמש

מגבלות

בחירת שיטת ההגדרה המועדפת

שליטה במקורות במקור מידע אמין ברמת הבסיס

שליטה במקורות הבסיסיים במקור בסיסי של מידע אמין

Git

OCI

Helm

שליטה באובייקטים בהיקף מרחב השמות במקור האמת הבסיסי

Git

OCI

Helm

שליטה במקורות בהיקף מרחב שמות במקור בהיקף מרחב שמות

Git

OCI

Helm

שליטה במקור האמת באמצעות Kubernetes API

שליטה ביותר ממקור אחד קובע

Git

OCI

Helm

שליטה במקורות מידע אמינים בהיקף מרחב השמות

משימות של אדמין מרכזי

משימות של מפעיל אפליקציה

Git

OCI

Helm

אימות סטטוס הסנכרון של מקור האמת

אימות ההתקנה של RootSync

אימות ההתקנה של RepoSync

הסרת מקור מידע אמין

שיטת בקרה מרכזית

שיטת Kubernetes API

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