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

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

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

בתרשים הבא מוצגת הארכיטקטורה של Config Sync, כולל הרכיבים והתלויות שלו, גם ב- Google Cloud וגם באשכול GKE:

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

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

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

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

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

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, הפריסה של המאזן נקראת ns-reconciler-REPOSYNC_NAMESPACE.

     הערה: validating webhook אוכף את מגבלת 63 התווים על ידי בדיקת האורך המקסימלי הפוטנציאלי של שם ה-reconciler: ‏ns-reconciler-REPOSYNC_NAMESPACE-REPOSYNC_NAME-REPOSYNC_NAME_LENGTH. המגבלה הזו נאכפת גם אם משתמשים בשם ברירת המחדל של RepoSync.

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

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

שם הפריסה	מרחב השמות של הפריסה	תיאור פריסה	מספר הרפליקות	ביטוי רגולרי של שם Pod	מספר המאגרים	שמות מאגרי התגים
reconciler-manager	config-management-system	מנהל ההתאמה פועל בכל אשכול שבו מופעל סנכרון ההגדרות באובייקט ConfigManagement. הוא עוקב אחרי אובייקטים מסוג RootSync ו-RepoSync ומנהל פריסת התאמה לכל אחד מהם.	1	reconciler-manager-.*	2	reconciler-manager otel-agent
root-reconciler	config-management-system	פריסת Root reconciler נוצרת לכל אובייקט RootSync.	1	root-reconciler-.*	‫3 עד 5^1	reconciler otel-agent git-sync helm-sync oci-sync gcenode-askpass-sidecar hydration-controller
ns-reconciler-.*	config-management-system	פריסת התאמה של מרחב שמות נוצרת לכל אובייקט RepoSync.	1	ns-reconciler-.*	‫3 עד 5^1	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 פועל בכל אשכול שבו מופעל סנכרון ההגדרות באובייקט ConfigManagement. הוא עוקב אחרי אובייקטים מסוג ResourceGroup ומעדכן אותם בסטטוס ההתאמה הנוכחי של כל אובייקט במלאי שלהם. אובייקט ResourceGroup נוצר לכל אובייקט RootSync ו-RepoSync כדי לתעד את רשימת האובייקטים שהוחלו על ידי המנגנון להתאמה ממקור האמת.	1	resource-group-controller-manager-.*	2	manager otel-agent
admission-webhook	config-management-system	ה-Webhook לאימות של סנכרון תצורות פועל בכל אשכול שבו מופעלת מניעת שינויים באובייקט ConfigManagement. הוא עוקב אחרי בקשות ל-API של Kubernetes ומונע שינוי או מחיקה של משאבים שמנוהלים על ידי סנכרון תצורות. ה-webhook של אישור הקבלה של סנכרון תצורות מושבת כברירת מחדל.	2	admission-webhook-.*	1	admission-webhook

‫¹ למידע נוסף על המקרים שבהם המאגרים האלה נוצרים, ראו מאגרי Reconciler.

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

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

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

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

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

רכיבים עיקריים

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

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

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

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

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

מנהל התאמות והתאמות

מנהל ההתאמה אחראי ליצירה ולניהול של ההתאמות הנפרדות שמוודאות שהגדרות האשכול נשארות מסונכרנות.

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

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

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

קונטיינרים של Reconciler

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

שם המאגר	תיאור	מצב
reconciler	מטפל בסנכרון ובתיקון חריגות.	היא תמיד מופעלת.
otel-agent	מקבל מדדים ממכלים אחרים של reconciler ושולח אותם אל OpenTelemetry Collector.	היא תמיד מופעלת.
git-sync	שולף הגדרות מהמאגר ב-Git לספרייה מקומית שקונטיינר ההתאמה יכול לקרוא.	מופעלת כש-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 לספרייה מקומית שקונטיינר ההתאמה יכול לקרוא.	מופעלת כשהמקור כולל קובץ kustomize.yaml.

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

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

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

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

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

שם המאגר	בקשת מעבד (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:

שם המאגר	בקשה ומגבלה של מעבד (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 Controller ו-ResourceGroup

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

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

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

תגובה לפעולה מאתר אחר (webhook) של כניסה

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

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

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

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

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

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

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

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

האובייקט RootSync שנקרא root-sync נוצר על סמך הקלט שלכם ב-API שלGoogle Cloud , ובאופן ספציפי בקטע 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 זמין במאמר הגדרת סנכרון מיותר ממקור מידע מהימן אחד.

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

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