התקנה ידנית של Config Connector

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

ההוראות בדף הזה מתמקדות בהתקנה של Config Connector באשכולות של Google Kubernetes Engine ‏ (GKE). למידע נוסף על אפשרויות ההתקנה השונות, ראו בחירת סוג התקנה.

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

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

לפני שמתחילים

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

• יוצרים או מזהים אשכול GKE שעדיין לא הותקן בו Config Connector, ושמופעלים בו Workload Identity ו-Kubernetes Engine Monitoring.
• מגדירים את kubectl כך שיתחבר לאשכול.

התקנת האופרטור של Config Connector

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

כדי להתקין את האופרטור של Config Connector:

1. מורידים את קובץ ה-‎ .tar העדכני של מפעיל Config Connector:

   gcloud storage cp gs://configconnector-operator/latest/release-bundle.tar.gz release-bundle.tar.gz
   

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

2. מחלצים את קובץ ה-tar:

   tar zxvf release-bundle.tar.gz
   

3. מתקינים את האופרטור של Config Connector באשכול:

   טייס אוטומטי

   kubectl apply -f operator-system/autopilot-configconnector-operator.yaml
   

   רגילה

   kubectl apply -f operator-system/configconnector-operator.yaml
   

4. כדי להגדיר את המפעיל של Config Connector כך שיפעל במצב מרחב שמות, מבצעים את השלבים הבאים:

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

      apiVersion: core.cnrm.cloud.google.com/v1beta1
      kind: ConfigConnector
      metadata:
        # the name is restricted to ensure that there is only ConfigConnector resource installed in your cluster
        name: configconnector.core.cnrm.cloud.google.com
      spec:
        mode: namespaced
        stateIntoSpec: Absent
      

   2. מחילים את המניפסט על האשכול:

      kubectl apply -f configconnector.yaml
      

התקנת Config Connector במצב מרחב שמות

הערה: צריך לבצע את השלבים האלה בכל מרחב שמות שרוצים ש-Config Connector ייצור ממנו משאבים.

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

יצירת מרחב שמות

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

kubectl create namespace NAMESPACE

מחליפים את NAMESPACE בשם של מרחב השמות.

יצירת זהות

כדי ליצור חשבון שירות ב-IAM ולקשר בין חשבון השירות ב-IAM לבין חשבון השירות של Config Connector ב-Kubernetes:

1. יוצרים חשבון שירות ב-IAM. אם יש לכם חשבון שירות קיים, אתם יכולים להשתמש בו במקום ליצור חשבון שירות חדש. משתמשים ב-gcloud כדי ליצור את חשבון השירות באמצעות הפקודה הבאה:

   gcloud iam service-accounts create NAMESPACE_GSA --project HOST_PROJECT_ID
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫NAMESPACE_GSA בשם של חשבון השירות של Google ‏ (GSA) שקשור למרחב השמות.
   • ‫HOST_PROJECT_ID במזהה הפרויקט המארח.

   למידע נוסף על יצירת חשבונות שירות, קראו את המאמר יצירה וניהול של חשבונות שירות.

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

   gcloud projects add-iam-policy-binding MANAGED_PROJECT_ID \
       --member="serviceAccount:NAMESPACE_GSA@HOST_PROJECT_ID.iam.gserviceaccount.com" \
       --role="roles/owner"
   

   מחליפים את MANAGED_PROJECT_ID במזהה הפרויקט המנוהל.

   הערה: אם אתם מעדיפים לתת גישת עריכה לפרויקט, החליפו את roles/owner ב-roles/editor. הקצאת תפקיד העריכה מאפשרת את רוב הפונקציונליות של Config Connector, למעט הגדרות ברמת הפרויקט או הארגון, כמו שינויים ב-IAM.

3. יוצרים קישור למדיניות IAM בין חשבון השירות ב-IAM לבין חשבון השירות של Config Connector ב-Kubernetes:

   gcloud iam service-accounts add-iam-policy-binding \
       NAMESPACE_GSA@HOST_PROJECT_ID.iam.gserviceaccount.com \
       --member="serviceAccount:HOST_PROJECT_ID.svc.id.goog[cnrm-system/cnrm-controller-manager-NAMESPACE]" \
       --role="roles/iam.workloadIdentityUser"
   

