ארכיטקטורה של סנכרון תצורות

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

בקטע הבא מוצגת הארכיטקטורה של סנכרון תצורות, כולל הרכיבים והתלות שלה, גם ב- Google Cloud וגם באשכול GKE:

תרשים שמציג את הקשר בין אובייקטים ומשאבים של Config Sync

‫Fleet service מנהל את רכיבי סנכרון תצורות באשכול ישירות, ללא ConfigManagement Operator מדור קודם או אובייקט ConfigManagement. צריך לשדרג את סנכרון תצורות באופן ידני לפי הצורך.

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

  1. הפעלת סנכרון תצורות באשכול מוסיפה את הרכיבים הבאים:

    • ConfigSync הגדרת משאב בהתאמה אישית (CRD)
    • אובייקט ConfigSync בשם config-sync.
    • הכלי Reconciler Manager בפריסה בשם reconciler-manager.
    • ה-ResourceGroup Controller בפריסה בשם resource-group-controller-manager.
    • ‫OpenTelemetry Collector בפריסה בשם otel-collector.
    • אופציונלי: ה-webhook של סנכרון תצורות admission בפריסה בשם admission-webhook. ה-webhook של סנכרון תצורות admission מותקן רק אם מפעילים את מניעת הסחף.

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

  2. יצירת אובייקטים של RootSync ו-RepoSync מוסיפה את הרכיבים הבאים:

    • לכל אובייקט RootSync, פריסת כלי הגישור נקראת root-reconciler-ROOTSYNC_NAME. עבור אובייקט RootSync בשם root-sync, פריסת ה-reconciler נקראת root-reconciler.

    • לכל אובייקט RepoSync, פריסת כלי הגישור נקראת ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. עבור אובייקט RepoSync בשם repo-sync, פריסת ה-reconciler נקראת ns-reconciler-REPOSYNC_NAMESPACE.

פריסות, Pods וקונטיינרים של סנכרון תצורות

בטבלה הבאה מפורט מידע נוסף על ה-Deployment (פריסה), ה-Pods והקונטיינרים של סנכרון תצורות:

