פיצול מאגר לכמה מאגרים

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

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

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

אם מאגר הבסיס מכיל מספר גדול של משאבים (לדוגמה, יותר מ-5,000), יכול להיות שיהיו בעיות בביצועים או בסנכרון של סנכרון תצורות מהסיבות הבאות:

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

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

פירוק של מאגר בסיס לא מובנה

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

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

‫1.21.0 ואילך (מומלץ)

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

נניח שמאגר הבסיס מסונכרן על ידי האובייקט RootSync single-root-sync. אחרי פיצול המאגר, יש לכם שני מאגרי שורש. אחד מסונכרן על ידי האובייקט RootSync של root-sync-1 והשני מסונכרן על ידי האובייקט RootSync של root-sync-2.

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

1. מוודאים של-RootSync single-root-sync יש את ערך ההערה configsync.gke.io/deletion-propagation-policy של Orphan או שהוא לא מוגדר. ערך ברירת המחדל כשהמדיניות לא מוגדרת זהה לערך Orphan. ההגדרה הזו מבטיחה שהאובייקטים לא יימחקו.

2. מוחקים את RootSync single-root-sync:

   kubectl delete rootsync single-root-sync -n config-management-system
   

3. כדי להגדיר את המאגרים החדשים:

   1. יוצרים מאגר חדש או ספרייה חדשה במאגר Git הקיים.
   2. מעבירים את המשאבים למאגר החדש או לספרייה החדשה.
   3. אם אתם מפצלים את מאגר הבסיס ליותר משני מאגרים, חזרו על השלבים האלה לפי הצורך.

4. שומרים ודוחפים את השינוי:

   git commit -am 'add configuration for the new root repository'
   

5. מחילים את האובייקטים root-sync-1 ו-root-sync-2 של RootSync. כך מסנכרנים את המאגר או הספרייה החדשים, כדי שהאובייקטים הקיימים באשכול ינוהלו על ידי אובייקטי RootSync החדשים root-sync-1 ו-root-sync-2:

    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceFormat: unstructured
      git:
        repo: NEW_ROOT_REPOSITORY
        revision: NEW_ROOT_REVISION
        branch: NEW_ROOT_BRANCH
        dir: "NEW_ROOT_DIRECTORY"
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        # secretRef should be omitted if the auth type is none, gcenode, or gcpserviceaccount.
        secretRef:
          name: git-creds
   

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

   • ‫NEW_ROOT_REPOSITORY: כתובת ה-URL של מאגר Git שישמש כמאגר הבסיס החדש. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או SSH. לדוגמה, ב-https://github.com/GoogleCloudPlatform/anthos-config-management-samples נעשה שימוש בפרוטוקול HTTPS. אם לא מזינים פרוטוקול, כתובת ה-URL נחשבת לכתובת URL מסוג HTTPS.
   • ‫NEW_ROOT_REVISION: (אופציונלי) גרסת ה-Git (תג או גיבוב) של מאגר הבסיס החדש שרוצים להוציא.
   • ‫NEW_ROOT_BRANCH: (אופציונלי) הענף של מאגר הבסיס החדש שממנו רוצים לסנכרן.
   • ‫NEW_ROOT_DIRECTORY: (אופציונלי) הנתיב במאגר Git לתיקיית השורש החדשה שמכילה את ההגדרות שרוצים לסנכרן.
   • ‫ROOT_AUTH_TYPE: הערך הזה צריך להיות זהה לאובייקט RootSync/root-sync הקיים.
   • ‫ROOT_EMAIL: הערך הזה צריך להיות זהה לאובייקט RootSync/root-sync הקיים.

6. מחכים שהאובייקט החדש של RootSync ב-root-sync-1 יסונכרן. כדי לבדוק את הסטטוס, משתמשים בפקודה הבאה:

   nomos status
   

כל הגרסאות

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

נניח שמאגר הבסיס מסונכרן על ידי האובייקט RootSync root-sync. אחרי פיצול המאגר, יש לכם שני מאגרי שורש. אחד מסונכרן על ידי האובייקט root-sync של RootSync, והשני מסונכרן על ידי האובייקט root-sync-1 של RootSync.

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

