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

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

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

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

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

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

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

אובייקטים של RootSync משמשים להסבר השלבים. אפשר להשתמש בשלבים גם לאובייקטים של RepoSync.

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

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

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

  1. מוודאים של-RootSync single-root-sync יש ערך הערה של Orphan או שהוא לא מוגדר.configsync.gke.io/deletion-propagation-policy ערך ברירת המחדל כשלא מוגדר כלום זהה לערך 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 (תג או hash) של מאגר הבסיס החדש שרוצים להוציא.
    • 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 ואילך כי היא דורשת פחות שלבים. אם הגרסה של Config Sync שלכם קודמת לגרסה 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. מחכים שאובייקט RootSync הקיים root-sync יסונכרן באמצעות הפקודה הבאה:

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

     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 (תג או hash) של מאגר הבסיס החדש שרוצים להוציא.
    • 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.

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