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

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

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

התקנת סנכרון תצורות באשכולות נפרדים באמצעות מסוףGoogle Cloud , Google Cloud CLI או Terraform.
הגדרת מאגר הבסיס, כולל סוג המקור, הפורמט והאימות.
אימות ההתקנה וההגדרה של סנכרון תצורות.

מגבלות

‫סנכרון תצורות לא תומך בהגדרת helm כסוג המקור באמצעות מסוף Google Cloud או Google Cloud CLI. אפשר להגדיר את האובייקט RootSync או RepoSync לסנכרון ממאגר Helm באמצעות Kubernetes API, או להצהיר עליו במקור אמת אחר. מידע נוסף מופיע בקטע הגדרות למאגר Helm.

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

לפני שמתקינים את סנכרון תצורות, צריך להכין מקור אמת ואשכול מתאים.

הענקת גישה ל-Config Sync למקור המידע האמין

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

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

בדיקת הדרישות לאשכול

לפני שיוצרים אשכול, כדאי לעיין בדרישות לאשכול.

התקנת סנכרון תצורות

כשמתקינים את סנכרון תצורות באמצעות מסוף Google Cloud או Google Cloud CLI, ‏ סנכרון תצורות יוצר באופן אוטומטי אובייקט RootSync בשם root-sync. אפשר להשתמש בפקודות kubectl כדי לשנות את root-sync ולהוסיף הגדרות נוספות של סנכרון תצורות. מידע נוסף זמין במאמר בנושא הגדרת סנכרון תצורה באמצעות פקודות kubectl.

המסוף

התקנת סנכרון תצורות

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

נכנסים לדף Config במסוף Google Cloud , בקטע Features.

מעבר אל Config

לוחצים על Install Config Sync (התקנת סנכרון תצורות).
בוחרים את הגרסה של סנכרון תצורות שרוצים להשתמש בה.
בקטע Installation options (אפשרויות התקנה), בוחרים באחת מהאפשרויות הבאות:
- התקנת סנכרון תצורות בכל האוסף (מומלץ): סנכרון תצורות מותקן בכל האשכולות באוסף.
- התקנת סנכרון תצורות באשכולות ספציפיים: המערכת מתקינה את סנכרון תצורות באשכולות שאתם בוחרים. כל האשכולות שנבחרו נרשמים אוטומטית לצי.
אם אתם מתקינים את סנכרון תצורות באשכולות נפרדים, בטבלה Available clusters (אשכולות זמינים), בוחרים את האשכולות שבהם רוצים להתקין את סנכרון תצורות.
לוחצים על Install Config Sync (התקנת סנכרון תצורות). בכרטיסייה הגדרות, אחרי כמה דקות, אמור להופיע הסטטוס מופעל בעמודה סטטוס עבור האשכולות בצי.

פריסת חבילה

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

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

במסוף Google Cloud , נכנסים אל מרכז הבקרה של סנכרון תצורות.

מעבר ללוח הבקרה של סנכרון תצורות
לוחצים על Deploy Package (פריסת חבילה).
בטבלה Select clusters for package deployment (בחירת אשכולות לפריסת חבילות), בוחרים את האשכול שרוצים לפרוס בו חבילה ולוחצים על Continue (המשך).
בוחרים באפשרות Package hosted on Git (חבילה שמתארחת ב-Git) או באפשרות Package hosted on OCI (חבילה שמתארחת ב-OCI) כסוג המקור, ואז לוחצים על Continue (המשך).
בקטע פרטי החבילה, מזינים שם חבילה שמזהה את אובייקט RootSync או RepoSync.
בשדה סוג הסנכרון, בוחרים באפשרות סנכרון בהיקף אשכול או סנכרון בהיקף מרחב שמות כסוג הסנכרון.