שם הפריסה מרחב השמות של הפריסה תיאור פריסה מספר העותקים ביטוי רגולרי של שם ה-Pod מספר מאגרי התגים שמות של מאגרי תגים
reconciler-manager config-management-system הכלי Reconciler Manager פועל בכל אשכול שבו מופעל סנכרון תצורות באובייקט ConfigManagement. הוא עוקב אחרי אובייקטים של RootSync ושל RepoSync ומנהל פריסת reconciler לכל אחד מהם. 1 reconciler-manager-.* 2
  • reconciler-manager
  • otel-agent
    		•
    root-reconciler config-management-system פריסת מאחד (reconciler) ברמת הבסיס נוצרת לכל אובייקט RootSync. 1 root-reconciler-.* ‫3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    ns-reconciler-.* config-management-system פריסת namespace reconciler נוצרת לכל אובייקט RepoSync. 1 ns-reconciler-.* ‫3 - 51
  • reconciler
  • otel-agent
  • git-sync
  • helm-sync
  • oci-sync
  • gcenode-askpass-sidecar
  • hydration-controller
    		•
    otel-collector config-management-monitoring ‫OpenTelemetry Collector פועל בכל אשכול שמופעל בו סנכרון תצורות באובייקט ConfigManagement. הוא אוסף מדדים מרכיבי סנכרון תצורות שפועלים במרחבי השמות config-management-system ו-resource-group-system, ומייצא את המדדים האלה אל Prometheus ו-Cloud Monitoring. 1 otel-collector-.* 1
  • otel-collector
    		•
    resource-group-controller-manager resource-group-system ה-ResourceGroup Controller פועל בכל אשכול שבו מופעל סנכרון תצורות באובייקט ConfigManagement. הוא עוקב אחרי אובייקטים ResourceGroup ומעדכן אותם בסטטוס ההתאמה הנוכחי של כל אובייקט במלאי. נוצר אובייקט ResourceGroup לכל אובייקט RootSync וRepoSync כדי ליצור מלאי של רשימת האובייקטים שהוחלו על ידי הכלי לאיחוד נתונים ממקור האמת. 1 resource-group-controller-manager-.* 2
  • manager
  • otel-agent
    		•
    admission-webhook config-management-system ה-Webhook של סנכרון תצורות Admission פועל בכל אשכול שבו מופעלת מניעת סחף באובייקט ConfigManagement. הוא עוקב אחרי בקשות ל-Kubernetes API ומונע שינוי או מחיקה של משאבים שמנוהלים על ידי סנכרון תצורות. תגובה לפעולה מאתר אחר (webhook) של סנכרון תצורות admission מושבתת כברירת מחדל. 2 admission-webhook-.* 1
  • admission-webhook
    		•

    1 פרטים על המועד שבו נוצרים מאגרי התגים האלה מופיעים במאמר בנושא מאגרי תגים של Reconciler.

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

    בטבלה הבאה מפורטים דרישות המשאבים של Kubernetes לרכיבי סנכרון תצורות. מידע נוסף זמין במאמר ניהול משאבים עבור Pods וקונטיינרים במאמרי העזרה של Kubernetes.

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

    שם הפריסה בקשת מעבד (m) לכל רפליקה בקשת זיכרון (Mi) לכל רפליקה
    config-management-operator 100 200
    resource-group-controller-manager 110 300
    admission-webhook1 10 100
    otel-collector 200 400
    reconciler-manager 20 150
    reconciler (אחד לכל RootSync ו-RepoSync) פרטים נוספים זמינים במאמר בנושא בקשות למשאבי מאזן.

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

    רכיבים מרכזיים

    בקטעים הבאים נרחיב על רכיבים חשובים של סנכרון תצורות.

    שירות Fleet ואובייקט ConfigSync

    שירות Hub Fleet מנהל את רכיבי סנכרון תצורות באשכול:

    ניהול סנכרון תצורות

    שירות Fleet מנהל גם את אובייקט ConfigSync באשכול. שירות Fleet מעדכן את המפרט של אובייקט ConfigSync על סמך הקלט שלכם ל-API של Google Cloud , ואת הסטטוס שלו כדי לשקף את הסטטוס של רכיבי סנכרון תצורות.

    כדי לבצע שינויים בהגדרת ההתקנה של סנכרון תצורות, צריך להשתמש ב- Google Cloud API. אבל אפשר להשתמש ב- Google CloudAPI או ב-Kubernetes API כדי לעקוב אחרי ההגדרה והתקינות של ההתקנה של סנכרון תצורות.

    Reconciler Manager ו-reconcilers

    ה-Reconciler Manager אחראי ליצירה ולניהול של רכיבי ה-reconciler האישיים שמוודאים שהגדרת האשכול תישאר מסונכרנת.

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

    הכלי להשוואה בין מצבים (reconciler) ברמת הבסיס (root) ובמרחב השמות (namespace) מאחזר באופן אוטומטי הגדרות ממקור האמת שלכם ומחיל אותן כדי לאכוף את המצב שאתם רוצים באשכול.

    בתרשימים הבאים מוצג איך Reconciler Manager שולט במחזור החיים של כל reconciler של שורש ושל מרחב שמות:

    דיאגרמה שמראה איך Reconciler Manager שולט ב-root reconciler דיאגרמה שמראה איך מנהל ה-Reconciler שולט ב-Reconciler של מרחב השמות

    מאגרי Reconciler

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

    שם הקונטיינר תיאור מצב
    reconciler מטפל בסנכרון ובתיקון של סטיות. היא תמיד מופעלת.
    otel-agent מקבלת מדדים ממכלי ה-reconciler האחרים ושולחת אותם אל OpenTelemetry Collector. היא תמיד מופעלת.
    git-sync שולף הגדרות ממאגר Git לספרייה מקומית שקונטיינר ה-reconciler יכול לקרוא. מופעלת כש-spec.sourceType הוא git.
    helm-sync שולף תרשימי Helm ממאגר התרשימים ומעבד אותם לספרייה מקומית שהקונטיינר של הכלי להשוואה יכול לקרוא. מופעלת כש-spec.sourceType הוא helm.
    oci-sync שולף תמונות OCI שמכילות את ההגדרות שלכם מ-Container Registry לספרייה מקומית שהקונטיינר של הכלי להשוואה יכול לקרוא. מופעלת כש-spec.sourceType הוא oci.
    gcenode-askpass-sidecar שומר במטמון את פרטי הכניסה של Git משירות המטא-נתונים של GKE לשימוש על ידי מאגר git-sync. מופעלת כש-spec.sourceType הוא git וגם spec.git.auth הוא gcenode או gcpserviceaccount.
    hydration-controller הכלי מטפל ביצירת הגדרות Kustomize בספרייה מקומית שקונטיינר ה-reconciler יכול לקרוא. מופעלת כשהמקור כולל קובץ kustomize.yaml.

    כפי שמוצג בטבלה הקודמת, בדרך כלל אפשר לצפות למספר מאגרי תגים של שלוש עד חמש בכל Pod של מאחד. המאגרים reconciler ו-otel-agent תמיד קיימים. הגדרת סוג למקור המידע האמין קובעת איזה מאגר תגים לסנכרון יתווסף. בנוסף, מאגרי התגים hydration-controller ו-gcenode-askpass-sidecar נוצרים אם ביצעתם את שינויי ההגדרה שמוזכרים בטבלה.

    בקשות למשאבי Reconciler

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

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

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

    שם הקונטיינר בקשת CPU‏ (m) בקשת זיכרון (Mi)
    reconciler 50 200
    otel-agent 10 100
    hydration-controller (אופציונלי) 10 100
    git-sync 10 16
    gcenode-askpass-sidecar (אופציונלי) 10 20
    helm-sync 75 128
    oci-sync 25 32

    בטבלה הבאה מפורטות בקשות המשאבים עבור אשכולות Autopilot:

    שם הקונטיינר בקשה ומגבלה של CPU‏ (m) בקשת זיכרון ומגבלה (Mi)
    reconciler 700 512
    otel-agent 10 64
    hydration-controller (אופציונלי) 200 256
    git-sync 20 32
    gcenode-askpass-sidecar (אופציונלי) 50 64
    helm-sync 250 384
    oci-sync 50 64

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

    גרסאות משולבות של Helm ו-Kustomize

    ‫סנכרון תצורות משתמש בקובצי הפעלה של Helm ו-Kustomize כדי לעבד הגדרות. כדי למצוא את הגרסאות של Helm ו-Kustomize שכלולות בגרסה של סנכרון תצורות, אפשר לעיין בשדות HELM_VERSION ו-KUSTOMIZE_VERSION בMakefile של מאגר הקוד הפתוח של סנכרון תצורות. אתם יכולים לעבור בין הסתעפויות ב-GitHub כדי לראות את הגרסאות של מהדורות שונות של סנכרון תצורות.

    מידע על עיבוד Helm באמצעות Kustomize זמין במאמר הגדרת Kubernetes באמצעות Kustomize. מידע על השימוש ב-Helm API זמין במאמר סנכרון תרשימי Helm מ-Artifact Registry.

    אובייקטים של ResourceGroup ו-ResourceGroup Controller

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

    לאובייקטים מסוג ResourceGroup יש את אותו שם ואותו מרחב שמות כמו לאובייקט התואם מסוג RootSync או RepoSync. לדוגמה, לאובייקט RootSync עם השם root-sync במרחב השמות config-management-system, האובייקט התואם ResourceGroup נקרא גם root-sync במרחב השמות config-management-system.

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

    Webhook של כניסה

    התגובה לפעולה מאתר אחר (webhook) של Config Sync Admission נוצרת כשמפעילים את מניעת סטיות. מניעת סחף מונעת באופן יזום בקשות לשינוי, כדי לוודא שהן תואמות למקור האמת לפני שהשינויים מותרים.

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

    אובייקטים של RootSync ו-RepoSync

    אובייקטים מסוג RootSync מגדירים את סנכרון תצורות ליצירת reconciler בסיסי שעוקב אחרי מקור האמת שצוין ומחיל אובייקטים מהמקור הזה על האשכול. כברירת מחדל, למנגנון ה-reconciler הבסיסי של כל אובייקט RootSync יש הרשאת cluster-admin. עם הרשאת ברירת המחדל הזו, אפשר לסנכרן בין משאבים בהיקף אשכול ובין משאבים בהיקף מרחב שמות. במקרה הצורך, אפשר לשנות את ההרשאות האלה על ידי הגדרת השדות spec.override.roleRefs. אובייקטים של RootSync מיועדים לשימוש של אדמינים של אשכולות.

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

    איך שירות Fleet מנהל אובייקטים של RootSync

    כשמתקינים את סנכרון תצורות באמצעות מסוף Google Cloud , Google Cloud CLI,‏ Config Connector או Terraform,‏ סנכרון תצורות מנוהל על ידי שירות Fleet, על סמך הקלט שלכם ב- Google Cloud API.

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

    אובייקט RootSync בשם root-sync נוצר על סמך הקלט שלכם ב-Google Cloud API, במיוחד בקטע spec.configSync שלconfig-management apply API. ממשק ה-API הזה חושף רק קבוצת משנה של שדות RootSync, ולכן השדות האלה נחשבים כמנוהלים ב-root-sync, בעוד שהשדות האחרים נחשבים כלא מנוהלים. אפשר לערוך שדות מנוהלים רק באמצעותGoogle Cloud API. אפשר לערוך את השדות הלא מנוהלים באמצעות kubectl או כל לקוח אחר של Kubernetes.

    אובייקטים נוספים של RootSync ו-RepoSync

    כדי ליצור עוד אובייקטים מסוג RootSync או RepoSync, אפשר להשתמש בכלי שורת הפקודה kubectl או בלקוח Kubernetes אחר. אפשר גם להשתמש באובייקט root-sync הראשוני כדי לנהל אובייקטים נוספים מסוג RootSync או RepoSync באמצעות GitOps. לשם כך, מוסיפים את מניפסט ה-YAML שלהם למקור האמת שממנו מוגדר אובייקט root-sync לסנכרן. אי אפשר להשתמש בשיטה הזו כדי לנהל את ההגדרות של root-sync הראשוני, כי חלק מהשדות שלו מנוהלים על ידי שירות Fleet. כדי לנהל את האובייקט root-sync באמצעות GitOps, אפשר להשתמש ב-Config Connector או ב-Terraform. מידע נוסף על יצירת אובייקטים נוספים של RootSync ושל RepoSync זמין במאמר הגדרת סנכרון מכמה מקורות אמת.

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