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

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

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

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

‫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 ב-Deployment בשם 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.

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

בטבלה הבאה מפורט מידע נוסף על ה-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 של הגישה מושבת כברירת מחדל.

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

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

    שירות ניהול צי רכבים ואובייקט ConfigSync

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

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

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

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

    מנהל התאמות ומבצעי התאמות

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

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

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

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

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

    מאגרי Reconciler

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

    שם הקונטיינר תיאור מצב
    reconciler מטפל בסנכרון ובתיקון סטיות. היא תמיד מופעלת.
    otel-agent מקבלת מדדים מהקונטיינרים האחרים של תהליך ההתאמה ושולחת אותם אל 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 עצמאית לטיפול בסנכרון. פריסת ה-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 גרסת Kustomize
    1.22.0 v3.15.3 v5.3.0
    1.21.0 v3.15.3 v5.3.0
    1.20.0 v3.15.3 v5.3.0

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

    אובייקטים של ResourceGroup ובקר ResourceGroup

    הכלי להשוואת נתונים של מרחב השמות והכלי להשוואת נתונים של שורש יוצרים אובייקט מלאי ResourceGroup לכל אובייקט RootSync וRepoSync שהגדרתם. כל אובייקט ResourceGroup מכיל רשימה של אובייקטים שסונכרנו עם האשכול ממקור האמת על ידי רכיב ה-reconciler של אותו אובייקט 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 נוצר כשמפעילים את מניעת סטיות. מניעת סחף (Drift) מונעת שינויים באופן יזום בבקשות לשינוי, כדי לוודא שהן תואמות למקור האמת לפני שהשינויים מבוצעים.

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

    אובייקטים של 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 זמין במאמר הגדרת סנכרון מכמה מקורות אמת.

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