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

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

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

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

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

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

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

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

  • ‫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. כדי לקבל את ההרשאה הזו, צריך להקצות את תפקיד ה-IAM ‏Service Account Admin ‏(roles/iam.serviceAccountAdmin). יכול להיות שתוכלו לקבל את ההרשאה הזו גם בתפקידים בהתאמה אישית או בתפקידים אחרים שמוגדרים מראש.

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

רישום אשכול

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

  1. פריסה של סנכרון תצורות
  2. נותנים ל-Config Sync הרשאת קריאה בלבד לאחד מהבאים:
  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 סוד, סנכרון תצורות יזהה את ה-Secret ברגע שתיצרו אותו, ולא תצטרכו להחיל מחדש את ההגדרה.

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

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

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

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

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

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

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

  • זוג מפתחות SSH‏ (ssh)
  • Cookiefile (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 של 4096 ביט. לא מומלץ להשתמש בערכים נמוכים יותר:

    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, מומלץ להשתמש בחשבון נפרד.

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

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

    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://EMAIL@source.developers.google.com:2022/p/PROJECT_ID/r/REPO_NAME

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

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

Cookiefile

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

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

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

    אם אתם לא משתמשים בשרת 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

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

אסימון

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

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

  1. כדי ליצור טוקן באמצעות GitHub,‏ GitLab או Bitbucket:

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

    אם אתם לא משתמשים בשרת 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.

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

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

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

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

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

    Cloud Source Repositories

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

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

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

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

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

    Secure Source Manager

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

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

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

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

    • כדי להעניק הרשאות ספציפיות למאגר, אפשר להשתמש בממשק האינטרנט של 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 חולקים את אותו מאגר של איחוד זהויות של עומסי עבודה (WIF) עבור GKE. במסגרת הקונספט של זהות בצי, אם מוסיפים את מדיניות IAM לחשבון שירות Kubernetes באשכול אחד, חשבון שירות Kubernetes מאותו מרחב שמות באשכולות אחרים באותו צי מקבל גם את אותה מדיניות IAM.

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

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

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

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

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

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

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

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

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

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

מחליפים את 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 בכתובת הבסיסית של נקודת קצה ל-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 בכתובת הבסיסית של נקודת קצה ל-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

אתם יכולים להשתמש ב-ServiceAccount של Kubernetes כסוג האימות אם אתם מאחסנים את תמונת ה-OCI ב-Artifact Registry והאשכול שלכם משתמש ב-GKE Workload Identity Federation for GKE או ב-fleet Workload Identity Federation for GKE.

מקצים את התפקיד 'קורא Artifact Registry' (roles/artifactregistry.reader) בפרויקט או במאגר לחשבון השירות של Kubernetes. מידע נוסף על תפקידים והרשאות ב-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.svc.id.goog/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.svc.id.goog/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_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים ב-Workload Identity Federation for GKE ב-Fleet, זהו מזהה הפרויקט של ה-Fleet שהאשכול רשום בו.
  • ‫KUBERNETES_SERVICEACCOUNT: חשבון השירות של Kubernetes בשביל הכלי להשוואה:
  • אם שם מאגר הבסיס RootSync הוא root-sync, משתמשים ב-root-reconciler. אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME. אם מתקינים את סנכרון תצורות באמצעות מסוף Google Cloud או Google Cloud CLI,‏ סנכרון תצורות יוצר באופן אוטומטי אובייקט RootSync בשם root-sync.
  • ‫REPOSITORY: מזהה המאגר.
  • ‫LOCATION: המיקום האזורי או הרב-אזורי של המאגר.

חשבון השירות של 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@developer.gserviceaccount.com \
   --role=roles/artifactregistry.reader

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

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

בשרתים שהוגדרו עם אישורים מרשות אישורים (CA) שלא נחשבת כבר כמהימנה, אפשר להגדיר את סנכרון תצורות לשימוש באישור CA כדי לאמת חיבורי HTTPS לשרת. המאפיין הזה נתמך בשרתי Git,‏ Helm או OCI. אישור ה-CA צריך לכלול אישורי SSL מלאים (בסיס/ביניים/עלה). אם השרת שלכם כבר משתמש ב-CA מהימן או שאתם לא מתחברים דרך 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 ל-Config Sync

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

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

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

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

אסימון

יוצרים 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. מידע נוסף על תפקידים והרשאות ב-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.svc.id.goog/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.svc.id.goog/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_HOST_PROJECT_ID: אם אתם משתמשים באיחוד זהויות של עומסי עבודה ל-GKE, הערך הזה זהה לערך של PROJECT_ID. אם אתם משתמשים ב-Workload Identity Federation for GKE ב-Fleet, זהו מזהה הפרויקט של ה-Fleet שהאשכול רשום בו.
  • ‫KUBERNETES_SERVICEACCOUNT: חשבון השירות של Kubernetes בשביל הכלי להשוואה:
  • אם שם מאגר הבסיס RootSync הוא root-sync, משתמשים ב-root-reconciler. אחרת, משתמשים ב-root-reconciler-ROOT_SYNC_NAME.
  • ‫REPOSITORY: מזהה המאגר.
  • ‫LOCATION: המיקום האזורי או הרב-אזורי של המאגר.

חשבון השירות של 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@developer.gserviceaccount.com \
    --role=roles/artifactregistry.reader

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

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

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

  1. אם אתם משתמשים ב-webhook של Config Sync admission (ה-webhook של admission מושבת כברירת מחדל) ומתקינים את סנכרון תצורות באשכול פרטי, צריך להוסיף כלל חומת אש כדי לאפשר את היציאה 10250. ה-webhook של סנכרון תצורות admission משתמש ביציאה 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.iam.gserviceaccount.com.

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

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

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

      מידע נוסף על הגדרת אובייקט Secret עבור אישור 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
    • ‫ROOT_DIRECTORY: מוסיפים את הנתיב במאגר לספריית הבסיס שמכילה את ההגדרה שרוצים לסנכרן. השדה הזה הוא אופציונלי, וערך ברירת המחדל הוא ספריית הבסיס (/) של המאגר.

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

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

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

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

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

    מידע נוסף על הגדרת אובייקט Secret עבור אישור CA זמין במאמר הגדרת רשות אישורים

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

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

    Helm

    # 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.iam.gserviceaccount.com.

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

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

    מידע נוסף על הגדרת אובייקט Secret עבור אישור 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>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4

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

כשיוצרים אובייקט RootSync, ‏ סנכרון תצורות יוצר reconciler עם הקידומת root-reconciler. תהליך ההתאמה הוא Pod שמוגדר כפריסה. הוא מסנכרן מניפסטים ממאגר 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, ‏ Config Sync מסופק כהתקנה עצמאית ללא ConfigManagement Operator. אם אתם משדרגים מגרסה קודמת לגרסה 1.20.0 או לגרסה מאוחרת יותר, אתם צריכים קודם להסיר את ConfigManagement Operator לפני השדרוג.

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

הסרת האופרטור ConfigManagement

אם אתם משדרגים מגרסה שלפני 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.

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

  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 שסופק, עורכים את ההתאמה האישית בארכיון שחולץ בשלב הקודם.

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

    kubectl apply -f CONFIG_SYNC_MANIFEST

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

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

הסרת סנכרון תצורות

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

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

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

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

      kubectl delete -f root-sync.yaml

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

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

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

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