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

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

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

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

מאגרי Git

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

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

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

בדוגמה הבאה מוצג קובץ RootSync manifest שמסונכרן ממאגר 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 כדי לאכוף מדיניות בסיסית בכל האשכולות בצי. בתרחיש הזה, יכול להיות שתאחסנו את התקנים NetworkPolicies, RoleBindings ו-ResourceQuotas במאגר Git מרכזי בשם standard-configs. כשמוקצה אשכול חדש, סנכרון תצורות מוגדר לסנכרון ממאגר standard-configs, וכך עוזר לוודא שכל האשכולות עומדים בתקנים הארגוניים מההתחלה.

תמונות OCI

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

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

כשמגדירים את סנכרון תצורות עם קובץ אימג' של OCI כמקור האמת,‏ סנכרון תצורות משתמש בקונטיינר oci-sync בתוך ה-Pod של reconciler כדי לשלוף את קובץ האימג' של 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

ההגדרה הזו מגדירה את סנכרון תצורות לסנכרון מקובץ אימג' של 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. לחלופין, אפשר להשתמש ב-Config Sync עם 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.s3ns.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.s3ns.iam.gserviceaccount.com. הוא פורס את משאבי התרשים במרחב השמות my-app-namespace תחת שם הגרסה my-chart-release.

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

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

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

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

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

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

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

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