ארגון קובצי תצורה במקור מידע אמין

בדף הזה מוסבר איך לארגן הגדרות במקור אמת.

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

מידע על קובצי תצורה

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

כש-סנכרון תצורות מנהל את המשאבים האלה, הוא שומר על סנכרון של האשכולות הרשומים באמצעות הגדרות. ההגדרה היא קובץ YAML או JSON במקור האמת. ‫סנכרון תצורות תומך במאגרי Git, בתמונות OCI וב-Helm charts כמקור האמת. ההגדרות מכילות את אותו סוג של פרטי הגדרה שאפשר להחיל על אשכול באופן ידני באמצעות הפקודה kubectl apply. אפשר ליצור קובץ config לכל אובייקט Kubernetes שיכול להיות באשכול. עם זאת, חלק מאובייקטים של Kubernetes, כמו Secrets, מכילים מידע רגיש שאולי לא מתאים לאחסון במקור אמת. כדאי לשקול היטב אם לנהל את סוגי האובייקטים האלה באמצעות סנכרון תצורות.

דרישות ומגבלות

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

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

  • אי אפשר להשתמש ב-Config Sync כדי לנהל ישירות את ClusterRoles מובנים של Kubernetes. ל-GKE יש כמה תפקידים שפונים למשתמשים, כמו cluster-admin,‏ admin,‏ edit ו-view. אי אפשר לנהל את ה-ClusterRole האלה ישירות באמצעות סנכרון תצורות, אחרת סנכרון תצורות יתנגש עם GKE. כדי להוסיף הרשאות ל-ClusterRoles המובנים, צריך להשתמש בצבירת תפקידים כדי לשנות אותם באופן עקיף. כדי לשנות את התפקידים, יוצרים ClusterRole עם שם ייחודי במקור המידע האמין עם ההערות המתאימות.

ארגון מקור המידע האמין

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

מומלץ להגדיר את sourceFormat ל-unstructured כשמגדירים את סנכרון תצורות. סוג המקור המובנה (היררכי) דורש מבנה תיקיות ספציפי מאוד כדי לסנכרן את ההגדרות בצורה נכונה, וברוב המקרים הוא מוסיף מורכבות מיותרת.

ברוב מסמכי התיעוד של Config Sync, כולל בדף הזה, נעשה שימוש בפורמט לא מוּבְנֶה כברירת מחדל, אבל אם צריך, אפשר למצוא מידע על הפורמט ההיררכי במאמר שימוש במאגר היררכי.

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

פריסה מבוססת-סביבה

גישה נפוצה היא לארגן את המאגר לפי סביבה.

├── cluster-essentials/
│   ├── crds/
│   └── namespace.yaml
├── environments/
│   ├── dev/
│   │   ├── backend/
│   │   └── frontend/
│   ├── staging/
│   │   ├── backend/
│   │   └── frontend/
│   └── prod/
│       ├── backend/
│       └── frontend/
└── system/
    └── monitoring/

בדוגמה הזו, מקור האמת מאורגן באופן הבא:

  • ‫cluster-essentials/: מכיל הגדרות שחלות על כל האשכולות, ללא קשר לסביבה. הם עשויים לכלול משאבים כמו הגדרות מותאמות אישית של משאבים (CRD) ומרחבי שמות חיוניים.
  • ‫environments/: ספריית האב של כל ההגדרות הספציפיות לסביבה.
  • ‫system/: מכיל הגדרות לשירותים ברמת המערכת, כמו ניטור.

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

כשמגדירים את סנכרון תצורות בתרחיש הזה, יוצרים כמה אובייקטים בכל אשכול.RootSync לדוגמה, באשכול פיתוח יש RootSync אובייקטים שמסתנכרנים מ-cluster-essentials/, מ-system/ ומ-environments/dev/.

פריסה מבוססת-אשכול

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

├── clusters/
│   ├── cluster-a/
│   │   ├── apps/
│   │   └── networking/
│   ├── cluster-b/
│   │   ├── apps/
│   │   └── networking/
│   └── cluster-c/
│       ├── apps/
│       └── networking/
└── shared/
    ├── roles/
    └── policies/

בדוגמה הזו, מקור האמת מאורגן באופן הבא:

  • ‫clusters/: מכילה ספרייה לכל אשכול שמנוהל.
  • ‫shared/: מכיל הגדרות שמשותפות לכל האשכולות, כמו תפקידי RBAC ומדיניות אבטחה.

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

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

פריסה מבוססת-צוות

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

├── teams/
│   ├── team-alpha/
│   │   ├── app-one/
│   │   └── app-two/
│   ├── team-beta/
│   │   ├── service-a/
│   │   └── service-b/
│   └── team-gamma/
│       ├── data-pipeline/
│       └── dashboard/
└── platform/
    ├── cluster-roles/
    └── storage-classes/

בדוגמה הזו, מקור האמת מאורגן באופן הבא:

  • ‫teams/: מארגן את ההגדרות לפי צוות, כשכל צוות מנהל את ההגדרות של האפליקציה והשירות שלו.
  • ‫platform/: מכיל הגדרות ברמת האשכול שמנוהלות על ידי צוות פלטפורמה מרכזי ומשמשות את כל הצוותים.

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

כשמגדירים את סנכרון תצורות, בתרחיש הזה כל צוות משתמש באובייקט RootSync כדי לסנכרן את ההגדרות. לדוגמה, team-alpha מסנכרן מ-teams/team-alpha/.

אימות קובצי תצורה

אחרי שיוצרים ומארגנים קובצי הגדרות ומוסיפים אותם למקור האמת, משתמשים בפקודה nomos vet --source-format=unstructured כדי לבדוק את התחביר והתוקף של ההגדרות. כך תוכלו להימנע משגיאות במהלך הסנכרון או אחריו.

התעלמות משינויים באובייקטים

אם אתם לא רוצים שסנכרון תצורות ישמור על מצב האובייקט באשכול אחרי שהוא נוצר, מוסיפים את ההערה client.lifecycle.config.k8s.io/mutation: ignore לאובייקט שאתם רוצים שסנכרון תצורות יתעלם משינויים בו.

בדוגמה הבאה אפשר לראות איך מוסיפים את ההערה לאובייקט:

metadata:
  annotations:
    client.lifecycle.config.k8s.io/mutation: ignore

אי אפשר לשנות ידנית את ההערה הזו באובייקטים מנוהלים באשכול.

המרת מאגר היררכי למאגר לא מובנה

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

nomos hydrate PATH

מחליפים את PATH בנתיב לספרייה.

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

פרטים נוספים זמינים במאמר בנושא פקודות של nomos.

אם אתם מעדיפים להמיר את המאגר באופן ידני, צריך לפעול לפי ההוראות הבאות:

  1. מסירים את ההגדרות של Repo בספרייה system/ ממאגר Git. לא צריך את משאב Repo למאגר לא מובנה.

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

  3. העברת מרחב שמות לא נתמכת במאגר לא מובנה. לכן, צריך להצהיר על כל המשאבים שמועברים בירושה במרחבי שמות צאצאים (אלה שנמצאים במקור בספרייה namespaces/).

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