בדף הזה מוסבר איך לפצל בבטחה מאגר אחד של שורש לשני מאגרים או יותר של שורש. אפשר להשתמש בשלבים האלה גם במאגרי מרחבי שמות.
מאגר שמסונכרן על ידי סנכרון תצורות מתייחס לשילוב של מאגר Git, הסתעפות, גרסה וספרייה.
אם יש מספר גדול של משאבים, למשל יותר מ-5,000, במאגר הבסיסי, יכול להיות שסנכרון תצורות לא יפעל בצורה תקינה בגלל שתי הסיבות הבאות:
- יכול להיות שהאובייקט ResourceGroup חורג ממגבלת הגודל של אובייקט etcd. אובייקט ResourceGroup מתעד את הקבוצה, הסוג, מרחב השמות והשם של כל המשאבים במאגר Git. מספר גדול של משאבים מוביל לאובייקט ResourceGroup גדול.
- הסנכרון של כל המשאבים ייקח יותר זמן מאשר סנכרון של מאגר עם מספר קטן יותר של משאבים. סנכרון תצורות מחיל את המשאבים על האשכול באופן רציף. לפעמים אי אפשר להחיל את המשאבים בהצלחה בפעם הראשונה, וסנכרון תצורות צריך לנסות שוב להחיל אותם.
אם נתקלים בבעיות האלה, אפשר לפצל את מאגר הבסיס מאחד לכמה מאגרים, כך שבכל מאגר בסיס יהיו פחות משאבים.
פיצול מאגר שורש לא מובנה
אובייקטים של RootSync משמשים להסבר השלבים. אפשר להשתמש בשלבים גם לאובייקטים של RepoSync.
גרסה 1.21.0 ואילך (מומלץ)
השיטה הזו פועלת ב-סנכרון תצורות מגרסה 1.21.0 ואילך, כי נוסף בגרסה הזו finalizer שמפסיק לנהל אובייקטים כשמוחקים אובייקט RootSync או RepoSync. בעבר, לאובייקטים יתומים היו מטא-נתונים קבועים, ולכן לא הייתה אפשרות לנהל אותם באמצעות לקוחות אחרים או אובייקטים חדשים של RootSync או RepoSync.
נניח שמאגר הבסיס מסונכרן על ידי האובייקט RootSync single-root-sync.
אחרי פיצול המאגר, יש לכם שני מאגרי בסיס. אחד מסונכרן על ידי אובייקט root-sync-1
RootSync והשני מסונכרן על ידי אובייקט root-sync-2 RootSync.
כדי לפצל את המאגר, פועלים לפי השלבים הבאים:
מוודאים של-RootSync
single-root-syncיש ערך הערה שלOrphanאו שהוא לא מוגדר.configsync.gke.io/deletion-propagation-policyערך ברירת המחדל כשלא מוגדר כלום זהה לערך Orphan. ההגדרה הזו מבטיחה שאובייקטים לא יימחקו.מחיקת RootSync
single-root-sync:kubectl delete rootsync single-root-sync -n config-management-systemכדי להגדיר את המאגרים החדשים:
- יוצרים מאגר חדש או ספרייה חדשה במאגר Git הקיים.
- מעבירים את המשאבים למאגר החדש או לספרייה החדשה.
- אם אתם מפצלים את מאגר הבסיס ליותר משני מאגרים, חוזרים על השלבים האלה לפי הצורך.
שומרים ודוחפים את השינוי:
git commit -am 'add configuration for the new root repository'החלת האובייקטים
root-sync-1ו-root-sync-2RootSync. כך מתבצע סנכרון של המאגר או הספרייה החדשים, כך שהאובייקטים הקיימים באשכול מנוהלים על ידי אובייקטי 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 הקיים.
-
ממתינים עד שאובייקט 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.
כדי לפצל את המאגר, פועלים לפי השלבים הבאים:
במאגר הבסיסי הקיים, בוחרים את המשאבים שרוצים להעביר למאגר או לספרייה אחרים ומוסיפים להם את ההערה
configmanagement.gke.io/managed: disabled. ההערה הזו מוודאת שהאובייקטים הקיימים באשכול לא יושפעו כשמעבירים את ההגדרה שלהם ממאגר אחד למאגר אחר. אם אתם משתמשים בפורמט Kustomize או בתרשימי helm, אתם יכולים לבחור בערך מחצית מהבסיסים ולהוסיף את ההערה הנפוצה לקובץkustomization.yaml, כמו בדוגמה הזו:# kustomization.yaml commonAnnotations: configmanagement.gke.io/managed: disabledשומרים ודוחפים את השינוי:
sh git commit -am 'disable Config Sync management on subset of the configuration'מחכים שאובייקט RootSync הקיים
root-syncיסונכרן באמצעות הפקודה הבאה:nomos statusכדי להגדיר את המאגר השני:
- יוצרים מאגר חדש או ספרייה חדשה במאגר Git הקיים.
- מעתיקים את המשאבים עם ההערה
configmanagement.gke.io/managed: disabledלמאגר החדש או לספרייה החדשה. - מסירים את ההערה
configmanagement.gke.io/managed: disabledבמאגר או בספרייה החדשים. - אם אתם מפצלים את מאגר הבסיס ליותר משני מאגרים, חוזרים על השלבים האלה לפי הצורך.
שומרים ודוחפים את השינוי:
git commit -am 'add configuration for the new root repository'מחילים אובייקט
root-sync-1RootSync כדי לסנכרן את המאגר או הספרייה החדשים, כך שהאובייקטים הקיימים באשכול ינוהלו על ידי אובייקטroot-sync-1RootSync חדש.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 הקיים.
-
ממתינים עד שאובייקט RootSync החדש
root-sync-1יסונכרן. אפשר לבדוק את הסטטוס באמצעות הפקודה הבאה:nomos statusמסירים את המשאבים עם ההערה
configmanagement.gke.io/managed: disabledמהמאגר המקורי. שומרים ודוחפים את השינוי:git commit -am 'remove configuration managed by the new root repository'מחכים שאובייקט
root-syncRootSync הקיים יסונכרן באמצעות הפקודה הבאה:nomos status
פיצול מאגר שורש היררכי
השלבים לפיצול מאגר היררכי דומים לשלבים לפיצול מאגר לא מובנה.
יש שלושה הבדלים עיקריים:
גם מאגר הבסיס החדש (או הספרייה החדשה) צריך להיות היררכי. צריך להעתיק את הספריות הקיימות
system/ו-clusterregistry/לספריית הבסיס החדשה (או לספרייה החדשה).המשאבים במרחב שמות לא יכולים להתפזר בכמה מאגרי מידע. אחרת, מנגנוני גישור שונים יתחרו על ניהול מרחב השמות.
אובייקט
root-sync-1RootSync צריך להשתמש ב-spec.sourceFormat: hierarchical.
מכיוון שאנחנו ממליצים על מאגרים לא מובנים, כדאי גם לשקול המרת מאגר הנתונים ההיררכי למאגר לא מובנה לפני שמחלקים אותו.