סנכרון בהיקף אשכול יוצר אובייקט RootSync, וסנכרון בהיקף מרחב שמות יוצר אובייקט RepoSync. מידע נוסף על האובייקטים האלה זמין במאמר בנושא ארכיטקטורת סנכרון תצורות.
בקטע מקור, מבצעים את הפעולות הבאות:
- למקורות שמתארחים במאגר Git, צריך להזין את השדות הבאים:
  1. מזינים את כתובת ה-URL של מאגר Git שמשמש כמקור אמת בכתובת ה-URL של המאגר.
  2. אופציונלי: מעדכנים את השדה Revision כדי לבדוק אם לא משתמשים ב-HEAD שמוגדר כברירת מחדל.
  3. אופציונלי: מעדכנים את השדה Path (נתיב) אם לא רוצים לסנכרן ממאגר הבסיס.
  4. אופציונלי: אם אתם לא משתמשים בענף ברירת המחדל main, אתם יכולים לעדכן את השדה Branch (ענף).
- אם המקורות מאוחסנים בתמונה של OCI, צריך להזין את השדות הבאים:
  1. מזינים את כתובת ה-URL של תמונת ה-OCI שבה אתם משתמשים כמקור אמת בתמונה.
  2. מזינים את הנתיב של הספרייה שממנה רוצים לסנכרן, ביחס לספריית הבסיס, בתור Directory.
(אופציונלי): מרחיבים את הקטע הגדרות מתקדמות כדי להשלים את הפעולות הבאות:
1. בוחרים סוג אימות. לסנכרון תצורות נדרשת גישת קריאה בלבד למקור המידע האמין כדי לקרוא את קובצי התצורה במקור ולהחיל אותם על האשכולות. אלא אם המקור שלכם לא דורש אימות, כמו מאגר ציבורי, אתם צריכים לוודא שנתתם ל-סנכרון תצורות גישת קריאה בלבד למאגר Git, לתמונת OCI או לתרשים Helm (רק ב-ה-CLI של gcloud). בוחרים את אותו סוג אימות שהגדרתם כשביצעתם את ההתקנה של סנכרון תצורות:
  
  הערה: ב-OCI, אפשר לבחור רק באפשרות Workload Identity לאימות.
  - ללא: לא נעשה שימוש באימות.
  - ‫SSH: אימות באמצעות זוג מפתחות SSH.
  - ‫Cookiefile: אימות באמצעות cookiefile.
  - טוקן: אימות באמצעות טוקן גישה או סיסמה.
  - מאגר Google Cloud: שימוש בחשבון שירות של Google כדי לגשת למאגר Cloud Source Repositories. בוחרים באפשרות הזו רק אם לא מופעלת ב-GKE ב-cluster שלכם פדרציית זהויות של עומסי עבודה.
  - ‫Workload Identity: שימוש בחשבון שירות של Google כדי לגשת למאגר Cloud Source Repositories.
2. מזינים מספר בשניות כדי להגדיר את זמן ההמתנה לסנכרון תצורות, שקובע כמה זמן סנכרון תצורות ימתין בין ניסיונות משיכה ממקור האמת.
3. מזינים כתובת URL של Git proxy ל-HTTPS proxy שבו ישתמשו כשמתקשרים עם המקור המהימן.
לוחצים על Deploy Package (פריסת חבילה).

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

gcloud

לפני שממשיכים, צריך לוודא שרשמתם את האשכולות בצי.

הפעלת התכונה ConfigManagement לצי הרכבים:

gcloud beta container fleet config-management enable

מכינים את ההגדרה על ידי יצירת קובץ בשם apply-spec.yaml והעתקת קובץ ה-YAML הבא לתוכו.

