סוגי בקרי Config Connector

‫Config Connector משתמש בארכיטקטורה שכבתית כדי לבצע התאמה בין משאבים בסביבתGoogle Cloud לבין המפרטים של Kubernetes. בקר הורה ברמה העליונה מנתב את התיאום של כל משאב לאחד מארבעה יישומי בקר בסיסיים.

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

סוגי הבקרים הבסיסיים

‫Config Connector משתמש בסוגי הבקרים הבאים:

  • בקרי Direct: הבקר הזה משתמש בספריית Kubernetescontroller-runtime הסטנדרטית ומתקשר עם Google Cloud ממשקי API Google Cloud ישירות באמצעות ערכות ה-SDK הרשמיות של Go. מומלץ להשתמש בבקרי גישה ישירים כשאפשר. לא כל המשאבים תומכים בבקר הישיר. כברירת מחדל, משאבים חדשים משתמשים בבקר הישיר. מתבצעת העברה קבועה של מקורות מידע קיימים. מידע נוסף זמין בהערות המוצר.
  • בקרי Terraform (TF): הבקר הזה פועל כעטיפה (wrapper) לספק Google של Terraform. הבקר מתרגם מפרטים של Kubernetes Resource Model‏ (KRM) למצבים שתואמים ל-Terraform, ומיישם פעולות של Terraform‏ plan ו-apply.
  • בקרי DCL: סוג הבקר הזה משמש כ-wrapper עבורGoogle Cloud ספריית הלקוח ההצהרתית (DCL).
  • בקרי IAM ספציפיים: אלה בקרי התמחות שנועדו במיוחד לניהול משאבים של ניהול זהויות והרשאות גישה (IAM), כולל IAMPolicy,‏ IAMPartialPolicy,‏ IAMPolicyMember ו-IAMAuditConfig. חלק מהמשאבים ב-IAM תומכים בבקר הישיר כאפשרות.

היתרונות של בקרי גישה ישירים

חלק מסוגי המשאבים תומכים בכמה סוגים של בקרי גישה. אם משאב תומך בבקר ישיר, מומלץ להשתמש בבקר ישיר במקום בסוג אחר של בקר, מהסיבות הבאות:

  • צריכת משאבים מופחתת: לבקרי גישה ישירים אין את התקורה של CPU וזיכרון שמשויכת להרצה ולתרגום של מצבים מבוססי Terraform או מבוססי DCL.
  • זמן אחזור משופר של תהליך ההתאמה: בקרי גישה ישירים יכולים לבצע פעולות ישירות בנקודות קצה של Google Cloud , וכך לקצר את הזמן הממוצע שנדרש כדי להגיע לעקביות של מצב המשאב.
  • סטטוס מפורט והבדלים מובְנים: ביומנים של cnrm-controller-manager יש דיווח מובְנה על ההבדלים בין הגרסאות. היומנים האלה מכילים את השינויים המדויקים בשדות שהובילו לשגיאות כמו לולאות של התאמות, ויכולים לעזור לפתור בעיות בקלות רבה יותר.
  • מצב מקורי שנצפה: בקרי בקרה ישירים מאכלסים את status.observedState בסטטוס המשאב, ומספקים תצוגה שקופה בצד השרת של שדות המשאב שמוחזרים ישירות על ידי ממשקי ה-API שלGoogle Cloud .
  • טיפול משופר במחזור החיים: בקרי ישירים כוללים תכונות נוספות כמו מחיקה מסודרת של רשומות יתומות.

בקר ניתוב ראשי

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

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

זיהוי הבקר של משאב

כדי לדעת איזה סוג בקר מוגדר או פעיל עבורGoogle Cloud משאב מסוים, אפשר להשתמש במיפוי קוד פעיל או לבדוק את מבני CustomResourceDefinition ‏ (CRD) ב-Google Kubernetes Engine ‏ (GKE).

כדי לחפש את ההגדרה הסטטית של משאב, בודקים את המשאב ב-GitHub בכתובת pkg/controller/resourceconfig/static_config.go ומחפשים את בלוק ההגדרה של המשאב, כמו בדוגמה הבאה:

{Group: "alloydb.cnrm.cloud.google.com", Kind: "AlloyDBCluster"}: {
    DefaultController:    k8s.ReconcilerTypeTerraform,
    SupportedControllers: []k8s.ReconcilerType{k8s.ReconcilerTypeDirect, k8s.ReconcilerTypeTerraform},
}
  • ‫DefaultController: מציין את הכלי להשוואה שמשמש כברירת מחדל אם לא צוינו כללים לשינוי הקשר ברמת מרחב השמות.
  • ‫SupportedControllers: מציג רשימה של כל אמצעי התיקון שהוטמעו וזמינים למשאב הזה. המתג מחליף את ההגדרות של כלי ההתאמה שמופיעים כאן.

כדי לבדוק תוויות CRD, משתמשים בפקודה kubectl get crd:

kubectl get crd RESOURCE_NAME -o jsonpath='{.metadata.labels}'

מחליפים את RESOURCE_NAME בשם המדויק של ה-CRD של Config Connector, לדוגמה, bigquerydatasets.bigquery.cnrm.cloud.google.com.

