התקנה ידנית של סנכרון תצורות באמצעות kubectl

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

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

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

הכנת הסביבה המקומית

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

• ליצור מקור מידע אמין או לקבל גישה למקור כזה.

• מתקינים ומפעילים את Google Cloud CLI, שמספק את הפקודות gcloud,‏ kubectl ו-nomos שבהן משתמשים בהוראות האלה. אם אתם משתמשים ב-Cloud Shell, ה-CLI של Google Cloud מותקן מראש.

• ‫kubectl לא מותקן כברירת מחדל על ידי Google Cloud CLI. כדי להתקין את kubectl, משתמשים בפקודה הבאה:

  gcloud components install kubectl
  

• מבצעים אימות ב- Google Cloud באמצעות הפקודה gcloud auth login כדי להוריד רכיבים של סנכרון תצורות.

הכנת האשכולות

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

הכנת ההרשאות

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

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole cluster-admin --user USER_ACCOUNT

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

• ‫CLUSTER_NAME: שם האשכול
• ‫USER_ACCOUNT: כתובת האימייל של החשבון שלכם ב- Google Cloud

בהתאם לאופן שבו הגדרתם את Google Cloud CLI במערכת המקומית, יכול להיות שתצטרכו להוסיף את השדות --project ו---zone.

אם אתם צריכים לתת ל-Config Sync גישה ל-OCI באמצעות gcpserviceaccount כסוג האימות, כדי ליצור קישור למדיניות אתם צריכים גם את ההרשאה iam.serviceAccounts.setIamPolicy. כדי לקבל את ההרשאה הזו, צריך להקצות את התפקיד "אדמין של חשבון שירות" (roles/iam.serviceAccountAdmin) ב-IAM. יכול להיות שתוכלו לקבל את ההרשאה הזו גם באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

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

רישום אשכול

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

1. פריסת סנכרון תצורות
2. נותנים לסנכרון ההגדרות הרשאת קריאה בלבד לאחד מהבאים:
   • Git
   • OCI
   • Helm
3. הגדרת סנכרון ההגדרות

פריסת סנכרון ההגדרות

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

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

   gcloud storage cp gs://config-management-release/released/latest/config-sync.tar.gz config-sync.tar.gz
   

2. מחלצים את הארכיון:

   tar -xzvf config-sync.tar.gz

3. בארכיון שחילצתם בשלב הקודם, פועלים לפי ההוראות בקובץ README.md שסופק כדי לערוך את ההתאמה האישית.

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

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   מחליפים את CONFIG_SYNC_MANIFEST בשם של המניפסט שעבר רינדור.

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

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

הסטטוס של התקנה תקינה ללא בעיות הוא PENDING או SYNCED.

התקנה לא תקינה תופיע בסטטוס NOT CONFIGURED, ותכלול אחת מהשגיאות הבאות:

• missing git-creds Secret
• git-creds Secret is missing the key specified by secretType

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

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

מתן הרשאת קריאה בלבד ל-Config Sync

אם אתם מאחסנים את ההגדרות ב-Git, אתם צריכים לתת לסנכרון ההגדרות גישה לקריאה בלבד ל-Git. אם אתם מאחסנים את קובצי התצורה כתמונות OCI, אתם צריכים לתת לסנכרון ההגדרות גישה לקריאה בלבד ל-OCI. אם אתם מאחסנים את קובצי התצורה ב-Helm, אתם צריכים לתת לסנכרון ההגדרות גישה לקריאה בלבד ל-Helm.

איך נותנים לסנכרון ההגדרות הרשאת קריאה בלבד ל-Git

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

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

עם זאת, רוב המשתמשים צריכים ליצור פרטי כניסה כי הגישה לקריאה למאגר שלהם מוגבלת. אם נדרשים פרטי כניסה, הם מאוחסנים ב-Secret של git-creds בכל אשכול רשום (אלא אם אתם משתמשים בחשבון שירות של Google). הסוד חייב להיות בשם git-creds כי זה ערך קבוע.

סנכרון ההגדרות תומך במנגנוני האימות הבאים:

• זוג מפתחות SSH‏ (ssh)
• קובץ Cookie‏ (cookiefile)
• טוקן (token)
• חשבון שירות של Google‏ (gcpserviceaccount)
• חשבון השירות של Compute Engine שמוגדר כברירת מחדל (gcenode)
• אפליקציית GitHub‏ (githubapp)

המנגנון שבוחרים תלוי במה שנתמך במאגר. באופן כללי, מומלץ להשתמש בזוג מפתחות SSH. גם GitHub וגם Bitbucket תומכים בשימוש בזוג מפתחות SSH. עם זאת, אם אתם משתמשים במאגר ב-Cloud Source Repositories או ב-Secure Source Manager, מומלץ להשתמש בחשבון שירות של Google כי התהליך פשוט יותר. אם הארגון שלכם מארח את המאגר ואתם לא יודעים באילו שיטות אימות הוא תומך, פנו לאדמין.

כדי להשתמש במאגר ב-Cloud Source Repositories כמאגר של סנכרון תצורות, צריך לאחזר את כתובת ה-URL של Cloud Source Repositories:

1. מציגים את כל המאגרים:

   gcloud source repos list
   

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

   REPO_NAME  PROJECT_ID  URL
   my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
   

   תצטרכו להשתמש בכתובת ה-URL הזו כשתגדירו את סנכרון תצורות בקטע הבא. אם אתם מגדירים את סנכרון תצורות באמצעות מסוףGoogle Cloud , אתם צריכים להוסיף את כתובת ה-URL בשדה URL. אם אתם מגדירים את סנכרון תצורות באמצעות Google Cloud CLI, אתם צריכים להוסיף את כתובת ה-URL לשדה syncRepo בקובץ התצורה.

זוג מפתחות SSH

זוג מפתחות SSH מורכב משני קבצים: מפתח ציבורי ומפתח פרטי. למפתח הציבורי יש בדרך כלל סיומת .pub.

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