4. נותנים לחשבון השירות ב-IAM הרשאות לפרסם מדדי Prometheus ב-Google Cloud Observability בפרויקט המארח:

   gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
       --member="serviceAccount:NAMESPACE_GSA@HOST_PROJECT_ID.iam.gserviceaccount.com" \
       --role="roles/monitoring.metricWriter"
   

יצירת ConfigConnectorContext

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

כדי ליצור ConfigConnectorContext:

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

   apiVersion: core.cnrm.cloud.google.com/v1beta1
   kind: ConfigConnectorContext
   metadata:
     # you need one ConfigConnectorContext per namespace
     name: configconnectorcontext.core.cnrm.cloud.google.com
     namespace: NAMESPACE
   spec:
     googleServiceAccount: "NAMESPACE_GSA@HOST_PROJECT_ID.iam.gserviceaccount.com"
     stateIntoSpec: Absent
   

2. מחילים את המניפסט על האשכול:

   kubectl apply -f configconnectorcontext.yaml
   

3. כדי לוודא שהאופרטור של Config Connector יצר חשבון שירות של Kubernetes למרחב השמות, מריצים את הפקודה הבאה:

   kubectl get serviceaccount/cnrm-controller-manager-NAMESPACE  -n cnrm-system
   

4. מוודאים שה-Pod של בקר Config Connector פועל במרחב השמות:

   kubectl wait -n cnrm-system \
       --for=condition=Ready pod \
       -l cnrm.cloud.google.com/component=cnrm-controller-manager \
       -l cnrm.cloud.google.com/scoped-namespace=NAMESPACE
   

   אם הבקר של Config Connector פועל, הפלט דומה לזה:

   cnrm-controller-manager-abcdefghijk-0 condition met.
   

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

אם אתם רוצים ש-Config Connector יפסיק לנהל משאבים במרחב שמות, הסירו את כל המשאבים של Config Connector ואת האובייקט ConfigConnectorContext במרחב השמות הזה.

1. כדי למצוא את כל המשאבים של Config Connector במרחב השמות, צריך להציג את כל המשאבים לכל הגדרה של משאב בהתאמה אישית של Config Connector.

   kubectl get gcp -n NAMESPACE
   

   הפלט של הפקודה הזו מציג את כל הגדרות המשאבים בהתאמה אישית (CRD) שמייצגות משאב שמנוהל על ידי Config Connector במרחב השמות הזה, כולל השם והסוג של המשאב ב-Kubernetes.

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

   kubectl delete -n NAMESPACE KIND NAME
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KIND: סוג המשאב ב-Kubernetes.
   • ‫NAME: שם המשאב.

3. מוחקים את האובייקט ConfigConnectorContext במרחב השמות.

   kubectl delete -n NAMESPACE ConfigConnectorContext configconnectorcontext.core.cnrm.cloud.google.com
   

   חשוב: אל תמחקו את האובייקט ConfigConnectorContext עד שכל המשאבים שמנוהלים על ידי Config Connector יימחקו.

הסרת Config Connector

כדי להסיר את Config Connector, מבצעים את השלבים הבאים:

1. כדי להסיר את רכיבי ה-CRD והבקר של Config Connector, מריצים את הפקודה הבאה:

   kubectl delete ConfigConnectorContext --all -A –wait=false
   
   kubectl delete ConfigConnector configconnector.core.cnrm.cloud.google.com \
       --wait=true
   

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

   kubectl delete -f operator-system/configconnector-operator.yaml  --wait=true
   

התקנה במצב אשכול

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

יצירת זהות

כדי ליצור ולנהל משאבי Google Cloud , Config Connector מבצע אימות באמצעות חשבון שירות של ניהול זהויות והרשאות גישה (IAM) ומשתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי לקשר בין חשבונות שירות של IAM לחשבונות שירות של Kubernetes.

הערה: צריך לבצע את השלבים האלה רק פעם אחת לכל אשכול.

כדי ליצור את הזהות:

1. יוצרים חשבון שירות ב-IAM. אם אתם רוצים להשתמש בחשבון שירות קיים, אתם יכולים להשתמש בו ולדלג על השלב הזה:

   gcloud iam service-accounts create SERVICE_ACCOUNT_NAME
   

   מחליפים את הערך SERVICE_ACCOUNT_NAME בשם שרוצים לתת לחשבון השירות.

   למידע נוסף על יצירת חשבונות שירות, קראו את המאמר יצירה וניהול של חשבונות שירות.

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

   gcloud projects add-iam-policy-binding PROJECT_ID \
     --member="serviceAccount:SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com" \
     --role="roles/editor"
   

   מחליפים את PROJECT_ID במזהה הפרויקט.

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

3. יוצרים קישור מדיניות IAM בין חשבון השירות ב-IAM לבין חשבון השירות המוגדר מראש ב-Kubernetes שבו פועל Config Connector:

   gcloud iam service-accounts add-iam-policy-binding \
   SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
     --member="serviceAccount:PROJECT_ID.svc.id.goog[cnrm-system/cnrm-controller-manager]" \
     --role="roles/iam.workloadIdentityUser"
   

הגדרת Config Connector

כדי להשלים את ההתקנה, יוצרים קובץ תצורה ל-ConfigConnector CustomResource, ואז מחילים אותו באמצעות הפקודה kubectl apply. ה-Config Connector Operator מתקין את ה-CRD של משאביGoogle Cloud ואת רכיבי Config Connector באשכול.

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

1. מעתיקים את קובץ ה-YAML הבא לקובץ בשם configconnector.yaml:

   # configconnector.yaml
   apiVersion: core.cnrm.cloud.google.com/v1beta1
   kind: ConfigConnector
   metadata:
     # the name is restricted to ensure that there is only one
     # ConfigConnector resource installed in your cluster
     name: configconnector.core.cnrm.cloud.google.com
   spec:
     mode: cluster
     googleServiceAccount: "SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com"
     # Setting `stateIntoSpec` to `Absent` is recommended. It means setting `cnrm.cloud.google.com/state-into-spec`
     # annotation to `absent` for all Config Connector resources created in the cluster in the future.
     # It prevents Config Connector from populating unspecified fields into the spec.
     stateIntoSpec: Absent

   מחליפים את הערכים הבאים:
   • ‫SERVICE_ACCOUNT_NAME בשם של חשבון השירות.
   • ‫PROJECT_ID במזהה הפרויקט.
2. מחילים את ההגדרות על האשכול באמצעות kubectl apply:

     kubectl apply -f configconnector.yaml

איך מציינים איפה ליצור את המשאבים

בעזרת Config Connector אפשר לארגן משאבים לפי פרויקט, תיקייה או ארגון, בדיוק כמו שמארגנים משאבים ב- Google Cloud.

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

אם אין לכם מרחב שמות למטרה הזו, אתם יכולים ליצור אחד באמצעות kubectl.

kubectl create namespace NAMESPACE

מחליפים את NAMESPACE בשם של מרחב השמות. לדוגמה: config-connector.

בוחרים כרטיסייה כדי לבחור איפה רוצים ש-Config Connector ייצור משאבים.

פרויקט

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

    kubectl annotate namespace \
    NAMESPACE cnrm.cloud.google.com/project-id=PROJECT_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫NAMESPACE בשם של מרחב השמות.
• ‫PROJECT_ID במזהה הפרויקט ב- Google Cloud .

תיקייה

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

    kubectl annotate namespace \
    NAMESPACE cnrm.cloud.google.com/folder-id=FOLDER_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫NAMESPACE בשם של מרחב השמות.
• ‫FOLDER_ID במזהה התיקייה ב- Google Cloud .

ארגון

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

    kubectl annotate namespace \
    NAMESPACE cnrm.cloud.google.com/organization-id=ORGANIZATION_ID

מחליפים את מה שכתוב בשדות הבאים:

• ‫NAMESPACE בשם של מרחב השמות.
• ‫ORGANIZATION_ID במזהה הארגון שלכם ( Google Cloud ).

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