1. במאגר הבסיס הקיים, בוחרים את המשאבים שרוצים להעביר למאגר או לספרייה אחרים ומוסיפים להם את ההערה configmanagement.gke.io/managed: disabled. ההערה הזו מבטיחה שהאובייקטים הקיימים באשכול לא יושפעו כשמעבירים את ההגדרות שלהם ממאגר אחד למאגר אחר. אם אתם משתמשים בפורמט Kustomize או בתרשימי Helm, אתם יכולים לבחור בערך חצי מהבסיסים ולהוסיף את ההערה הנפוצה לקובץ kustomization.yaml, כמו בדוגמה הזו:

   # kustomization.yaml
   commonAnnotations:
     configmanagement.gke.io/managed: disabled
   

2. שומרים ודוחפים את השינוי: sh git commit -am 'disable Config Sync management on subset of the configuration'

3. ממתינים לסנכרון של אובייקט root-sync RootSync הקיים באמצעות הפקודה הבאה:

   nomos status
   

4. כדי להגדיר את המאגר השני:

   1. יוצרים מאגר חדש או ספרייה חדשה במאגר Git הקיים.
   2. מעתיקים את המשאבים עם ההערה configmanagement.gke.io/managed: disabled למאגר החדש או לספרייה החדשה.
   3. מסירים את ההערה configmanagement.gke.io/managed: disabled במאגר או בספרייה החדשים.
   4. אם אתם מפצלים את מאגר הבסיס ליותר משני מאגרים, חזרו על השלבים האלה לפי הצורך.

5. שומרים ודוחפים את השינוי:

   git commit -am 'add configuration for the new root repository'
   

6. מחילים אובייקט RootSync של root-sync-1 כדי לסנכרן את המאגר או הספרייה החדשים, כך שהאובייקטים הקיימים באשכול ינוהלו על ידי אובייקט RootSync החדש של root-sync-1.

    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: root-sync-1
      namespace: config-management-system
    spec:
      sourceFormat: unstructured
      git:
        repo: NEW_ROOT_REPOSITORY
        revision: NEW_ROOT_REVISION
        branch: NEW_ROOT_BRANCH
        dir: "NEW_ROOT_DIRECTORY"
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        # secretRef should be omitted if the auth type is none, gcenode, or gcpserviceaccount.
        secretRef:
          name: git-creds
   

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

   • ‫NEW_ROOT_REPOSITORY: כתובת ה-URL של מאגר Git שישמש כמאגר הבסיס החדש. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או SSH. לדוגמה, ב-https://github.com/GoogleCloudPlatform/anthos-config-management-samples נעשה שימוש בפרוטוקול HTTPS. אם לא מזינים פרוטוקול, כתובת ה-URL נחשבת לכתובת URL מסוג HTTPS.
   • ‫NEW_ROOT_REVISION: (אופציונלי) גרסת ה-Git (תג או גיבוב) של מאגר הבסיס החדש שרוצים להוציא.
   • ‫NEW_ROOT_BRANCH: (אופציונלי) הענף של מאגר הבסיס החדש שממנו רוצים לסנכרן.
   • ‫NEW_ROOT_DIRECTORY: (אופציונלי) הנתיב במאגר Git לתיקיית השורש החדשה שמכילה את ההגדרות שרוצים לסנכרן.
   • ‫ROOT_AUTH_TYPE: הערך הזה צריך להיות זהה לאובייקט RootSync/root-sync הקיים.
   • ‫ROOT_EMAIL: הערך הזה צריך להיות זהה לאובייקט RootSync/root-sync הקיים.

7. מחכים שהאובייקט החדש של RootSync ב-root-sync-1 יסונכרן. כדי לבדוק את הסטטוס, משתמשים בפקודה הבאה:

   nomos status
   

8. מסירים את המשאבים עם ההערה configmanagement.gke.io/managed: disabled מהמאגר המקורי. שומרים ודוחפים את השינוי:

   git commit -am 'remove configuration managed by the new root repository'
   

9. ממתינים לסנכרון של אובייקט root-sync RootSync הקיים באמצעות הפקודה הבאה:

   nomos status
   

פיצול מאגר בסיס היררכי

השלבים לפירוק מאגר היררכי דומים לשלבים לפירוק מאגר לא מובנה.

יש שלושה הבדלים עיקריים:

1. גם מאגר הבסיס החדש (או הספרייה החדשה) צריך להיות היררכי. צריך להעתיק את הספרייה הקיימת system/ ואת הספריות clusterregistry/ למאגר הבסיס החדש (או לספרייה החדשה).

2. המשאבים במרחב שמות לא יכולים להתפרס על פני כמה מאגרים. אחרת, גורמי התאמה שונים יתחרו על ניהול מרחב השמות.

3. האובייקט root-sync-1 RootSync צריך להשתמש ב-spec.sourceFormat: hierarchical.

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