כדי להשתמש בזוג מפתחות SSH:

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

   הפקודה הבאה יוצרת מפתח RSA של 4,096 ביטים. לא מומלץ להשתמש בערכים נמוכים יותר:

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

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

   • ‫GIT_REPOSITORY_USERNAME: שם המשתמש שבו רוצים ש"סנכרון הגדרות" ישתמש כדי לאמת את המאגר
   • ‫/path/to/KEYPAIR_FILENAME: נתיב לזוג המפתחות

   אם אתם משתמשים במארח של מאגר Git של צד שלישי כמו GitHub, או אם אתם רוצים להשתמש בחשבון שירות עם Cloud Source Repositories, מומלץ להשתמש בחשבון נפרד.

   הערה: צריך ליצור את מפתח ה-SSH בלי ביטוי סיסמה. בסנכרון ההגדרות אין תמיכה בביטויי סיסמה של מפתחות SSH.

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

   • Cloud Source Repositories
   • Bitbucket
   • GitHub מומלץ ליצור מפתחות פריסה נפרדים כדי לספק הרשאת קריאה בלבד למאגר GitHub יחיד.
   • GitLab

3. מוסיפים את המפתח הפרטי לסוד חדש באשכול:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   מחליפים את /path/to/KEYPAIR_PRIVATE_KEY_FILENAME בשם של המפתח הפרטי (זה שבלי הסיומת .pub).

4. (מומלץ) כדי להגדיר בדיקה של מארחים מוכרים באמצעות אימות SSH, אתם יכולים להוסיף את מפתח המארחים המוכרים לשדה data.known_hosts בסוד git_creds. כדי להשבית את הבדיקה של known_hosts, אפשר להסיר את השדה known_hosts מה-secret. כדי להוסיף את המפתח של המארחים המוכרים, מריצים את הפקודה:

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   לאחר מכן, בקטע data, מוסיפים את הרשומה של המארחים המוכרים:

   known_hosts: KNOWN_HOSTS_KEY
   

5. מוחקים את המפתח הפרטי מהדיסק המקומי או מגינים עליו בדרך אחרת.

6. כשמגדירים את סנכרון תצורות ומוסיפים את כתובת ה-URL של מאגר Git, צריך להשתמש בפרוטוקול SSH. אם אתם משתמשים במאגר ב-Cloud Source Repositories, אתם צריכים להשתמש בפורמט הבא כשאתם מזינים את כתובת ה-URL:

   ssh://[e-mail]:2022/p/PROJECT_ID/r/REPO_NAME
   

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

   • ‫EMAIL: שם המשתמש שלכם ב- Google Cloud
   • ‫PROJECT_ID: המזהה של הפרויקט ב- Google Cloudשבו נמצא המאגר
   • ‫REPO_NAME: שם המאגר

קובץ Cookie

הערה: אפשר להשתמש בפרטי הכניסה של cookiefile רק ב-Cloud Source Repositories. אם אתם רוצים להשתמש ב-GitHub עם אימות cookiefile, אתם יכולים להשתמש ב-Cloud Source Repositories כדי ליצור עותק של המאגר שלכם ב-GitHub.

תהליך קבלת ה-cookiefile תלוי בהגדרת המאגר. לדוגמה, ראו יצירת פרטי כניסה סטטיים במסמכי התיעוד של Cloud Source Repositories. פרטי הכניסה בדרך כלל מאוחסנים בקובץ .gitcookies בספריית הבית, או שהם נמסרים לכם על ידי מנהל אבטחה.

כדי להשתמש ב-cookiefile, צריך לבצע את השלבים הבאים:

1. אחרי שיוצרים ומקבלים את ה-cookiefile, מוסיפים אותו ל-Secret חדש באשכול.

   אם אתם לא משתמשים בשרת proxy ל-HTTPS, צרו את הסוד באמצעות הפקודה הבאה:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   אם אתם צריכים להשתמש בשרת proxy ל-HTTPS, הוסיפו אותו ל-Secret יחד עם cookiefile באמצעות הפקודה הבאה:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

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

   • ‫/path/to/COOKIEFILE: הנתיב ושם הקובץ המתאימים
   • ‫HTTPS_PROXY_URL: כתובת ה-URL של שרת ה-proxy ל-HTTPS שמשמש לתקשורת עם מאגר Git
   הערה: מטעמי אבטחה, אנחנו לא ממליצים להשתמש בשרת proxy ל-HTTP.

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

אסימון

אם הארגון שלכם לא מאפשר להשתמש במפתחות SSH, יכול להיות שתעדיפו להשתמש בטוקן. בסנכרון הגדרות, אתם יכולים להשתמש בטוקנים לגישה אישית (PAT) של GitHub, ב-PAT או במפתחות פריסה של GitLab, או בסיסמת האפליקציה של Bitbucket בתור הטוקן שלכם.

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

1. יוצרים אסימון באמצעות GitHub,‏ GitLab או Bitbucket:

   • ‫GitHub: יוצרים PAT. נותנים לטוקן את ההיקף repo כדי שהוא יוכל לקרוא ממאגרים פרטיים. מכיוון שאתם מקשרים PAT לחשבון GitHub, מומלץ גם ליצור משתמש מכונה ולקשר את ה-PAT למשתמש המכונה.
   • ‫GitLab: יצירת PAT או יצירת טוקן פריסה
   • ‫Bitbucket: יוצרים סיסמה לאפליקציה.

2. אחרי שיוצרים ומקבלים את האסימון, מוסיפים אותו ל-Secret חדש באשכול.

   אם אתם לא משתמשים בשרת proxy ל-HTTPS, צרו את הסוד באמצעות הפקודה הבאה:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

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

   • ‫USERNAME: שם המשתמש שבו רוצים להשתמש.
   • ‫TOKEN: האסימון שיצרתם בשלב הקודם.

   אם אתם צריכים להשתמש בשרת proxy ל-HTTPS, הוסיפו אותו ל-Secret יחד עם username ו-token באמצעות הפקודה הבאה:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

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

   • ‫USERNAME: שם המשתמש שבו רוצים להשתמש.
   • ‫TOKEN: האסימון שיצרתם בשלב הקודם.
   • ‫HTTPS_PROXY_URL: כתובת ה-URL של שרת ה-proxy ל-HTTPS שמשמש לתקשורת עם מאגר Git.
   הערה: מטעמי אבטחה, אנחנו לא ממליצים להשתמש בשרת proxy ל-HTTP.

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

