שיטות מומלצות לשימוש ב-Config Connector

בדף הזה מוסברות שיטות מומלצות שכדאי להשתמש בהן כשמשתמשים ב-Config Connector.

ניהול מגבלות המכסה של API

אם נתקלתם בשגיאות שמציינות שחרגתם ממגבלת המכסה של ה-API, יכול להיות שיצרתם יותר מדי משאבי Config Connector עם אותו סוג אובייקט, למשל deployment, באותו פרויקט מכסה. כשיוצרים הרבה משאבים, המשאבים האלה יכולים ליצור יותר מדי בקשות API לאותה נקודת קצה ל-API בגלל אסטרטגיית ההתאמה שבה משתמש Config Connector.

אחת הדרכים לפתור את הבעיה היא לבקש להגדיל את המכסה. בנוסף להגדלת המכסה, אם אישרתם ששגיאת המכסה נגרמת כתוצאה מבקשות GET שמופנות אל Google Cloud המשאבים שמנוהלים על ידי משאבי Config Connector, תוכלו לשקול אחת מהאפשרויות הבאות:

הגדלת מרווח ההתאמה

אתם יכולים להגדיל את הזמן בין פעולות ההתאמה של משאב ב-Config Connector כדי להימנע מחריגה ממכסות ה-API. ההמלצה היא להגדיר את מרווח הזמן של ההתאמה לשעה אחת.

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

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

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

כדי לפצל משאבים קיימים של Config Connector לפרויקטים שונים, מבצעים את השלבים הבאים:

  1. קובעים אילו משאבי Config Connector מתכננים להעביר לפרויקטים אחרים.
  2. מחיקת המשאבים של Config Connector. מוודאים שההערה cnrm.cloud.google.com/deletion-policy לא מוגדרת ל-abandon.
  3. מעדכנים את השדה spec.projectRef או את ההערה cnrm.cloud.google.com/project-id בהגדרת ה-YAML של משאבי Config Connector שרוצים להעביר לפרויקטים החדשים.
  4. נותנים לחשבון השירות ב-IAM שמשמש את Config Connector את ההרשאות המתאימות בפרויקטים החדשים.
  5. מחילים את הגדרת ה-YAML המעודכנת כדי ליצור את משאבי Config Connector.

מעבר למצב עם מרחבי שמות

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

  1. הגדרת Config Connector להפעלה במצב של מרחב שמות. יוצרים חשבונות שירות חדשים של IAM מפרויקטים שונים ומקשרים אותם למרחבי שמות שונים לפי ההוראות להגדרת Config Connector לכל פרויקט.

  2. מעניקים לחשבונות השירות החדשים ב-IAM את ההרשאות המתאימות בפרויקט שמכיל את המשאבים.

  3. קובעים אילו משאבים של Config Connector מתכננים להעביר למרחבי שמות שונים.

  4. מעדכנים את הגדרות ה-YAML של משאבי Config Connector ומגדירים את ההערה cnrm.cloud.google.com/deletion-policy abandon.

  5. מחילים את הגדרת ה-YAML המעודכנת כדי לעדכן את המדיניות בנושא מחיקת נתונים של משאבי Config Connector.

  6. ביטול השימוש במשאבי Config Connector.

  7. מעדכנים את השדה metadata.namespace בהגדרת ה-YAML של משאבי Config Connector שרוצים להעביר למרחבי השמות השונים.

  8. מחילים את הגדרות ה-YAML המעודכנות כדי להשיג את המשאבים הנטושים.

ניהול מאגרי צמתים באשכולות GKE

יכול להיות שתיתקלו בשגיאות כשתיצרו אשכול על ידי החלת משאב ContainerCluster ב-Config Connector, ואז תנסו לעדכן את nodeConfig או שדות אחרים שקשורים לצומת על ידי החלת הגדרה מעודכנת של ContainerCluster. השגיאות האלה נובעות משדות שלא ניתן לשנות, כמו nodeConfig, nodeConfig.labels, nodeConfig.taint, וזו מגבלה טכנית של Google Cloud API הבסיסי.

אם אתם צריכים לעדכן את השדות האלה, אתם יכולים להשתמש במשאב ContainerNodePool כדי לנהל מאגרי צמתים שבהם השדות האלה לא קבועים. כדי לנהל מאגרי צמתים באמצעות המשאב ContainerNodePool, צריך לציין הערה cnrm.cloud.google.com/remove-default-node-pool: "true". ההערה הזו מסירה את מאגר הצמתים שמוגדר כברירת מחדל ונוצר במהלך יצירת האשכול. לאחר מכן, כדי ליצור מאגרי צמתים נפרדים, מציינים שדות nodeConfig ב-ContainerNodePool במקום ב-ContainerCluster. אפשר לעיין בContainerNodePoolדוגמה למשאב.

צריך להגדיר את ההערה cnrm.cloud.google.com/state-into-spec: absent גם למשאב ContainerCluster וגם למשאב ContainerNodePool. ההערה הזו מונעת שגיאות פוטנציאליות של התאמה במהלך האינטראקציה בין בקר Config Connector לבין ממשקי ה-API הבסיסיים.

בדוגמאות הבאות מוצגת הגדרה של ContainerCluster ושל ContainerNodePool עם ההערות האלה:

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  name: containercluster-sample
  annotations:
    cnrm.cloud.google.com/remove-default-node-pool: "true"
    cnrm.cloud.google.com/state-into-spec: absent
spec:
  description: A sample cluster.
  location: us-west1
  initialNodeCount: 1

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerNodePool
metadata:
  labels:
    label-one: "value-one"
  name: containernodepool-sample
  annotations:
    cnrm.cloud.google.com/state-into-spec: absent
spec:
  location: us-west1
  autoscaling:
    minNodeCount: 1
    maxNodeCount: 3
  nodeConfig:
    machineType: n1-standard-1
    preemptible: false
    oauthScopes:
      - "https://www.googleapis.com/auth/logging.write"
      - "https://www.googleapis.com/auth/monitoring"
  clusterRef:
    name: containercluster-sample