אפשר להגדיר את כל השדות האופציונליים spec.configSync שצריך כשיוצרים את קובץ המניפסט, ואחר כך להשתמש בפקודות kubectl להגדרה. אפשר גם להגדיר רק את השדה spec.configSync.enabled כ-true ולהשמיט את השדות האופציונליים. אחר כך תוכלו להשתמש בפקודות kubectl כדי ליצור אובייקטים נוספים של RootSync או RepoSync, שתוכלו לנהל באופן מלא באמצעות פקודות kubectl בהמשך.
```
# apply-spec.yaml

     applySpecVersion: 1
     spec:
       configSync:
         enabled: true
         # If you don't have a source of truth yet, omit the
         # following fields. You can configure them later.
         sourceType: SOURCE_TYPE
         sourceFormat: FORMAT
         syncRepo: REPO
         syncRev: REVISION
         secretType: SECRET_TYPE
         gcpServiceAccountEmail: EMAIL
         metricsGcpServiceAccountEmail: METRICS_EMAIL
         policyDir: DIRECTORY
         preventDrift: false
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫SOURCE_TYPE: מוסיפים git כדי לסנכרן ממאגר Git,‏ oci כדי לסנכרן מתמונה של OCI או helm כדי לסנכרן מתרשים Helm. אם לא תציינו ערך, נשתמש בערך ברירת המחדל git.
- ‫FORMAT: מוסיפים unstructured כדי להשתמש במאגר לא מובנה או מוסיפים hierarchy כדי להשתמש במאגר היררכי. הערכים האלה הם תלויי אותיות רישיות. השדה הזה הוא אופציונלי וערך ברירת המחדל שלו הוא hierarchy. מומלץ להוסיף את unstructured, כי הפורמט הזה מאפשר לכם לארגן את ההגדרות בצורה הכי נוחה לכם.
- ‫REPO: מוסיפים את כתובת ה-URL של מקור האמת. כתובות URL של מאגרי Git ו-Helm משתמשות בפרוטוקול HTTPS או SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. אם אתם מתכננים להשתמש ב-SSH כsecretType, צריך להזין את כתובת ה-URL עם פרוטוקול ה-SSH. זהו שדה חובה, ואם לא מזינים פרוטוקול, המערכת מתייחסת לכתובת ה-URL כאל כתובת URL מסוג HTTPS.
  
  כתובות 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 עם פורמט לא נתמך יגרום לגיזום של משאבים מנוהלים ללא שגיאה.
- ‫REVISION: מספר הגרסה ב-Git (תג או גיבוב) או שם ההסתעפות שממנו רוצים לסנכרן. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא קיצור.
- ‫SECRET_TYPE: אחת מהאפשרויות הבאות secretTypes:
  git
  - ‫none: לא נעשה שימוש באימות.
  - ‫ssh: שימוש בזוג מפתחות SSH.
  - ‫cookiefile: שימוש ב-cookiefile.
  - ‫token: שימוש באסימון.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת למאגר של Cloud Source Repositories או של Secure Source Manager. אם בוחרים בסוג האימות הזה, צריך ליצור קשר בין מדיניות IAM אחרי שמסיימים להגדיר את סנכרון תצורות. לפרטים, ראו את הכרטיסייה 'חשבון שירות של Google' בקטע הענקת גישה ל-סנכרון תצורות ל-Git באמצעות חשבון שירות של Google.
  - ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת אל Cloud Source Repositories. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
  - ‫githubapp: שימוש באפליקציית GitHub לאימות למאגר GitHub.
  מידע נוסף על סוגי האימות האלה זמין במאמר בנושא הענקת גישה ל-סנכרון תצורות ל-Git.
  oci
  - ‫none: לא להשתמש באימות
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לתמונה ב-Artifact Registry. בוחרים באפשרות הזו רק אם איחוד הזהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  קסדה
  - ‫token: שימוש באסימון.
  - ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine כדי לגשת לתמונה ב-Artifact Registry. בוחרים באפשרות הזו רק אם איחוד הזהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
  - ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.
  - ‫EMAIL: אם הוספתם את gcpserviceaccount כ-secretType, צריך להוסיף את כתובת האימייל של חשבון השירות שלכם ב-Google. לדוגמה, acm@PROJECT_ID.iam.gserviceaccount.com.
  - ‫METRICS_EMAIL: כתובת האימייל של Google Cloud חשבון השירות (GSA) שמשמש לייצוא מדדים של סנכרון תצורות אל Cloud Monitoring. ל-GSA צריך להיות תפקיד IAM של כתיבת מדדי מעקב (roles/monitoring.metricWriter). ה-ServiceAccount‏ default של Kubernetes במרחב השמות config-management-monitoring צריך להיות מקשר ל-GSA.
  - ‫DIRECTORY: הנתיב של הספרייה שממנה רוצים לסנכרן, ביחס לשורש של מאגר Git. כל ספריות המשנה של הספרייה שציינתם נכללות ומסונכרנות לאשכול. ערך ברירת המחדל הוא ספריית הבסיס של המאגר.
רשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעה במאמר שדות gcloud.

הערה: אם עדיין לא הכנתם מקור אמת, אתם יכולים להפעיל את סנכרון תצורות בלי להגדיר הגדרות כלשהן. לשם כך, צריך להגדיר את spec.configSync.enabled לערך true ולהשמיט את כל שדות spec.configSync האחרים. אחרי שמכינים את המאגר, עורכים את apply-spec.yaml כדי להוסיף את הגדרות התצורה.
מחילים את הקובץ apply-spec.yaml. אם אתם משתמשים במניפסט קיים, אתם צריכים להחיל את הקובץ על האשכול שאתם רוצים להגדיר עם ההגדרות שאחזרתם בפקודה הקודמת:
```
gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=CONFIG_YAML_PATH \
    --project=PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MEMBERSHIP_NAME: השם של החברות ב-Fleet שבחרתם כשביצעתם רישום של האשכול. אפשר למצוא את השם באמצעות הפקודה gcloud container fleet memberships list.