אימות ההתקנה

כל הרכיבים של Config Connector פועלים במרחב שמות שנקרא cnrm-system. כדי לוודא שה-Pods מוכנים, מריצים את הפקודה הבאה:

kubectl wait -n cnrm-system \
      --for=condition=Ready pod --all

אם Config Connector מותקן כמו שצריך, הפלט אמור להיראות כך:

pod/cnrm-controller-manager-0 condition met

הערה: יכול להיות שיעברו כמה דקות עד שה-Pod של הבקר יתחיל לפעול.

הסרת Config Connector

כדי להסיר את Config Connector, מבצעים את השלבים הבאים:

1. כדי להסיר את רכיבי ה-CRD והבקר של Config Connector, מריצים את הפקודה הבאה:

   kubectl delete ConfigConnector configconnector.core.cnrm.cloud.google.com \
       --wait=true
   

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

   kubectl delete -f operator-system/configconnector-operator.yaml  --wait=true
   

שדרוג Config Connector

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

gcloud storage cp gs://configconnector-operator/latest/release-bundle.tar.gz release-bundle.tar.gz
tar zxvf release-bundle.tar.gz
kubectl apply -f operator-system/configconnector-operator.yaml

שדרוג לאחור של Config Connector

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

בגרסה 1.123.1 של Config Connector ואילך, אפשר להחזיר את גרסת האופרטור להתקנות שמשתמשות במצב מרחב שמות. בכל מרחב שמות שיש בו אופרטור שרוצים להחזיר לגרסה קודמת, מגדירים את השדה spec.version באובייקט ConfigConnectorContext לגרסה הקודמת של Config Connector.

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

שדרוג מהתקנות שלא בוצעו על ידי מפעיל

בגרסה 1.33.0 ומעלה של Config Connector אפשר להתקין רק באמצעות התוסף של GKE או האופרטור.

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

1. מריצים את הפקודות הבאות כדי להסיר את רכיבי המערכת של Config Connector שאינם CRD:

   kubectl delete sts,deploy,po,svc,roles,clusterroles,clusterrolebindings --all-namespaces -l cnrm.cloud.google.com/system=true --wait=true
   kubectl delete validatingwebhookconfiguration abandon-on-uninstall.cnrm.cloud.google.com --ignore-not-found --wait=true
   kubectl delete validatingwebhookconfiguration validating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
   kubectl delete mutatingwebhookconfiguration mutating-webhook.cnrm.cloud.google.com --ignore-not-found --wait=true
   

2. מתקינים את Config Connector באמצעות התוסף של GKE או האופרטור.

מעבר מהתוסף להתקנה ידנית

כשמתקינים את Config Connector כתוסף, הגרסה שלו קשורה ישירות לגרסת GKE שמותקנת.

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

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

1. משביתים את התוסף בלי למחוק אובייקטים של ConfigConnector או ConfigConnectorContext:

   gcloud container clusters update CLUSTER_NAME --update-addons ConfigConnector=DISABLED
   

   מחליפים את CLUSTER_NAME בשם של האשכול שבו התקנתם את Config Connector.

2. מתקינים את האופרטור הידני של הגרסה שנבחרה.

   כדי למנוע שגיאות פוטנציאליות באימות של CRD (לדוגמה, KNV2009: Invalid value: "v1beta1": must appear in spec.versions), הגרסה שנבחרה של האופרטור הידני חייבת להיות זהה לגרסה שבה השתמשתם בתוסף או מאוחרת יותר. שדרוג לאחור של גרסת המפעיל הידני עלול לגרום לשגיאות (לדוגמה, KNV2009) כי יכול להיות שהתוסף של GKE כבר שדרג הגדרות CRD מסוימות לגרסה מאוחרת יותר של Config Connector.

הערה: מכיוון ש-namespace-id ConfigMap במרחב השמות configconnector-operator-system נמחק כחלק מהשבתת התוסף, נוצרים מחדש cnrm-controller-manager StatefulSets ישנים.

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

• תחילת העבודה עם Config Connector.
• מידע ולמידה על שיטות מומלצות לשימוש ב-Config Connector.