מידע על מקורות מידע אמינים

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

אתם יכולים לסנכרן קובצי תצורה משלושה סוגים של מקורות: מאגרי Git, קובצי אימג' של Open Container Initiative (OCI) ותרשימי Helm. כדי לבחור את האפשרות הכי טובה לסביבה ולתהליך העבודה שלכם, חשוב להבין איך סנכרון תצורות פועל עם כל סוג מקור.

מאגרים של Git

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

כשמגדירים את סנכרון תצורות עם מאגר Git כמקור האמת, סנכרון תצורות משתמש בקונטיינר git-sync בתוך ה-Pod של ההתאמה כדי לשלוף הגדרות ממאגר Git. כדי לשלוט טוב יותר במקום שבו מתבצעת משיכת ההגדרות במאגר Git, אתם יכולים להגדיר את כתובת ה-URL, ההסתעפות והגרסה (commit או תג) של המאגר.

הגדרה לדוגמה של RootSync

בדוגמה הבאה מוצג מניפסט של RootSync שמסתנכרן ממאגר Git:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

ההגדרה הזו מגדירה את סנכרון תצורות לסנכרן מניפסטים ממאגר Git. הכלי "סנכרון הגדרות" עוקב אחרי הספרייה cluster-configs בהסתעפות main של המאגר https://github.com/example/my-configs.git, ובודק אם יש עדכונים כל 60 שניות בלי אימות.

תרחיש לדוגמה: ניהול מרכזי

נניח שאתם אדמינים של פלטפורמה שרוצים להשתמש במאגר Git כדי לאכוף מדיניות בסיסית בכל האשכולות ב-fleet. בתרחיש הזה, אתם יכולים לאחסן את NetworkPolicies, RoleBindings ו-ResourceQuotas הרגילים במאגר Git מרכזי בשם standard-configs. כשמקצים אשכול חדש, סנכרון ההגדרות מוגדר לסנכרון ממאגר standard-configs, כדי להבטיח שכל האשכולות יעמדו בסטנדרטים של הארגון כבר מההתחלה.

תמונות OCI

תמונות OCI הן פורמט סטנדרטי לאריזת אפליקציות והתלויות שלהן. בגישה הזו, ההגדרות נחשבות פריטי מידע שנוצרו בתהליך הפיתוח (Artifact), בדומה לקובצי אימג' של קונטיינרים. הגישה הזו מציעה יתרונות כמו חוסר שינוי וביצועים מהירים יותר בקנה מידה רחב. באמצעות OCI, אתם יכולים להשתמש בתשתית ובכלים של קובצי אימג' של קונטיינרים, כמו Artifact Registry, כדי לנהל את קובצי האימג' שלכם, ובאיחוד זהויות של עומסי עבודה ל-GKE כדי לפשט את האימות.

כדי להשתמש ב-OCI כמקור תצורה, בדרך כלל צריך תהליך נפרד שבו יוצרים את קובצי התצורה כקובץ אימג' של OCI ואז מעבירים אותו בדחיפה לפלטפורמת רישום כמו Artifact Registry. הגישה הזו פחות קריאה לאנשים באופן ישיר מאשר הגדרות אישיות שמאוחסנות כקבצים במאגר Git.

כשמגדירים את סנכרון תצורות עם קובץ אימג' של OCI כמקור האמת, סנכרון תצורות משתמש בקונטיינר oci-sync בתוך ה-Pod של ההתאמה כדי לשלוף את קובץ האימג' של OCI שמכיל את ההגדרות מהמרשם.

הגדרה לדוגמה של RootSync

בדוגמה הבאה מוצג מניפסט של RootSync שמסתנכרן מתמונת OCI שמאוחסנת ב-Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

ההגדרה הזו מגדירה את Config Sync לסנכרון מתמונת OCI. הכלי "סנכרון הגדרות" שולף את קובץ האימג' us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 מ-Artifact Registry באמצעות חשבון שירות של Kubernetes לצורך אימות.

תרחיש לדוגמה: שילוב של צינור עיבוד נתונים של CI/CD