- ‫CONFIG_YAML_PATH: הנתיב לקובץ apply-spec.yaml.
- PROJECT_ID: מזהה הפרויקט.

Terraform

לכל אשכול שרוצים להגדיר בו את סנכרון תצורות, מחילים בלוק משאבים של google_gkehub_feature_membership שמכיל בלוקים של configmanagement ו-config_sync, כמו בדוגמה הבאה:

git

data "google_project" "default" {}

resource "google_container_cluster" "default" {
  name     = "gke-autopilot-basic"
  location = "us-central1"

  fleet {
    project = data.google_project.default.project_id
  }

  enable_autopilot = true
}

resource "google_gke_hub_feature" "configmanagement_feature" {
  name     = "configmanagement"
  location = "global"
}

resource "google_gke_hub_feature_membership" "configmanagement_feature_member" {
  location = "global"

  feature             = google_gke_hub_feature.configmanagement_feature.name
  membership          = google_container_cluster.default.fleet[0].membership_id
  membership_location = google_container_cluster.default.fleet[0].membership_location

  configmanagement {
    config_sync {
      # The field `enabled` was introduced in Terraform version 5.41.0, and
      # needs to be set to `true` explicitly to install Config Sync.
      enabled = true
      git {
        sync_repo   = "REPO"
        sync_branch = "BRANCH"
        policy_dir  = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
  }
}

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

‫REPO: כתובת ה-URL למאגר Git שמכיל את קובצי ההגדרות.
‫BRANCH: הענף במאגר, לדוגמה main.
‫DIRECTORY: הנתיב במאגר Git שמייצג את הרמה העליונה של המאגר שרוצים לסנכרן.
SECRET: סוג האימות הסודי.

oci

data "google_project" "default" {}

resource "google_container_cluster" "default" {
  name     = "gke-autopilot-basic"
  location = "us-central1"

  fleet {
    project = data.google_project.default.project_id
  }

  enable_autopilot = true
}

resource "google_gke_hub_feature" "configmanagement_feature" {
  name     = "configmanagement"
  location = "global"
}

resource "google_gke_hub_feature_membership" "configmanagement_feature_member" {
  location = "global"

  feature             = google_gke_hub_feature.configmanagement_feature.name
  membership          = google_container_cluster.default.fleet[0].membership_id
  membership_location = google_container_cluster.default.fleet[0].membership_location

  configmanagement {
    config_sync {
      # The field `enabled` was introduced in Terraform version 5.41.0, and
      # needs to be set to `true` explicitly to install Config Sync.
      enabled = true
      oci {
        sync_repo   = "REPO"
        policy_dir  = "DIRECTORY"
        secret_type = "SECRET"
      }
    }
  }
}

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

‫REPO: כתובת ה-URL למאגר תמונות OCI שמכיל את קובצי ההגדרות.
‫DIRECTORY: הנתיב המוחלט של הספרייה שמכילה את המשאבים שרוצים לסנכרן. כדי להשתמש בספריית הבסיס, צריך להשאיר את השדה הזה ריק.
SECRET: סוג האימות הסודי.

חוזרים על התהליך הזה לכל אשכול שרוצים לסנכרן.

מידע נוסף על שימוש ב-Terraform זמין במאמר תמיכה של Terraform ב-סנכרון תצורות.

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

אימות ההתקנה

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

gcloud

מריצים את הפקודה הבאה:

nomos status

אם ההתקנה בוצעה בהצלחה, הסטטוס יהיה SYNCED או PENDING.

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

console

כך עושים את זה:

נכנסים לדף Config במסוף Google Cloud , בקטע Features.

מעבר אל Config

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

ביטול בקשות למשאבים ומגבלות

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

אפשר לשנות את בקשות המשאבים והמגבלות של חלק מהרכיבים של סנכרון תצורות באמצעות השדה deploymentOverrides בקובץ apply-spec.yaml כשמתקינים את סנכרון תצורות באמצעות ה-CLI של gcloud. אי אפשר להשתמש בשדה deploymentOverrides כדי לבטל שדות אחרים בפריסה, כמו מספר העותקים.

השדה deploymentOverrides יכול לבטל רק את בקשות המשאבים והמגבלות של פריסות שהן לא root או namespace reconciler, כמו reconciler-manager. אם אתם צריכים לבטל את המשאבים של reconciler של שורש או מרחב שמות, אתם יכולים להשתמש בשדה spec.override.resources באובייקט RootSync או RepoSync.

בדוגמה הבאה אפשר לראות איך משתמשים בשדה deploymentOverrides כדי להגדיר בקשה חדשה למעבד ומגבלה חדשה למעבד, ובקשה חדשה לזיכרון ומגבלה חדשה לזיכרון עבור מאגר התגים reconciler-manager:

applySpecVersion: 1
spec:
  configSync:
    enabled: true
    # ... other fields...
    deploymentOverrides:
    - name: reconciler-manager
      namespace: config-management-system
      containers:
      - name: reconciler-manager
        cpuRequest: 50m
        cpuLimit: 100m
        memoryRequest: 256Mi
        memoryLimit: 512Mi

אחרי שיוצרים את הקובץ apply-spec.yaml, מריצים את הפקודה הבאה כדי להחיל אותו:

gcloud beta container fleet config-management apply \
    --membership=MEMBERSHIP_NAME \
    --config=apply-spec.yaml \
    --project=PROJECT_ID

רשימה מלאה של השדות שאפשר לשנות מופיעה במאמרי העזרה בנושא שדות במפרט של gcloud apply.

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

איך משדרגים את Config Sync
מידע נוסף על פקודות gcloud להגדרת סנכרון תצורות
איך מגדירים סנכרון מכמה מאגרי מידע
משתמשים בפקודה nomos.
כדאי לקרוא את המאמר בנושא פתרון בעיות ב-סנכרון תצורות.
איך מסירים את סנכרון תצורות
סקירת הרשאות ברירת המחדל של סנכרון תצורות

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

מגבלות

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

הענקת גישה ל-Config Sync למקור המידע האמין

בדיקת הדרישות לאשכול

התקנת סנכרון תצורות

המסוף

התקנת סנכרון תצורות

פריסת חבילה

gcloud

git

oci

קסדה

Terraform

git

oci

אימות ההתקנה

gcloud

console

ביטול בקשות למשאבים ומגבלות

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

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