בודקים את התוצאות כדי לראות את הפרטים הבאים:

  • ‫cnrm.cloud.google.com/tf2crd: "true": הבקר מבוסס Terraform ‏(TF) מנהל את המשאב.
  • ‫cnrm.cloud.google.com/dcl2crd: "true": המשאב מנוהל על ידי בקר מבוסס DCL.
  • אם התוויות האלה לא מופיעות: הבקר הישיר מנהל את המשאב.

שינוי בקר ברירת המחדל

יש שתי שיטות עיקריות לביטול ברירת המחדל של סוג בקר ב-Config Connector. ההבדל ביניהם קשור בעיקר להיקף הפעולה שלהם, לעלויות התחזוקה ולסדר העדיפויות שלהם במהלך תהליך ההתאמה.

בטבלה הבאה מסוכמים ההבדלים בין שתי הגישות:

תכונה הערה למשאב שינוי מברירת המחדל של ConfigConnectorContext
היקף מופע של משאב יחיד כל המשאבים מסוג מסוים במרחב שמות
קדימות הכי גבוהה (מבטלת את ConfigConnectorContext) בינוני (מבטל את ברירת המחדל הסטטית)
מומלץ? לא כן
מתאים במיוחד ל בדיקות חד-פעמיות השקה לצוות או לפרויקט

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

כדי להריץ מופע משאב ספציפי עם כלי ספציפי לתיקון שגיאות, מוסיפים את ההערה alpha.cnrm.cloud.google.com/reconciler למטא-נתונים של המשאב. למרות שלא מומלץ להשתמש בגישה הזו מהסיבות שצוינו בקטע הקודם, יכול להיות שתצטרכו אותה כדי לבדוק הגדרות של מופע משאב יחיד או כדי לשמור על הגדרות מדור קודם.

apiVersion: bigquery.cnrm.cloud.google.com/v1beta1
kind: BigQueryDataset
metadata:
  name: my-bq-ds
  namespace: NAMESPACE_NAME
  annotations:
    alpha.cnrm.cloud.google.com/reconciler: direct
spec:
  ...

הערכים הנתמכים להערה הם direct,‏ tf או dcl.

ביטול ברירת המחדל של הבקר למרחב שמות

כדי להגדיר שינוי ברירת מחדל ברמת מרחב השמות באמצעות משאב מותאם אישית של ConfigConnectorContext, מבצעים את השלבים הבאים:

  1. שליפת השם והקבוצה מהגדרות המשאב. לדוגמה, עבור המשאב BigQueryDataset, סוג המשאב הוא BigQueryDataset והקבוצה היא bigquery.cnrm.cloud.google.com.

  2. עורכים את אובייקט ConfigConnectorContext במרחב השמות שמכיל את המשאבים המנוהלים:

    kubectl edit configconnectorcontext configconnectorcontext.core.cnrm.cloud.google.com -n NAMESPACE_NAME

    מחליפים את NAMESPACE_NAME במרחב השמות של היעד.

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

    apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: NAMESPACE_NAME
spec:
  googleServiceAccount: "kcc-sa@my-project.iam.gserviceaccount.com"
  experiments:
    controllerOverrides:
      BigQueryDataset.bigquery.cnrm.cloud.google.com: direct

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

מגבלות על החלפת מרחב שמות ותרחישי שימוש

  • דרישת תמיכה מפורשת: כדי שהחלפת ברירת המחדל תצליח, צריך להטמיע את סוג בקר היעד עבור סוג המשאב. כדי לבדוק אם סוג מסוים של בקר נתמך, אפשר לעיין במאמר בנושא זיהוי הבקר של משאב. אם סוג בקר המשאבים שצוין בביטול ברירת המחדל לא נתמך, בקר המשאבים הראשי מתעלם מביטול ברירת המחדל, והכלי להשוואה בין מצבים שמוגדר כברירת המחדל ממשיך לטפל במשאב.
  • מגבלת מרחב שמות: שינויים שנעשים בהגדרות של ConfigConnectorContext חלים על כל המופעים של סוג המשאב שנמצאים במרחב השמות הספציפי הזה. אי אפשר לטרגט מקרים ספציפיים של משאבים באמצעות שינויים שמוגבלים למרחב שמות.
  • בקרת גישה: בדרך כלל, כדי לעדכן אובייקט ConfigConnectorContext צריך הרשאות ברמה גבוהה יותר בצוות הפלטפורמה, בהשוואה לעריכות רגילות של משאבים.
  • החלפת דיווח הסטטוס: אם מצוין ב-ConfigConnectorContext תחליפים סוג בקר לא תקין או לא נתמך, בקר האב מסמן את ההקשר כלא תקין. כדי לבדוק את זה, מריצים את הפקודה kubectl get configconnectorcontext configconnectorcontext.core.cnrm.cloud.google.com -n NAMESPACE_NAME -o yaml ובודקים את השדות .status.healthy ו-.status.errors.
  • מתי כדאי להשתמש בשיטה הזו: זו הגישה המומלצת לביטול של בקרי תנועה. אפשר להשתמש בו כדי להפעיל מרחבי שמות שלמים בבקרי גישה מודרניים (כמו direct) או כדי לאכוף עקביות ארכיטקטונית בפרויקט.