חשבון שירות של Google

אם המאגר נמצא ב-Cloud Source Repositories או ב-Secure Source Manager, והאשכול משתמש באיחוד זהויות של עומסי עבודה ל-GKE או באיחוד זהויות של עומסי עבודה ל-GKE ב-Fleet, אתם יכולים לתת לסנכרון ההגדרות גישה למאגר באותו פרויקט כמו האשכול המנוהל באמצעות חשבון שירות ב-Google.

הערה: למרות שהשיטה המומלצת היא להקצות תפקידי IAM ישירות לישות מורשית של ServiceAccount ב-Kubernetes‏ (principal://) בשביל איחוד זהויות של עומסי עבודה ל-GKE, אימות Git של סנכרון תצורות דורש התחזות לחשבון שירות של IAM כי השדה spec.git.gcpServiceAccountEmail של RootSync ו-RepoSync דורש כתובת אימייל של חשבון שירות של IAM.

1. אם עדיין אין לכם חשבון שירות, צרו חשבון שירות.

2. מקצים לחשבון השירות את התפקידים המתאימים ב-IAM כדי שתהיה לו גישה למאגר:

   Cloud Source Repositories

   מקצים לחשבון השירות ב-Google את התפקיד "קורא של Cloud Source Repositories"‏ (roles/source.reader) ב-IAM. למידע נוסף על התפקידים וההרשאות ב-Cloud Source Repositories, קראו את המאמר מתן הרשאות לצפייה במאגרים.

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

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID."
     

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

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

   Secure Source Manager

   מקצים לחשבון השירות של Google את התפקידים "ממשק גישה למכונה של Secure Source Manager" (roles/securesourcemanager.instanceAccessor) ו"קורא מאגרים של Secure Source Manager" (roles/securesourcemanager.repoReader) ב-IAM. מידע נוסף על התפקידים וההרשאות ב-Secure Source Manager מופיע במאמר ניהול התפקידים במאגר.

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

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.instanceAccessor \
       --member="serviceAccount:GSA_NAME@PROJECT_ID."
     

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/securesourcemanager.repoReader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID."
     

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

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

   אם אתם מגדירים את סנכרון תצורות באמצעות Google Cloud CLI, הוסיפו את gcpserviceaccount בתור secretType ואז הוסיפו את כתובת האימייל של חשבון השירות ל-gcpServiceAccountEmail.

4. אם אתם משתמשים במאגר ב-Secure Source Manager, אתם צריכים להשתמש בפורמט הבא כשאתם מגדירים את סנכרון תצורות ומוסיפים את כתובת ה-URL של מאגר Git:

   https://INSTANCE_ID-PROJECT_NUMBER-git.LOCATION.sourcemanager.dev/PROJECT_ID/REPO_NAME.git
   

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

   • ‫INSTANCE_ID: השם של המכונה של Secure Source Manager.
   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloudשבו נמצא המכונה.
   • ‫PROJECT_NUMBER: Google Cloudמספר הפרויקט שבו נמצא המכונה.
   • ‫LOCATION: האזור שבו נמצאת המכונה.
   • ‫REPO_NAME: שם המאגר.

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

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

   הקישור הזה מאפשר לחשבון השירות של Config Sync ב-Kubernetes לפעול כחשבון השירות ב-Google:

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID. \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.[config-management-system/KUBERNETES_SERVICEACCOUNT]" \
       --project=PROJECT_ID
   

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

• ‫PROJECT_ID: מזהה הפרויקט של הארגון.
• ‫FLEET_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE ב-Fleet, זה מזהה הפרויקט של ה-Fleet שאליו האשכול רשום.
• ‫GSA_NAME: חשבון השירות המותאם אישית ב-Google שבו רוצים להשתמש כדי להתחבר ל-Secure Source Manager או ל-Cloud Source Repositories.
• ‫KUBERNETES_SERVICEACCOUNT: ה-ServiceAccount של Kubernetes למתאם:
  • במאגרי שורש, אם השם של RootSync הוא root-sync, צריך להשתמש ב-root-reconciler. אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME. אם מתקינים את סנכרון ההגדרות באמצעות מסוף Google Cloud או Google Cloud CLI, סנכרון ההגדרות יוצר באופן אוטומטי אובייקט RootSync בשם root-sync.
• ‫REPOSITORY: שם המאגר.
• ‫POLICY_FILE: קובץ ה-JSON או ה-YAML עם מדיניות ניהול הזהויות והרשאות הגישה.

הערה: כדי ליצור את קישור המדיניות הזה נדרשת ההרשאה iam.serviceAccounts.setIamPolicy.

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

אם המאגר נמצא ב-Cloud Source Repositories, והאשכול הוא GKE עם איחוד זהויות של עומסי עבודה ל-GKE מושבת, אפשר להשתמש ב-gcenode כסוג האימות.

אם אתם מגדירים את סנכרון תצורות באמצעות מסוף Google Cloud , בחרו באפשרות Google Cloud Repository בתור Authentication Type.

אם אתם מגדירים את סנכרון תצורות באמצעות Google Cloud CLI, הוסיפו את gcenode בתור secretType.

אם בוחרים באפשרות Google Cloud Repository או באפשרות gcenode, אפשר להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. אתם צריכים להקצות את תפקיד ה-IAM 'קורא Cloud Source Repositories' (roles/source.reader) לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. למידע נוסף על התפקידים וההרשאות של Cloud Source Repositories, קראו את המאמר מתן הרשאות לצפייה במאגרים.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:PROJECT_NUMBER-compute@"

מחליפים את PROJECT_ID במזהה הפרויקט של הארגון, ואת PROJECT_NUMBER במספר הפרויקט של הארגון.

אפליקציית GitHub

אם המאגר שלכם נמצא ב-GitHub, אתם יכולים להשתמש ב-githubapp כסוג האימות.

כדי להשתמש באפליקציית GitHub:

1. פועלים לפי ההוראות ב-GitHub כדי להקצות אפליקציית GitHub ולתת לה הרשאה לקרוא מהמאגר.

2. מוסיפים את ההגדרות של אפליקציית GitHub לסוד חדש באשכול:

   שימוש במזהה לקוח

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • מחליפים את CLIENT_ID במזהה הלקוח של אפליקציית GitHub.
   • מחליפים את INSTALLATION_ID במזהה ההתקנה של אפליקציית GitHub.
   • מחליפים את /path/to/GITHUB_PRIVATE_KEY בשם של הקובץ שמכיל את המפתח הפרטי.
   • מחליפים את BASE_URL בכתובת ה-URL הבסיסית של נקודת קצה ל-API של GitHub. צריך להשתמש בארגומנט הזה רק אם המאגר לא מתארח ב-www.github.com. אחרת, אפשר להשמיט את הארגומנט והוא יוגדר כברירת מחדל ל-https://api.github.com/.

   שימוש במזהה האפליקציה

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • מחליפים את APPLICATION_ID במזהה האפליקציה של GitHub.
   • מחליפים את INSTALLATION_ID במזהה ההתקנה של אפליקציית GitHub.
   • מחליפים את /path/to/GITHUB_PRIVATE_KEY בשם של הקובץ שמכיל את המפתח הפרטי.
   • מחליפים את BASE_URL בכתובת ה-URL הבסיסית של נקודת הקצה ל-API של GitHub. צריך להשתמש בארגומנט הזה רק אם המאגר לא מתארח ב-www.github.com. אחרת, אפשר להשמיט את הארגומנט והוא יוגדר כברירת מחדל ל-https://api.github.com/.

3. מוחקים את המפתח הפרטי מהדיסק המקומי או מגינים עליו בדרך אחרת.

4. כשמגדירים את "סנכרון תצורות" ומוסיפים את כתובת ה-URL של מאגר Git, משתמשים בסוג האימות githubapp.

הענקת הרשאת קריאה בלבד ל-Config Sync ב-OCI

כדי שסנכרון ההגדרות יוכל לקרוא את ההגדרות שכלולות בתמונת ה-OCI ששמורה ב-Artifact Registry ולהחיל אותן על האשכולות, צריך לתת לו הרשאת קריאה בלבד.

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

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

• ‫Kubernetes ServiceAccount‏ (k8sserviceaccount)

• חשבון השירות של Compute Engine שמוגדר כברירת מחדל (gcenode)

‫Kubernetes ServiceAccount

אם אתם מאחסנים את קובץ האימג' של OCI ב-Artifact Registry והאשכול שלכם משתמש באיחוד זהויות של עומסי עבודה ל-GKE או באיחוד זהויות של עומסי עבודה ב-fleet ל-GKE, אתם יכולים להשתמש ב-Kubernetes ServiceAccount כסוג האימות.

מקצים את התפקיד "קריאה ב-Artifact Registry" (roles/artifactregistry.reader) בפרויקט או במאגר ל-Kubernetes ServiceAccount. למידע נוסף על התפקידים וההרשאות של Artifact Registry, קראו את המאמר הגדרת תפקידים והרשאות ל-Artifact Registry.

• אם אותן הרשאות חלות על כל המאגרים בפרויקט, צריך לתת הרשאה ברמת הפרויקט:

  gcloud projects add-iam-policy-binding PROJECT_ID \
      --role=roles/artifactregistry.reader \
      --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID./subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
      --condition=None
  

• כדי להעניק לחשבונות שירות רמות גישה שונות לכל מאגר בפרויקט, צריך להעניק הרשאה ספציפית למאגר:

  gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
      --location=LOCATION \
      --role=roles/artifactregistry.reader \
      --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID./subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
      --project=PROJECT_ID \
      --condition=None
  

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

• ‫PROJECT_ID: מזהה הפרויקט של הארגון.
• ‫FLEET_HOST_PROJECT_NUMBER: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, זהו מספר הפרויקט של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE ב-Fleet, זה מספר הפרויקט של ה-Fleet שאליו רשום האשכול.
• ‫FLEET_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE ב-Fleet, זה מזהה הפרויקט של ה-Fleet שאליו האשכול רשום.
• ‫KUBERNETES_SERVICEACCOUNT: ה-Kubernetes ServiceAccount של ה-reconciler:
• במאגרי שורש, אם השם של RootSync הוא root-sync, צריך להשתמש ב-root-reconciler. אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME. אם מתקינים את סנכרון ההגדרות באמצעות מסוף Google Cloud או Google Cloud CLI, סנכרון ההגדרות יוצר באופן אוטומטי אובייקט RootSync בשם root-sync.
• ‫REPOSITORY: מזהה המאגר.
• ‫LOCATION: המיקום האזורי או המיקום במספר אזורים של המאגר.

הערה: כדי ליצור את קישור המדיניות הזה, נדרשת ההרשאה resourcemanager.projects.setIamPolicy (לגישה ברמת הפרויקט) או ההרשאה artifactregistry.repositories.setIamPolicy (לגישה ספציפית למאגר).

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

אם אתם מאחסנים את קובץ האימג' של OCI ב-Artifact Registry והאשכול שלכם הוא GKE עם איחוד זהויות של עומסי עבודה מושבת ל-GKE, אתם יכולים להשתמש ב-gcenode כסוג האימות. סנכרון ההגדרות משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. אתם צריכים לתת לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine גישת קריאה ל-Artifact Registry.

מריצים את הפקודה הבאה כדי לתת לחשבון השירות של Compute Engine הרשאת קריאה ל-Artifact Registry:

gcloud projects add-iam-policy-binding PROJECT_ID \
   --member=serviceAccount:PROJECT_NUMBER-compute@ \
   --role=roles/artifactregistry.reader

מחליפים את PROJECT_ID במזהה הפרויקט של הארגון, ואת PROJECT_NUMBER במספר הפרויקט של הארגון.

הגדרת סנכרון הגדרות לרשות אישורים

בשרתים שמוגדרים עם אישורים מרשות אישורים (CA) שלא נחשבת מהימנה, אפשר להגדיר את סנכרון ההגדרות כך שישתמש באישור CA כדי לאמת חיבורי HTTPS לשרת. המאפיין הזה נתמך בשרתי Git,‏ Helm או OCI. אישור ה-CA צריך לכלול אישורי SSL מלאים (בסיס/ביניים/עלה). אם השרת כבר משתמש ברשות אישורים מהימנה או שאתם לא מתחברים באמצעות HTTPS, אתם יכולים לדלג על השלב הזה ולא להגדיר את caCertSecretRef.

RootSync

1. משיגים את אישור ה-CA ששימש להנפקת האישור לשרת Git, ושומרים אותו בקובץ.

2. באובייקטים של RootSync, צריך ליצור את ה-Secret במרחב השמות config-management-system. לדוגמה:

   kubectl create ns config-management-system && 
   
   kubectl create secret generic ROOT_CA_CERT_SECRET_NAME 
   
    --namespace=config-management-system 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. כשמגדירים את סנכרון תצורות, מגדירים את הערך של השדה caCertSecretRef.name באובייקט RootSync ל-ROOT_CA_CERT_SECRET_NAME.

RepoSync

1. משיגים את אישור ה-CA ששימש להנפקת האישור לשרת Git, ושומרים אותו בקובץ.

2. באובייקטים מסוג RepoSync, צריך ליצור את הסוד באותו מרחב שמות שבו נמצא ה-RepoSync. לדוגמה:

   kubectl create ns REPO_SYNC_NAMESPACE && 
   
   kubectl create secret generic NAMESPACE_CA_CERT_SECRET_NAME 
   
    --namespace=REPO_SYNC_NAMESPACE 
   
    --from-file=cert=/path/to/CA_CERT_FILE
   

3. כשמגדירים את RepoSync, צריך להגדיר את הערך של השדה caCertSecretRef.name באובייקט RepoSync ל-NAMESPACE_CA_CERT_SECRET_NAME.

מתן הרשאת קריאה בלבד ל-סנכרון תצורות ב-Helm

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

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

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

• טוקן (token)
• ‫Kubernetes ServiceAccount‏ (k8sserviceaccount)
• חשבון השירות של Compute Engine שמוגדר כברירת מחדל (gcenode)

הערה: סנכרון תצורות לא תומך בהגדרת helm כסוג המקור באמצעות מסוף Google Cloud או Google Cloud CLI. אתם יכולים להגדיר את האובייקט RootSync או RepoSync לסנכרון ממאגר Helm באמצעות Kubernetes API, או להצהיר עליו במקור מידע מוסמך אחר. מידע נוסף זמין במאמר הגדרת מאגר Helm.

אסימון

יוצרים Secret עם שם משתמש וסיסמה למאגר Helm:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

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

• ‫SECRET_NAME: השם שרוצים לתת לסוד.
• ‫USERNAME: שם המשתמש של מאגר Helm.
• ‫PASSWORD: הסיסמה למאגר Helm.

כשמגדירים את סנכרון ההגדרות, משתמשים בשם הסוד שנבחר ל-spec.helm.secretRef.name.

‫Kubernetes ServiceAccount

אתם יכולים להשתמש ב-Kubernetes ServiceAccount כסוג האימות אם אתם מאחסנים את תרשים Helm ב-Artifact Registry והאשכול שלכם משתמש ב-איחוד זהויות של עומסי עבודה ל-GKE או ב-איחוד זהויות של עומסי עבודה ל-GKE.

מקצים את התפקיד "קריאה ב-Artifact Registry" (roles/artifactregistry.reader) בפרויקט או במאגר ל-Kubernetes ServiceAccount. למידע נוסף על התפקידים וההרשאות של Artifact Registry, קראו את המאמר הגדרת תפקידים והרשאות ל-Artifact Registry.

• אם אותן הרשאות חלות על כל המאגרים בפרויקט, צריך לתת הרשאה ברמת הפרויקט:

  gcloud projects add-iam-policy-binding PROJECT_ID \
     --role=roles/artifactregistry.reader \
     --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID./subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
     --condition=None
  

• כדי להעניק לחשבונות שירות רמות גישה שונות לכל מאגר בפרויקט, צריך להעניק הרשאה ספציפית למאגר:

  gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
     --location=LOCATION \
     --role=roles/artifactregistry.reader \
     --member="principal://iam.googleapis.com/projects/FLEET_HOST_PROJECT_NUMBER/locations/global/workloadIdentityPools/FLEET_HOST_PROJECT_ID./subject/ns/config-management-system/sa/KUBERNETES_SERVICEACCOUNT" \
     --project=PROJECT_ID \
     --condition=None
  

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

• ‫PROJECT_ID: מזהה הפרויקט של הארגון.
• ‫FLEET_HOST_PROJECT_NUMBER: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, זהו מספר הפרויקט של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE ב-Fleet, זה מספר הפרויקט של ה-Fleet שאליו רשום האשכול.
• ‫FLEET_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE ב-Fleet, זה מזהה הפרויקט של ה-Fleet שאליו האשכול רשום.
• ‫KUBERNETES_SERVICEACCOUNT: ה-Kubernetes ServiceAccount של ה-reconciler:
• במאגרי שורש, אם השם של RootSync הוא root-sync, צריך להשתמש ב-root-reconciler. אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME.
• ‫REPOSITORY: מזהה המאגר.
• ‫LOCATION: המיקום האזורי או המיקום במספר אזורים של המאגר.

הערה: כדי ליצור את קישור המדיניות הזה, נדרשת ההרשאה resourcemanager.projects.setIamPolicy (לגישה ברמת הפרויקט) או ההרשאה artifactregistry.repositories.setIamPolicy (לגישה ספציפית למאגר).

חשבון השירות של Compute Engine שמוגדר כברירת מחדל

אם אתם מאחסנים את תרשים ה-Helm ב-Artifact Registry, והאשכול שלכם הוא GKE עם איחוד זהויות של עומסי עבודה ל-GKE מושבת, אתם יכולים להשתמש ב-gcenode כסוג האימות. סנכרון ההגדרות משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. אתם צריכים לתת לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine גישת קריאה ל-Artifact Registry. יכול להיות שתצטרכו להעניק את היקף הגישה storage-ro כדי לתת הרשאת קריאה בלבד לשליפת תמונות.

נותנים לחשבון השירות של Compute Engine הרשאת קריאה ל-Artifact Registry:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:PROJECT_NUMBER-compute@ \
    --role=roles/artifactregistry.reader

מחליפים את PROJECT_ID במזהה הפרויקט של הארגון, ואת PROJECT_NUMBER במספר הפרויקט של הארגון.

הגדרת סנכרון ההגדרות

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

1. אם אתם משתמשים ב-webhook לאימות של סנכרון תצורות (ה-webhook לאימות מושבת כברירת מחדל) ומתקינים את סנכרון תצורות באשכול פרטי, הוסיפו כלל חומת אש כדי לאפשר את היציאה 10250. ה-webhook לאימות של סנכרון ההגדרות משתמש ביציאה 10250 למניעת חריגה.

2. מחכים שה-CRD של RootSync ו-RepoSync יהיו זמינים:

   until kubectl get customresourcedefinitions rootsyncs.configsync.gke.io reposyncs.configsync.gke.io; do date; sleep 1; echo ""; done
   

3. שומרים את אחד מהמניפסטים הבאים בתור root-sync.yaml. צריך להשתמש בגרסת המניפסט שתואמת לסוג המקור של ההגדרות האישיות.

   Git

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: git
     sourceFormat: unstructured
     git:
       repo: ROOT_REPOSITORY
       revision: ROOT_REVISION
       branch: ROOT_BRANCH
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       secretRef:
         name: ROOT_SECRET_NAME
       noSSLVerify: ROOT_NO_SSL_VERIFY
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

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

   • ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
   • ‫ROOT_REPOSITORY: מוסיפים את כתובת ה-URL של מאגר Git שרוצים להשתמש בו כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
   • ‫ROOT_REVISION: מוסיפים את הגרסה (תג או גיבוב) או את ההסתעפות של Git שממנה רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא HEAD. כשמשתמשים בגיבוב, הוא חייב להיות גיבוב מלא ולא מקוצר.
   • ‫ROOT_BRANCH: מוסיפים את הענף של המאגר שממנו רוצים לסנכרן. השדה הזה הוא אופציונלי וערך ברירת המחדל הוא master. כדי לפשט את התהליך, מומלץ להשתמש בשדה revision כדי לציין שם של הסתעפות. אם צוינו גם השדה revision וגם השדה branch, השדה revision מקבל עדיפות על פני branch.
   • ‫ROOT_DIRECTORY: מוסיפים את הנתיב במאגר Git לתיקיית השורש שמכילה את ההגדרות שרוצים לסנכרן. השדה הזה הוא אופציונלי, וברירת המחדל היא תיקיית השורש (/) של המאגר.

   • ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:

     • ‫none: ללא אימות
     • ‫ssh: שימוש בזוג מפתחות SSH
     • ‫cookiefile: שימוש בcookiefile
     • token: שימוש בטוקן
     • ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories.
     • ‫gcenode: שימוש בחשבון שירות של Google כדי לגשת למאגר ב-Cloud Source Repositories. צריך לבחור באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.

     מידע נוסף על סוגי האימות האלה זמין במאמר מתן גישה לקריאה בלבד ל-סנכרון תצורות ב-Git.

     חובה למלא את השדה הזה.

   • ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount בתור ROOT_AUTH_TYPE, הוסיפו את כתובת האימייל של חשבון השירות ב-Google. לדוגמה, acm@PROJECT_ID..

   • ‫ROOT_SECRET_NAME: מוסיפים את שם הסוד. אם השדה הזה מוגדר, צריך להוסיף את המפתח הציבורי של הסוד לספק Git. השדה הזה הוא אופציונלי.

   • ‫ROOT_NO_SSL_VERIFY: כדי להשבית את האימות של אישור ה-SSL, מגדירים את השדה הזה לערך true. ערך ברירת המחדל הוא false.

   • ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את שם הסוד. אם השדה הזה מוגדר, ספק ה-Git צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור ה-CA במפתח בשם cert. השדה הזה אופציונלי.

     איך מגדירים את אובייקט הסוד לאישור ה-CA

   הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

   המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Git כמקור.

   OCI

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: oci
     sourceFormat: unstructured
     oci:
       image: ROOT_IMAGE
       dir: ROOT_DIRECTORY
       auth: ROOT_AUTH_TYPE
       gcpServiceAccountEmail: ROOT_EMAIL
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

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

   • ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
   • ‫ROOT_IMAGE: כתובת ה-URL של קובץ האימג' של OCI שמשמש כמאגר הבסיס, לדוגמה LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. כברירת מחדל, התמונה נשלפת מהתג latest, אבל אפשר לשלוף תמונות לפי TAG או DIGEST במקום זאת. מציינים TAG או DIGEST ב-PACKAGE_NAME:
     • כדי לשלוף לפי TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • כדי לשלוף לפי DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST

   זהירות: כדי להשתמש בסנכרון ההגדרות, צריך לדחוס את שכבת ה-OCI בפורמט tar או tar+gzip. פורמטים אחרים (לדוגמה, tar+bz2) לא יזוהו על ידי סנכרון תצורות. מעבר ממאגר תקין לתמונת OCI בפורמט לא נתמך יגרום למחיקת המשאבים המנוהלים בלי שגיאה.

   • ‫ROOT_DIRECTORY: מוסיפים את הנתיב במאגר לתיקיית השורש שמכילה את ההגדרות שרוצים לסנכרן. השדה הזה הוא אופציונלי, וברירת המחדל היא תיקיית השורש (/) של המאגר.

   • ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:

     • ‫none: ללא אימות
     • ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל של Compute Engine כדי לגשת לתמונה ב-Artifact Registry. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
     • ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.

     חובה למלא את השדה הזה.

   • ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount בתור ROOT_AUTH_TYPE, הוסיפו את כתובת האימייל של חשבון השירות ב-Google. לדוגמה, acm@PROJECT_ID..

   • ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את שם הסוד. אם השדה הזה מוגדר, ספק ה-OCI צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור ה-CA במפתח בשם cert. השדה הזה אופציונלי.

   איך מגדירים את אובייקט הסוד לאישור ה-CA

   הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

   המניפסט הזה יוצר אובייקט RootSync שמשתמש בקובץ אימג' של OCI כמקור.

   הגה

   # root-sync.yaml
   apiVersion: configsync.gke.io/v1beta1
   kind: RootSync
   metadata:
     name: ROOT_SYNC_NAME
     namespace: config-management-system
   spec:
     sourceType: helm
     sourceFormat: unstructured
     helm:
       repo: ROOT_HELM_REPOSITORY
       chart: HELM_CHART_NAME
       version: HELM_CHART_VERSION
       releaseName: HELM_RELEASE_NAME
       namespace: HELM_RELEASE_NAMESPACE
       values:
         foo:
           bar: VALUE_1
         baz:
         - qux: VALUE_2
           xyz: VALUE_3
       includeCRDs: HELM_INCLUDE_CRDS
       auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
       caCertSecretRef:
         name: ROOT_CA_CERT_SECRET_NAME
   

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

   • ‫ROOT_SYNC_NAME: מוסיפים את השם של אובייקט RootSync.
   • ‫ROOT_HELM_REPOSITORY: כתובת ה-URL של מאגר Helm שמשמש כמאגר הבסיס. אפשר להזין כתובות URL באמצעות פרוטוקול HTTPS או SSH. לדוגמה, https://github.com/GoogleCloudPlatform/anthos-config-management-samples משתמש בפרוטוקול HTTPS. חובה למלא את השדה הזה.
   • ‫HELM_CHART_NAME: השם של תרשים ה-Helm. חובה למלא את השדה הזה.
   • ‫HELM_CHART_VERSION: גרסת התרשים. השדה הזה הוא אופציונלי. אם לא מציינים ערך, המערכת משתמשת בגרסה העדכנית.
   • ‫HELM_RELEASE_NAME: השם של גרסת ה-Helm. השדה הזה הוא אופציונלי.
   • ‫HELM_RELEASE_NAMESPACE: מרחב השמות של היעד לגרסה. הוא מגדיר מרחב שמות רק למשאבים שמכילים את namespace: {{ .Release.Namespace }} בתבניות שלהם. השדה הזה הוא אופציונלי. אם לא מציינים ערך, המערכת משתמשת במרחב השמות שמוגדר כברירת מחדל, config-management-system.
   • ‫HELM_INCLUDE_CRDS: מגדירים את הערך true אם רוצים שתבנית Helm תיצור גם CustomResourceDefinition. השדה הזה הוא אופציונלי. אם לא מציינים ערך, ברירת המחדל היא false ולא נוצר CRD.
   • ‫VALUE: ערכים שבהם צריך להשתמש במקום ערכי ברירת המחדל שמצורפים לתרשים Helm. צריך לעצב את השדה הזה באותו אופן שבו מעצבים את הקובץ values.yaml של תרשים Helm. השדה הזה הוא אופציונלי.

   • ‫ROOT_AUTH_TYPE: מוסיפים אחד מסוגי האימות הבאים:

     • ‫none: ללא אימות
     • ‫token: שימוש בשם משתמש ובסיסמה כדי לגשת למאגר Helm פרטי.
     • ‫gcenode: שימוש בחשבון השירות שמוגדר כברירת מחדל של Compute Engine כדי לגשת לתמונה ב-Artifact Registry. בוחרים באפשרות הזו רק אם איחוד זהויות של עומסי עבודה ל-GKE לא מופעל באשכול.
     • ‫gcpserviceaccount: שימוש בחשבון שירות של Google כדי לגשת לתמונה.

     חובה למלא את השדה הזה.

   • ‫ROOT_EMAIL: אם הוספתם את gcpserviceaccount בתור ROOT_AUTH_TYPE, הוסיפו את כתובת האימייל של חשבון השירות ב-Google. לדוגמה, acm@PROJECT_ID..

   • ‫ROOT_SECRET_NAME: מוסיפים את שם הסוד אם token הוא ROOT_AUTH_TYPE. השדה הזה הוא אופציונלי.

   • ‫ROOT_CA_CERT_SECRET_NAME: מוסיפים את שם הסוד. אם השדה הזה מוגדר, ספק ה-Helm צריך להשתמש באישור שהונפק על ידי רשות האישורים (CA) הזו. הסוד חייב להכיל את אישור ה-CA במפתח בשם cert. השדה הזה אופציונלי.

   איך מגדירים את אובייקט הסוד לאישור ה-CA

   הסבר על השדות ורשימה מלאה של השדות שאפשר להוסיף לשדה spec מופיעים במאמר שדות RootSync.

   המניפסט הזה יוצר אובייקט RootSync שמשתמש ב-Helm כמקור.

4. מחילים את השינויים:

   kubectl apply -f root-sync.yaml
   

מזינים שם אשכול לבוררי אשכולות (אופציונלי)

אם רוצים להשתמש ב-cluster-name-selectors, צריך לספק שם אשכול ל-סנכרון תצורות. השלב הזה הוא אופציונלי ונדרש רק אם משתמשים בבוררי שמות של אשכולות.

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

1. מוסיפים את משתנה הסביבה CLUSTER_NAME לפריסה של reconciler-manager:

   kubectl set env deployment/reconciler-manager -n config-management-system CLUSTER_NAME=CLUSTER_NAME
   

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

2. כדי להפיץ את שם האשכול גם למתאמי RootSync וגם למתאמי RepoSync, מפעילים מחדש את הפריסה של reconciler-manager:

   kubectl rollout restart deployment/reconciler-manager -n config-management-system
   

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

אפשר להשתמש בפקודה nomos status כדי לבדוק את סטטוס הסנכרון של מאגר הבסיס:

nomos status

הפלט אמור להיראות כמו בדוגמה הבאה:

my_managed_cluster-1
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4

אימות ההתקנה של RootSync

כשיוצרים אובייקט RootSync, סנכרון ההגדרות יוצר מתאם עם הקידומת root-reconciler. מנגנון ההתאמה הוא Pod שנפרס כ-Deployment. הוא מסנכרן מניפסטים ממאגר Git לאשכול.

כדי לוודא שהאובייקט RootSync פועל כמו שצריך, בודקים את הסטטוס של פריסת root-reconciler:

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

מחליפים את ROOT_SYNC_NAME בשם של RootSync.

הפלט אמור להיראות כמו בדוגמה הבאה:

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

במאמר מעקב אחרי אובייקטים של RootSync ו-RepoSync מוסבר איך לבדוק את הסטטוס של אובייקט RootSync בדרכים נוספות.

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

שדרוג של סנכרון ההגדרות

השלבים לשדרוג של "סנכרון תצורות" תלויים בגרסה שמשדרגים ממנה ובגרסה שמשדרגים אליה. החל מגרסה 1.20.0, סנכרון ההגדרות מסופק כהתקנה עצמאית ללא ConfigManagement Operator. אם אתם משדרגים מגרסה שקודמת ל-1.20.0 לגרסה 1.20.0 ואילך, קודם אתם צריכים להסיר את ConfigManagement Operator.

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

הסרת ConfigManagement Operator

אם אתם משדרגים מגרסה שקודמת ל-1.20.0 לגרסה 1.20.0 ואילך, אתם צריכים להסיר את ConfigManagement Operator לפני השדרוג.

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

kubectl get configmanagement

אם הפלט לא ריק, Config Management מותקן באשכול. כדי להסיר את Config Management, מבצעים את השלבים הבאים להסרת Config Management, אבל משאירים את סנכרון תצורות מותקן באשכול. מומלץ להשתמש ב-nomos CLI כדי להסיר את ConfigManagement Operator, כי יש לו ממשק עשיר יותר וטיפול חזק יותר בשגיאות. כדאי להשתמש בסקריפט המעטפת רק אם אין לכם גישה אל nomos CLI.

אזהרה: לפני שממשיכים, חשוב לוודא שHierarchy Controller מושבת.

nomos (מומלץ)

1. מוודאים שמותקנת הגרסה העדכנית של CLI של nomos.

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

   nomos migrate --remove-configmanagement
   

סקריפט מעטפת

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

 #!/bin/bash

 set -euox pipefail

 hnc_enabled="$(kubectl get configmanagements.configmanagement.gke.io config-management -o=jsonpath="{.spec.hierarchyController.enabled}" --ignore-not-found)"

 if [[ "${hnc_enabled}" == "true" ]]; then
   echo "Hierarchy Controller is enabled on the ConfigManagement object. It must be disabled before migrating."
   echo "This can be done by unsetting the spec.hierarchyController field on ConfigManagement."
   exit 1
 fi

 kubectl delete deployment -n config-management-system config-management-operator --ignore-not-found --cascade=foreground

 if kubectl get configmanagement config-management &> /dev/null ; then
   kubectl patch configmanagement config-management --type="merge" -p '{"metadata":{"finalizers":[]}}'
   kubectl delete configmanagement config-management --cascade=orphan --ignore-not-found
 fi

 kubectl delete clusterrolebinding config-management-operator --ignore-not-found
 kubectl delete clusterrole config-management-operator --ignore-not-found
 kubectl delete serviceaccount -n config-management-system config-management-operator --ignore-not-found
 kubectl delete customresourcedefinition configmanagements.configmanagement.gke.io --ignore-not-found

התקנת הגרסה החדשה של סנכרון תצורות

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

1. מורידים את המניפסט של סנכרון תצורות ואת פקודות nomos לגרסה החדשה.

2. מחלצים את הארכיון:

   tar -xzvf config-sync.tar.gz

3. בארכיון שחילצתם בשלב הקודם, פועלים לפי ההוראות בקובץ README.md שסופק כדי לערוך את ההתאמה האישית.

   הערה: צריך לערוך את kustomization.yaml בשביל הגדרות מסוימות, למשל הגדרת שם של אשכול לשימוש עם ClusterSelector או הכללת הקובץ admission-webhook.yaml לשימוש עם מניעת חריגה.

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

   kubectl apply -f CONFIG_SYNC_MANIFEST
   

   מחליפים את CONFIG_SYNC_MANIFEST בשם של המניפסט שעבר רינדור.

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

הסרת ההתקנה של "סנכרון תצורות"

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

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

1. אדמין מרכזי צריך להסיר את מאגר הבסיס:

   1. אם הפעלתם את ה-webhook ואתם רוצים לשמור את המשאבים, השביתו את מניעת השינויים במשאבים נטושים. אם לא הפעלתם את ה-webhook, אתם לא צריכים לבצע פעולות נוספות כדי לשמור על המשאבים שלכם.

   2. מוחקים את האובייקט RootSync באמצעות הפקודה הבאה:

      kubectl delete -f root-sync.yaml
      

2. מסירים את כל המאגרים.

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

      kubectl delete -f CONFIG_SYNC_MANIFEST --ignore-not-found
   

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

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

• איך מגדירים סנכרון מכמה מאגרים