נניח שאתם רוצים לשלב יצירת קובצי אימג' של OCI בצינור עיבוד הנתונים של CI/CD בארגון. כשממזגים שינויים בקובצי תצורה, אפשר להגדיר את צינור עיבוד הנתונים כך שיריץ בדיקות אימות (כמו הפקודה nomos vet), ליצור את קובצי ה-YAML בתמונת OCI ולדחוף את התמונה ל-Artifact Registry. בשלב הזה, סנכרון תצורות יזהה באופן אוטומטי את הגרסה החדשה של קובץ האימג' ויחיל אותה על האשכולות, כדי לוודא שכל השינויים בתצורה יושקו בצורה מאומתת ועם גרסה.

תרשימי Helm

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

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

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

כשמגדירים את סנכרון תצורות עם תרשים Helm כמקור האמין, סנכרון תצורות משתמש בקונטיינר helm-sync בתוך Pod של התאמה כדי לשלוף תרשימים ממאגר Helm (כמו Artifact Registry) או ממאגר Git, ואז מעבד את התרשים כדי ליצור מניפסטים של Kubernetes. לחלופין, אתם יכולים להשתמש ב-סנכרון תצורות עם Kustomize כדי ליצור תרשימי Helm. מידע נוסף על הגישה הזו זמין במאמר שימוש בסנכרון הגדרות עם Kustomize ו-Helm.

הגדרה לדוגמה של RootSync

בדוגמה הבאה מוצג מניפסט של RootSync שמסתנכרן מתרשים Helm שמאוחסן ב-Artifact Registry:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

ההגדרה הזו מגדירה את סנכרון תצורות לסנכרן תרשים Helm ממאגר OCI. ‫סנכרון תצורות מאחזר את גרסה 1.2.0 של תרשים my-chart מהמאגר oci://us-central1-docker.pkg.dev/my-project/my-helm-repo, ומאמת באמצעות חשבון השירות my-service-account@my-project.iam.gserviceaccount.com. הפקודה פורסת את המשאבים של התרשים במרחב השמות my-app-namespace, תחת שם הגרסה my-chart-release.

תרחיש לדוגמה: פריסת אפליקציה של צד שלישי

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

בחירת סוג המקור

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

תכונה מאגר Git תמונת OCI תרשים Helm
למי זה מתאים ניהול הגדרות למטרות כלליות, גמישות, קריא לאנשים הגדרות קבועות עם גרסאות, תוך שימוש בתשתית של קונטיינרים אריזה והפצה של אפליקציות מורכבות
יכולת שינוי ניתן לשינוי לא ניתן לשינוי ניתן לשינוי (גרסאות התרשים לא ניתנות לשינוי, אבל הערכים יכולים להשתנות)
חזרה לגרסה קודמת ביטול של פקודות commit או שינוי של הסתעפויות פריסת תג תמונה קודם חזרה לגרסה קודמת של תרשים
כלים לקוחות Git רגילים, צינורות עיבוד נתונים של CI/CD ‫Docker או Podman, מאגרי קונטיינרים ‫Helm CLI, מאגרי Helm
ביצועים יכול להיות איטי יותר במאגרים גדולים מהיר יותר, במיוחד בקנה מידה גדול מהיר כשמאחזרים ממאגר תרשימים
אימות גמיש (SSH, טוקן), יכול להיות מורכב יותר להגדרה פשוט יותר עם איחוד זהויות של עומסי עבודה ל-GKE (לדוגמה, עם Artifact Registry) פשוט יותר עם איחוד זהויות של עומסי עבודה ל-GKE (לדוגמה, עם Artifact Registry)

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

  • ‫RootSync שמסתנכרן ממאגר Git שמכיל משאבים וכללי מדיניות בסיסיים ברמת האשכול, שמנוהלים על ידי צוות הפלטפורמה.
  • ‫RepoSync במרחב שמות ספציפי שמסתנכרן מתרשים Helm כדי לפרוס מכונה של Redis שמנוהלת על ידי צוות האפליקציה.
  • ‫RepoSync אחר במרחב שמות אחר שמסתנכרן מתמונת OCI שמכילה קבוצה של הגדרות ספציפיות לאפליקציה, שנוצרו בתהליך CI/CD נפרד.

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