במדריך הזה נסביר איך להגדיר את Config Sync ל-Google Kubernetes Engine בשתי סביבות, אחת לפיתוח ואחת לייצור, באמצעות שיטות מומלצות ל-Config Sync.
בתרחיש הזה, אתם חלק מצוות אדמינים של פלטפורמה בחברת Foo Corp. האפליקציות של Foo Corp נפרסות ב-GKE, והמשאבים מחולקים בין שני פרויקטים, dev ו-prod. הפרויקט dev מכיל אשכול GKE לפיתוח, והפרויקט prod מכיל אשכול GKE לייצור. המטרה שלכם כאדמינים של הפלטפורמה היא לוודא ששתי הסביבות עומדות בדרישות המדיניות של Foo Corp, ושהמשאבים ברמת הבסיס, כמו מרחבי שמות של Kubernetes וחשבונות שירות, נשארים עקביים בשתי הסביבות.
במדריך הזה נעשה שימוש בתכונת העיבוד האוטומטי ב-Config Sync כדי לעבד את המשאבים באשכול. כל אחד מהאשכולות מוגדר לסנכרון מספרייה שמכילה קובץ הגדרות של Kustomization, שמופעל אוטומטית בתהליך העיבוד ב-Config Sync. פרטים נוספים זמינים במאמר בנושא שימוש במאגר עם הגדרות Kustomize ועם תרשימי Helm.
במדריך הזה יוצרים את המשאבים הבאים:- שני Google Cloud פרויקטים שמייצגים את סביבות הפיתוח והייצור.
- שני אשכולות GKE,
devו-prod, בפרויקטים נפרדים, עם Config Sync מותקן.
ארכיטקטורת מאגר
במדריך הזה מגדירים את Config Sync כך שיסנכרן עם ההגדרות בספרייה config-source/ של מאגר הדוגמאות. הספרייה הזו מכילה את הספריות והקבצים הבאים:
config-source/
├── base
│ ├── foo
│ │ ├── kustomization.yaml
│ │ ├── namespace.yaml
│ │ └── serviceaccount.yaml
│ ├── kustomization.yaml
│ ├── pod-creator-clusterrole.yaml
│ └── pod-creator-rolebinding.yaml
├── cloudbuild.yaml
├── overlays
│ ├── dev
│ │ └── kustomization.yaml
│ └── prod
│ └── kustomization.yaml
└── README.md
הספרייה config-source כוללת את קובצי המניפסט base/ ואת שכבות העל של Kustomize dev/ ו-prod/. כל ספרייה מכילה קובץ kustomization.yaml, שמפרט את הקבצים ש-Kustomize צריכה לנהל ולהחיל על האשכול.
ב-dev/kustomization.yaml וב-prod/kustomization.yaml מוגדרת סדרה של תיקונים. התיקונים האלה משנים את משאבי base/ של הסביבה הספציפית.
לדוגמה, ה-RoleBinding של dev מאפשר לכל המפתחים ב-Foo Corp לפרוס Pods לאשכול dev, בעוד שה-RoleBinding של prod מאפשר רק לסוכן של פריסה רציפה, deploy-bot@foo-corp.com, לפרוס Pods לייצור:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
kind: ServiceAccount
name: foo-ksa
patch: |-
- op: replace
path: /metadata/name
value: foo-ksa-dev
- op: replace
path: /metadata/namespace
value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
kind: RoleBinding
name: pod-creators
patch: |-
- op: replace
path: /subjects/0/name
value: developers-all@foo-corp.com
commonLabels:
environment: dev
מטרות
- מגדירים את Config Sync כך שיבצע באופן אוטומטי עיבוד וסנכרון של ההגדרה עבור שתי הסביבות הנפרדות.
עלויות
במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:
כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.
כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.
לפני שמתחילים
לפני שמתחילים את המדריך הזה, חשוב לוודא שביצעתם את השלבים הבאים:
בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים או יוצרים שני פרויקטים ב- Google Cloud .
משדרגים את Google Cloud CLI לגרסה העדכנית.
מתקינים או משדרגים את הפקודה
nomos
יצירה ורישום של אשכולות
כדי שתוכלו להתמקד בתהליך העבודה שבו אתם צריכים להשתמש כשאתם מגדירים את Config Sync לכמה סביבות, בספרייה multi-environments-kustomize יש סקריפטים שבהם אתם יכולים להשתמש כדי להפוך את ההגדרה של Config Sync לאוטומטית.
משכפלים את המאגר לדוגמה:
git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.gitעוברים לתיקייה שמכילה את המשאבים שדרושים למדריך הזה:
cd anthos-config-management-samples/multi-environments-kustomize/כדי להריץ את הסקריפטים שבהם נעשה שימוש במדריך הזה, צריך להגדיר את המשתנים הבאים:
export DEV_PROJECT="DEV_PROJECT_ID" export PROD_PROJECT="PROD_PROJECT_ID" export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE" export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE" export CM_CONFIG_DIR="config-sync-rendering"מחליפים את מה שכתוב בשדות הבאים:
-
DEV_PROJECT_ID: מזהה הפרויקט מGoogle Cloud הפרויקט שרוצים להשתמש בו כפרויקט פיתוח -
PROD_PROJECT_ID: מזהה הפרויקט מתוךGoogle Cloud הפרויקט שרוצים להשתמש בו כפרויקט הייצור -
DEV_CLUSTER_ZONE: אזור Compute Engine שבו רוצים ליצור את אשכול הפיתוח. לדוגמה,us-central1-c. -
PROD_CLUSTER_ZONE: האזור ב-Compute Engine שבו רוצים ליצור את אשכול הייצור
-
כדי ליצור שני אשכולות, מריצים את הסקריפט
./create-clusters.sh:./create-clusters.shהסקריפט הזה יוצר אשכול GKE אחד בשם
devבפרויקט הפיתוח ואשכול GKE אחד בשםprodבפרויקט הייצור. הסקריפט הזה גם מפעיל את GKE API ומתחבר לאשכולותdevו-prodכדי שתוכלו לגשת לממשקי ה-API שלהם באמצעותkubectl.פלט לדוגמה:
kubeconfig entry generated for dev. Fetching cluster endpoint and auth data. kubeconfig entry generated for prod. ⭐️ Done creating clusters.כדי לרשום את האשכולות לשני צי GKE נפרדים, מריצים את הסקריפט
register-clusters.sh:./register-clusters.shהסקריפט הזה יוצר Google Cloud חשבון שירות ומפתח לרישום אשכולות GKE, ואז משתמש בפקודה
gcloud container fleet memberships registerכדי לרשום את האשכולותdevו-prodב-GKE בפרויקטים שלהם.פלט לדוגמה:
Waiting for Feature Config Management to be created...done. ⭐️ Done registering clusters.
הגדרת Config Sync
אחרי שיוצרים את האשכולות ורושמים אותם, אפשר להתקין את Config Sync ולאמת את ההתקנה.
התקנת Config Sync
כדי להתקין את Config Sync, מריצים את הסקריפט install-config-sync.sh באשכול הפיתוח ובאשכול הייצור:
./install-config-sync.sh
הפלט אמור להיראות כך:
🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.
הכלי Config Sync מסנכרן עכשיו את ההגדרות במאגרי המידע שלכם.
אימות ההגדרות את ההגדרות
בקטע הזה בודקים שהאשכולות מסתנכרנים עם ההגדרות במאגר:
כדי לבדוק את המצב של התקנת Config Sync, מריצים את הפקודה
nomos status:nomos statusאפשר לראות שגם אשכול הפיתוח וגם אשכול הייצור מסונכרנים עכשיו עם המאגרים המתאימים שלהם:
gke_DEV_PROJECT_ID_us-central1-c_dev -------------------- <root> https://github.com/GoogleCloudPlatform/anthos-config-management-samples/multi-environments-kustomize/config-source/overlays/dev@main SYNCED 8f2e196f Managed resources: NAMESPACE NAME STATUS clusterrole.rbac.authorization.k8s.io/pod-creator Current namespace/default Current namespace/foo Current default rolebinding.rbac.authorization.k8s.io/pod-creators Current foo serviceaccount/foo-ksa-dev Current *gke_PROD_PROJECT_ID_us-central1-c_prod -------------------- <root> https://github.com/GoogleCloudPlatform/anthos-config-management-samples/multi-environments-kustomize/config-source/overlays/prod@main SYNCED c91502ee Managed resources: NAMESPACE NAME STATUS clusterrole.rbac.authorization.k8s.io/pod-creator Current namespace/default Current namespace/foo Current default rolebinding.rbac.authorization.k8s.io/pod-creators Current foo serviceaccount/foo-ksa-prod Current ```כדי לעבור לאשכול הפיתוח, משתמשים ב-
kubectl:kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"כדי לוודא שהמשאבים מסונכרנים, צריך לקבל מרחבי שמות. אמור להופיע מרחב השמות
foo.kubectl get namespaceפלט לדוגמה:
NAME STATUS AGE config-management-monitoring Active 9m38s config-management-system Active 9m38s default Active 47h foo Active 9m5s kube-node-lease Active 47h kube-public Active 47h kube-system Active 47h resource-group-system Active 9m30sהגדרתם עכשיו עיבוד אוטומטי של הגדרות עבור סביבת פיתוח וסביבת ייצור, במספר פרויקטים וסביבות של Google Cloud .
הסרת המשאבים
כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים, או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.
מחיקת כל המשאבים
כדי למחוק את המשאבים שיצרתם במדריך הזה, אבל לשמור את פרויקטי הפיתוח והייצור, מריצים את סקריפט הניקוי:
./cleanup.sh
מחיקת הפרויקטים
- במסוף Google Cloud , נכנסים לדף Manage resources.
- ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
- כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.