כלי שורת הפקודה nomos הוא כלי אופציונלי ל-Config Sync שבו אפשר להשתמש כדי לקבל את הסטטוס של Config Sync ואת סטטוס הסנכרון של מקור האמת. הכלי nomos מספק את הפקודות הבאות:
| פקודה | Usage |
|---|---|
nomos status |
בדיקת הסטטוס של סנכרון התצורות |
nomos vet |
בדיקה אם יש שגיאות במקור האמת |
nomos hydrate |
הצגת כל ההגדרות במקור האמת |
nomos bugreport |
יצירת דוח איתור באגים |
nomos migrate |
העברה מאובייקט ConfigManagement אל RootSync |
nomos init |
איך מאתחלים מקור קובע היררכי |
דרישות מוקדמות
כדי להשתמש בכלי nomos לאינטראקציה עם אשכול, צריך להתקין את Config Sync באשכול היעד. צריך גם להתקין ולהגדיר את כלי שורת הפקודה kubectl.
אם אתם מבצעים אינטראקציה עם אשכולות של Google Kubernetes Engine, אתם צריכים לוודא שאתם מתקינים גם את gke-gcloud-auth-plugin.
הכלי nomos תומך בתצוגה מקדימה ובאימות של הגדרות Kustomize ושל תרשימי Helm. כדי להשתמש בתכונה הזו, צריך להתקין את Kustomize ואת Helm בתחנת העבודה המקומית. אם מקור האמת שלכם מכיל רק הגדרות שעברו רינדור מלא, השימוש ב-Kustomize וב-Helm הוא אופציונלי.
התקנת הכלי nomos
הכלי nomos הוא קובץ בינארי שעבר קומפילציה מקוד Go, ואפשר להתקין אותו באופן מקומי, למשל בתחנת עבודה או במחשב נייד.
הכלי nomos לא נכלל כשמתקינים את Config Sync. אפשר להתקין את הכלי nomos באמצעות התקנה של Google Cloud CLI. אם אתם משתמשים ב-Cloud Shell, Google Cloud CLI מותקן מראש.
אם אין לכם Google Cloud CLI, מומלץ להשתמש ב-gcloud components install nomos כדי להתקין את הכלי nomos. התקנת הכלי nomos באמצעות Google Cloud CLI מאפשרת לכם להשתמש ב-gcloud components update כדי לעדכן את הכלי nomos לגרסה האחרונה.
מידע על דרכים חלופיות להתקנת הכלי nomos זמין במאמר הורדות.
שימוש בסיסי
כדי להציג את תחביר הפקודה הבסיסי, משתמשים בארגומנט --help:
nomos --help
הכלי nomos קורא מהשיבוט המקומי של מקור האמת. משתמשים בדגל --path כדי לציין את המיקום של הרמה העליונה של מקור האמת. כברירת מחדל, --path מוגדר כ-. או כספרייה הנוכחית. לדוגמה:
nomos vet --path=PATH_TO_SOURCE --source-format unstructured
בדיקת הסטטוס של Config Sync
כדי לעקוב אחרי הסטטוס של Config Sync בכל האשכולות הרשומים, אפשר להשתמש בפקודה nomos status. בכל אשכול, nomos status מדווח על הגיבוב של הקומיט שהוחל על האשכול לאחרונה, ועל כל השגיאות שקרו במהלך הניסיון להחיל שינויים מהזמן האחרון.
אפשר גם להשתמש ב-nomos status כדי לבדוק אם המשאבים שמנוהלים על ידי Config Sync מוכנים. nomos status מדווח על הסטטוס של כל משאב בודד בעמודה STATUS בקטע Managed resources של הפלט.
בדוגמה הבאה מוצגים כמה מהתנאים השונים שעליהם יכולה לדווח הפקודה nomos status:
nomos status
פלט לדוגמה:
MANAGED_CLUSTER_1
--------------------
<root> git@github.com:foo-corp/acme@main
SYNCED f52a11e4
Managed resources:
NAMESPACE NAME STATUS
k8snoexternalservices.constraints.gatekeeper.sh/no-internet-services Current
namespace/hello Current
MANAGED_CLUSTER_2
--------------------
<root> git@github.com:foo-corp/acme@main
PENDING 9edf8444
MANAGED_CLUSTER_3
--------------------
<root> git@github.com:foo-corp/acme@main
ERROR f52a11e4
Error: KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.
MANGED_CLUSTER_4
--------------------
NOT INSTALLED
MANAGED_CLUSTER_5
--------------------
<root> git@github.com:foo-corp/acme/admin@main
SYNCED f52a11e4
Managed resources:
NAMESPACE NAME STATUS
namespace/gamestore Current
namespace/monitoring Current
gamestore reposync.configsync.gke.io/repo-sync Current
gamestore rolebinding.rbac.authorization.k8s.io/gamestore-admin Current
gamestore rolebinding.rbac.authorization.k8s.io/gamestore-webstore-admin Current
monitoring deployment.apps/prometheus-operator Current
monitoring prometheus.monitoring.coreos.com/acm Current
monitoring service/prometheus-acm Current
monitoring service/prometheus-operator Current
monitoring serviceaccount/prometheus-acm Current
monitoring serviceaccount/prometheus-operator Current
monitoring servicemonitor.monitoring.coreos.com/acm-service Current
--------------------
bookstore git@github.com:foo-corp/acme/bookstore@v1
SYNCED 34d1a8c8
Managed resources:
NAMESPACE NAME STATUS
gamestore configmap/store-inventory Current
gamestore webstore.marketplace.com/gameplace Current
בפלט הזה:
MANAGED_CLUSTER_1סנכרן את השינוי האחרון למקור האמת, ולכל המשאבים המנוהלים יש סטטוסCurrent. סטטוסCurrentמציין שהמצב של המשאב תואם למצב שרציתם.- הסנכרון של
MANAGED_CLUSTER_2עדיין מתבצע. - ב-
MANAGED_CLUSTER_3יש שגיאה שמנעה את החלת השינוי. בדוגמה הזו,MANAGED_CLUSTER_3כולל את השגיאה KNV1021 כי חסר בו CustomResourceDefinition (CRD) שמותקן באשכולות האחרים. -
MANAGED_CLUSTER_4לא מותקן Config Sync. -
MANAGED_CLUSTER_5מסתנכרן משני מאגרי Git.<root>מקור המידע האמין שייך לאדמין של האשכול, וbookstoreמקור המידע האמין יכול להיות שייך לצוות פיתוח אפליקציות.
סטטוסים של משאבים מנוהלים
הסטטוס של המשאבים המנוהלים יכול להיות אחד מהערכים הבאים:
InProgress: המצב בפועל של המשאב עדיין לא הגיע למצב שצוין במניפסט המשאב. הסטטוס הזה מציין שהתאמת המשאבים עדיין לא הושלמה. משאבים שנוצרו לאחרונה מתחילים בדרך כלל עם הסטטוס הזה, אבל יש משאבים כמו ConfigMaps שמתחילים בסטטוסCurrentבאופן מיידי.
Failed: אירעה שגיאה בתהליך של השוואת המצב בפועל למצב הרצוי, או שלא חל בו שיפור מספיק.
Current: המצב בפועל של המשאב תואם למצב הרצוי. תהליך ההתאמה נחשב למושלם עד שיש שינויים במצב הרצוי או במצב בפועל.
Terminating: המשאב נמצא בתהליך מחיקה.
NotFound: המשאב לא קיים באשכול.
Unknown: Config Sync לא מצליח לקבוע את הסטטוס של המשאב.
כדי להפסיק את הצגת הסטטוס ברמת המשאב, מוסיפים את האפשרות --resources=false לפקודה nomos status.
מידע על השמירה האחרונה שסונכרנה
הפקודה nomos status מציגה בפלט שלה את הגיבוב (hash) של הקומיט האחרון שהוחל על האשכול, בקטע status.sync.commit. כדי לקבל את הערך הזה, שולחים שאילתה לאובייקט RootSync או RepoSync ומסתכלים על השדה status.sync.
לדוגמה, כדי לשלוח שאילתה לאובייקט RootSync, מריצים את הפקודה הבאה:
kubectl get rootsyncs.configsync.gke.io -n config-management-system root-sync -o yaml
פלט לדוגמה:
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
status:
sync:
commit: f1739af550912034139aca51e382dc50c4036ae0
lastUpdate: "2021-04-20T00:25:01Z"
כדי לשלוח שאילתה לאובייקט RepoSync, מריצים את הפקודה הבאה:
kubectl get reposync.configsync.gke.io -n NAMESPACE repo-sync -o yaml
מחליפים את NAMESPACE במרחב השמות שבו יצרתם את מקור האמת של מרחב השמות.
פלט לדוגמה:
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
status:
sync:
commit: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
lastUpdate: "2021-04-20T00:25:20Z"
הקומִיט הזה מייצג את הקומִיט האחרון שבוצע מול האשכול. עם זאת, לא כל משאב באשכול מושפע מכל פעולת commit. כדי לראות את פעולת ה-commit האחרונה למשאב ספציפי, צריך לשלוח שאילתה למשאב הספציפי ולבדוק את metadata.annotations.configmanagement.gke.io/token. לדוגמה:
kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml
מחליפים את CLUSTER_ROLE_NAME בשם של תפקיד האשכול שרוצים לשלוח לו שאילתה.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
configmanagement.gke.io/token: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
nomos status flags
כדי להתאים אישית את הפקודה nomos status, מוסיפים את הדגלים הבאים:
| דגל | תיאור |
|---|---|
--contexts |
מקבל רשימה של הקשרים שמופרדים בפסיקים לשימוש בפקודות מרובות אשכולות. ברירת המחדל היא כל ההקשרים. אם לא רוצים להשתמש בהקשרים, משתמשים ב-"". |
-h או --help |
עזרה בפקודה nomos status. |
--name |
מקבל מחרוזת. משתמשים בדגל הזה כדי לסנן את Root ואת Repo Sync עם השם שצוין. אפשר להשתמש בדגל הזה לצד הדגל namespace. |
--namespace |
מקבל מחרוזת. משתמשים בדגל namespace כדי להגביל את הפקודה למרחב שמות ספציפי של מקור האמת. אם לא מגדירים את המדיניות, מקבלים את כל המקורות. הדגל הזה זמין רק אם הפעלתם סנכרון מכמה מקורות אמת. |
--poll |
משתמשים בדגל poll כדי להריץ את nomos status באופן רציף ולגרום לו להדפיס מחדש את טבלת הסטטוס במרווחי זמן קבועים. לדוגמה 3s. כדי להריץ את nomos status פעם אחת, לא מגדירים את הדגל הזה. |
--resources |
מקבלים true או false. אם הערך הוא true, הפקודה nomos status מציגה את הסטטוס ברמת המשאב של מקור האמת הבסיסי או של מרחב השמות כשמסנכרנים מכמה מקורות אמת.
ערך ברירת המחדל הוא true. |
--timeout |
פרק הזמן הקצוב לחיבור לכל אשכול. ערך ברירת המחדל הוא 3s. |
ההרשאות הנדרשות
אם אתם בעלי הפרויקט, יש לכם את תפקיד ה-RBAC cluster-admin ואתם יכולים להשתמש בפקודה nomos status לכל אשכול בפרויקט בלי להוסיף הרשאות נוספות. אם אין לכם את התפקיד cluster-admin, אתם יכולים להשתמש ב-nomos status על ידי יצירת ClusterRole הבא:
יוצרים קובץ בשם
nomos-status-reader.yamlומעתיקים אליו את ClusterRole הבא. הכללים שצריך להגדיר תלויים בשימוש באובייקטים של RootSync ו-RepoSync.שימוש באובייקטים של RootSync ו-RepoSync
# nomos-status-reader.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nomos-status-reader rules: - apiGroups: ["configsync.gke.io"] resources: ["reposyncs", "rootsyncs"] verbs: ["get"] - nonResourceURLs: ["/"] verbs: ["get"]לא משתמשים באובייקטים של RootSync ו-RepoSync
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: nomos-status-reader rules: - apiGroups: ["configmanagement.gke.io"] resources: ["configmanagements", "repos"] verbs: ["get", "list"] - nonResourceURLs: ["/"] verbs: ["get"]מחילים את הקובץ
nomos-status-reader.yaml:kubectl apply -f nomos-status-reader.yaml
בדיקת שגיאות במקור האמת
לפני שמאשרים הגדרה במקור האמת, משתמשים בפקודה nomos vet כדי לבדוק את התחביר והתוקף של ההגדרות במקור האמת:
nomos vet --source-format unstructured
אם נמצאות שגיאות תחביר, הפקודה nomos vet יוצאת עם סטטוס שאינו אפס ורושמת הודעות שגיאה ב-STDERR.
nomos vet flags
כדי להתאים אישית את הפקודה nomos vet, מוסיפים את הדגלים הבאים:
| דגל | תיאור |
|---|---|
--api-server-timeout |
מקבלת מחרוזת של משך זמן. הגדרה של פסק זמן בצד הלקוח לתקשורת עם שרת Kubernetes API. ברירת המחדל היא 15s. |
--clusters |
מקבל רשימה של שמות אשכולות שמופרדים בפסיקים, לשימוש בפקודות של כמה אשכולות. ברירת המחדל היא כל האשכולות. משתמשים ב-"" אם לא רוצים להשתמש באשכולות. |
--format |
מקבלים yaml או json. הפורמט של הפלט. ערך ברירת המחדל הוא yaml. |
-h או --help |
עזרה בפקודה nomos vet. |
--keep-output |
מקבל ערך בוליאני. אם true, הפלט שעבר עיבוד נשמר במיקום שאפשר לציין באמצעות הדגל --output. |
--namespace |
מקבל מחרוזת. אם המדיניות מוגדרת, המערכת מאמתת את מקור האמת כשם מרחב
שמות של מקור האמת עם השם שצוין. הגדרה אוטומטית של
--source-format=unstructured. |
--no-api-server-check |
מקבל ערך בוליאני. אם true, הגישה לשרת Kubernetes API לצורך גילוי מושבתת. מידע נוסף על הדגל הזה זמין בקטע אימות בצד השרת. |
--output |
מקבל מחרוזת. הנתיב לפלט שעבר עיבוד. ברירת המחדל היא הספרייה compiled. אם המדיניות --keep-output מוגדרת לערך false, המערכת מתעלמת מהדגל הזה. |
--path |
מקבל מחרוזת. הנתיב לספריית הבסיס של מקור המידע האמין של Config Sync. ברירת המחדל היא "." |
--source-format |
מקבלים hierarchy או unstructured. If
hierarchy or unset, validates the source of truth as a
hierarchical source of truth. If
unstructured, validates the source of truth as an
unstructured source of truth.
חובה להשתמש בדגל הזה אם אתם משתמשים במקור אמת לא מובנה. |
--threshold |
אפשר להזין מספר שלם. הגדרת המספר המקסימלי של אובייקטים שמותרים לכל מאגר. אם חורגים מהמספר הזה, מוצגת שגיאה. כדי להשבית את האימות של מספר האובייקטים המקסימלי, משמיטים את הדגל או משתמשים בדגל --threshold=0.
כדי להשתמש בערך ברירת המחדל 1000, מציינים את הדגל ללא ערך. כדי להגדיר מגבלה ספציפית, משתמשים בערך --threshold=N. |
אימות בצד השרת
אם הפקודה nomos vet לא יכולה לקבוע אם הסוג הוא במרחב שמות, הכלי nomos מתחבר לשרת ה-API של ההקשר הנוכחי kubectl. כברירת מחדל, הכלי nomos מבין סוגים בסיסיים של Kubernetes ו-CRD של Config Sync, ולכן הוא מנסה להתחבר לשרת ה-API רק אם ל-CR אין CRD מוצהר תואם. במקרה כזה, אם ה-CRD לא הוחל על שרת ה-API, הפקודה nomos
vet מחזירה את השגיאה KNV1021. כדי להשבית את הבדיקה הזו ולמנוע שגיאות מ-CRD חסרים, מעבירים את הדגל --no-api-server-check.
שמירת מטא-נתונים של שרת API במטמון
במקום להשבית את הבדיקות של שרת ה-API, אפשר לשמור את הנתונים במטמון בשרת ה-API עבור הפקודה nomos vet. כדי לשמור את api-resources במטמון, פועלים לפי השלבים הבאים:
- מתחברים לאשכול שמכיל את כל ה-CRD שדרושים למקור האמת. לא צריך להפעיל את Config Sync באשכול.
- עוברים אל policyDir של מקור האמת. זו אותה ספרייה שצוינה במשאב ConfigManagement או RootSync.
- מריצים את הפקודה הבאה:
kubectl api-resources > api-resources.txtהפקודה הזו יוצרת קובץ בשם api-resources.txt שמכיל את הפלט המדויק של kubectl api-resources.
מעכשיו, הפעלות של nomos vet במקור האמת מודעות להגדרות הסוגים האלה. אם הקובץ api-resources.txt מוסר או משנה את השם, nomos vet לא יכול למצוא את הקובץ. nomos vet עדיין ינסה להתחבר לאשכול אם הוא ימצא מניפסטים לסוגים שלא הוגדרו ב-api-resources.txt (אלא אם הועבר --no-api-server-check).
קובץ ה-api-resources.txt משפיע רק על אופן הפעולה של הכלי nomos. היא לא משנה את אופן הפעולה של Config Sync בשום צורה.
אפשר להוסיף לקובץ api-resources.txt רשומות נוספות שמתייחסות לסוגים שלא נמצאים במקור האמת שעובר אימות. nomos vet מייבא את ההגדרות, אבל לא עושה איתן שום דבר.
עדכון הקובץ api-resources.txt
אחרי שמוודאים שכל ה-CRD שרוצים נמצאים באשכול, מריצים את הפקודה הבאה:
kubectl api-resources > api-resources.txt
בדיקה אוטומטית של שגיאות תחביר כשמבצעים קומיט
אם מבצעים קומיט של קובץ עם שגיאות JSON או YAML, Config Sync לא מחיל את השינוי. עם זאת, אפשר למנוע את השגיאות האלה באמצעות שימוש ב-hooks בצד הלקוח או בצד השרת.
שימוש ב-nomos vet ב-pre-commit hook
אתם יכולים להגדיר pre-commit hook שמריץ את הפקודה nomos vet כדי לבדוק אם יש שגיאות תחביר כשאתם מבצעים commit של שינוי בשיבוט Git המקומי של המאגר.
אם פעולת ה-hook לפני הקומיט מסתיימת עם סטטוס שאינו אפס, הפעולה git commit נכשלת.
כדי להריץ את הפקודה nomos vet כ-pre-commit hook, עורכים את הקובץ .git/hooks/pre-commit במקור האמת (שימו לב שהקובץ .git מתחיל בתו .). יכול להיות שתצטרכו ליצור את הקובץ באופן ידני. מוסיפים את הפקודה nomos vet
לשורה חדשה בתסריט. הארגומנט --path הוא אופציונלי. מגדירים את הארגומנט
--source-format לפורמט המקור של המאגר.
nomos vet --path=/path/to/repo --source-format unstructured
מוודאים שקובץ pre-commit ניתן להרצה:
chmod +x .git/hooks/pre-commit
עכשיו, כשמריצים פקודה של git commit בשיבוט של מקור האמת, nomos vet פועל באופן אוטומטי.
התוכן של ספריית .git/ לא מתועד במקור האמת עצמו, ואי אפשר להוסיף אותו למקור האמת באותו מיקום. אפשר ליצור ספרייה במקור המידע האמין עבור Git hooks, ואנשים שמשתמשים במקור המידע האמין יכולים להעתיק את ה-hooks למקום המתאים בעותק המקומי שלהם.
שימוש ב-nomos vet ב-hook בצד השרת
Git מספק מנגנון להפעלת בדיקות בשרת, ולא בלקוח, במהלך פעולת git push. אם הבדיקה נכשלת, גם git push נכשל. הלקוח לא יכול לעקוף את ה-hooks האלה בצד השרת. השיטה להגדרת ווים בצד השרת תלויה באופן האירוח של שרת ה-Git. למידע נוסף, אפשר לעיין באחד מהקישורים הבאים או במסמכי העזרה של שירות אחסון ה-Git שלכם.
הגדרת מספר מקסימלי של אובייקטים לסנכרון
Config Sync שומר הפניה לכל אובייקט שהוא מסנכרן באובייקט מלאי ResourceGroup, יחד עם הסטטוס הנוכחי של האובייקט. ל-Kubernetes יש מגבלה על גודל בבייט של אובייקטים של משאבים, ולכן יש מגבלה על המספר המקסימלי של אובייקטים ש-Config Sync יכול לסנכרן עם RootSync או RepoSync יחיד.
כברירת מחדל, מגבלת הגודל של etcd בצד השרת היא 1.5 MiB. פרטים נוספים זמינים במסמכי התיעוד של etcd. החלת אובייקט שגדול מהמגבלה הזו גורמת לאחת מהשגיאות הבאות, בהתאם לגודל האובייקט:
etcdserver: request is too largerpc error: code = ResourceExhausted desc = trying to send message larger than maxRequest entity too large: limit is 3145728
כדי למנוע חריגה ממגבלת הגודל של Kubernetes באובייקטים מסוג ResourceGroup, אפשר להשתמש ב-nomos vet --threshold כדי לאמת את מספר האובייקטים במאגר המקור.
כברירת מחדל, כשמשתמשים בפקודה nomos vet, לא נאכף סף.
העברת הדגל --threshold תגרום לפקודה vet להחזיר שגיאה אם מספר האובייקטים במאגר המקור חורג מהסף.
המלאי של ResourceGroup מכיל הפניות לאובייקטים ואת הסטטוס הנוכחי של האובייקט. הוא יכול לגדול במיוחד אם האובייקטים לא מסתנכרנים או לא מתעדכנים.
כדי להימנע מחריגה ממגבלת הגודל של אובייקט Kubernetes, צריך לבחור סף שישאיר מספיק קיבולת לרישום שגיאות באובייקט. ערך ברירת המחדל של 1000 אמור להתאים כמעט לכל המקרים, אבל אפשר להעלות או להוריד את סף הרגישות לפי הצורך.
הסף הזה מאומת רק על ידי הפקודה nomos vet, ולא על ידי Config Sync עצמו. כדי לאכוף את הסף, משתמשים בפקודה nomos vet --threshold בבדיקה לפני שליחה במאגר מקור או בוו לפני ביצוע commit ב-Git.
הצגת כל ההגדרות במקור האמת
אפשר להשתמש בפקודה nomos hydrate כדי לראות את התוכן המשולב של מקור האמת בכל אשכול רשום.
אם מריצים את הפקודה nomos hydrate ללא אפשרויות, נוצרת ספרייה compiled/ בספריית העבודה הנוכחית. בספרייה הזו נוצרת ספריית משנה לכל אשכול רשום, עם ההגדרות שפוענחו במלואן שהאופרטור יחיל על האשכול.
הפקודה הזו יכולה גם להמיר מקור אמת היררכי
למקור אמת לא מובנה אחד או יותר,
באמצעות התוכן בספרייה compiled/.
nomos hydrate flags
כדי להתאים אישית את הפקודה nomos hydrate, מוסיפים את הדגלים הבאים:
| דגל | תיאור |
|---|---|
--api-server-timeout |
מקבלת מחרוזת של משך זמן. הגדרה של פסק זמן בצד הלקוח לתקשורת עם שרת Kubernetes API. ברירת המחדל היא 15s. |
--clusters |
הפרמטר מקבל רשימה של שמות אשכולות, מופרדים בפסיקים. משתמשים בדגל הזה כדי להגביל את הפלט לאשכול אחד או לרשימה של אשכולות. ברירת המחדל היא כל האשכולות. משתמשים ב-"" אם לא רוצים להשתמש באשכולות. |
--flat |
אם האפשרות הזו מופעלת, כל הפלט מודפס לקובץ אחד. משתמשים בדגל הזה אם רוצים
לחקות את ההתנהגות של nomos view. |
--format |
אפשר להזין בו את הערך yaml או json. הפורמט של הפלט. ערך ברירת המחדל הוא yaml. |
-h או --help |
עזרה בפקודה nomos hydrate. |
--no-api-server-check |
מקבל ערך בוליאני. אם true, ההגדרה משביתה את התקשורת עם שרת ה-API לצורך גילוי. מידע נוסף על הדגל הזה זמין בקטע אימות בצד השרת. |
--output |
מקבל מחרוזת. המיקום שבו ייכתבו ההגדרות של המאזן. ברירת המחדל היא הספרייה compiled.
אם האפשרות --flat לא מופעלת, כל מניפסט של משאב נכתב כקובץ נפרד.
אם האפשרות --flat מופעלת, נכתב קובץ יחיד שמכיל את כל מניפסטים של המשאבים.
|
--path |
מקבל מחרוזת. הנתיב לספריית הבסיס של מקור המידע האמין של Config Sync. ברירת המחדל היא "." |
--source-format |
מקבלים hierarchy או unstructured. If
hierarchy or unset, validates the source of truth as a
hierarchical source of truth. If
unstructured, validates the source of truth as an
unstructured source of truth.
חובה להשתמש בדגל הזה אם אתם משתמשים במקור אמת לא מובנה. |
יצירת דוח על באג
אם נתקלתם בבעיה ב-Config Sync שדורשת עזרה מGoogle Cloud התמיכה, תוכלו להשתמש בפקודה nomos bugreport כדי לקבל מידע חשוב לניפוי באגים. אפשר להשתמש בפקודה הזו כמקור קובע יחיד לכמה מאגרי קוד.
nomos bugreport
הפקודה הזו יוצרת קובץ ZIP עם חותמת זמן שמכיל מידע על אשכול Kubernetes שהוגדר בהקשר kubectl. הקובץ מכיל גם יומנים מ-Config Sync Pods. הוא לא מכיל מידע מהמשאבים שמסונכרנים עם Config Sync. מידע נוסף על התוכן של קובץ ה-ZIP זמין במאמר nomos bugreport reference.
מגבלות
הפקודה nomos bugreport נכשלת ויוצרת קובץ ZIP לא שלם אם קובץ כלשהו גדול מ-1GiB. לרוב זה קורה בגלל קובצי יומן גדולים.
בטבלה הבאה מפורטות הסיבות הנפוצות ביותר לגודל גדול של קובצי יומן, ואיך אפשר לפתור את הבעיות האלה:
| מטרה | הפעולה המומלצת |
|---|---|
| רמת פירוט גבוהה יותר ביומן | הפחתת רמת הפירוט של היומן באמצעות החלפות של רמת היומן |
| אובייקטים גדולים מאוד | ביטול הניהול של האובייקט הגדול או הקטנת הגודל שלו |
| אובייקטים רבים | פיצול המאגר למספר מאגרים |
| קרבות עם שלטים | לפתור את הריב |
העברה מאובייקט ConfigManagement לאובייקט RootSync
אפשר להריץ את הפקודה nomos migrate כדי לבצע מיגרציה מאובייקט ConfigManagement לאובייקט RootSync, וכך להפעיל את ממשקי ה-API RootSync ו-RepoSync.
nomos migrate תומך בהרצה יבשה כדי לראות תצוגה מקדימה של תהליך ההעברה.
nomos migrate משנה ישירות את אובייקט ConfigManagement באשכול.
כדי למנוע את ביטול השינויים שבוצעו באמצעות nomos migrate, צריך לוודא שאובייקט ConfigManagement לא נבדק במקור האמת.
nomos migrate --contexts=KUBECONFIG_CONTEXTS --dry-run
אם התוצאה של ההרצה היבשה נראית תקינה, אפשר להעביר את אובייקט ConfigManagement באמצעות nomos migrate:
nomos migrate --contexts=KUBECONFIG_CONTEXTS
הפלט אמור להיראות כך:
--------------------
Enabling the multi-repo mode on cluster "my_managed_cluster-1" ...
- A RootSync object is generated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml".
- The original ConfigManagement object is saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-original.yaml".
- The ConfigManagement object is updated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml".
- Resources for the multi-repo mode have been saved in a temp folder. If the migration process is terminated, it can be recovered manually by running the following commands:
kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml && \
kubectl wait --for condition=established crd rootsyncs.configsync.gke.io && \
kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml.
- Updating the ConfigManagement object ....
- Waiting for the RootSync CRD to be established ....
- The RootSync CRD has been established.
- Creating the RootSync object ....
- Waiting for the reconciler-manager Pod to be ready ....
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- Haven't detected running Pods with the label selector "app=reconciler-manager".
- The reconciler-manager Pod is running.
- Waiting for the root-reconciler Pod to be ready ....
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- The root-reconciler Pod is running.
- The migration process is done. Please check the sync status with `nomos status`.
Finished migration on all the contexts. Please check the sync status with `nomos status`.
חזרה להגדרה הקודמת
אם צריך לבצע החזרה לגרסה קודמת אחרי ההעברה באמצעות nomos migrate, צריך להחיל את אובייקט ConfigManagement המקורי. nomos migrate שומר את אובייקט ConfigManagement המקורי בקובץ ומדפיס את השם במסוף.
שם הקובץ הוא מהצורה /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.
כדי לחזור לתצורה הקודמת, מעתיקים את נתיב הקובץ של cm-original.yaml ומחילים את הקובץ על האשכול:
kubectl apply -f CM_ORIGINAL_PATH
nomos migrate flags
כדי להתאים אישית את הפקודה nomos migrate, מוסיפים את הדגלים הבאים:
| דגל | תיאור |
|---|---|
--connect-timeout |
מקבל משך זמן. משך הזמן הקצוב לחיבור לכל אשכול.
ברירת המחדל היא 3s. |
--contexts |
מקבל רשימה של הקשרים שמופרדים בפסיקים לשימוש בסביבות מרובות אשכולות. ברירת המחדל היא ההקשר הנוכחי. להשתמש ב-"all" בכל ההקשרים. |
--dry-run |
מקבל ערך בוליאני. אם true, רק הפלט של ההעברה יודפס. |
-h או --help |
עזרה בפקודה nomos migrate. |
--remove-configmanagement |
מקבל ערך בוליאני. אם true, עובר אל OSS Config Sync
על ידי הסרת ConfigManagement Operator ו-ConfigManagement CRD. |
--wait-timeout |
מקבל משך זמן. משך הזמן הקצוב לתפוגה להמתנה עד שהתנאים של משאבי Kubernetes יהיו נכונים. ברירת המחדל היא 10m. |
הפעלה של מקור מידע אמין היררכי
אם אתם משתמשים במקור אמת לא מובנה, אתם יכולים לארגן את מקור האמת באופן שרירותי.
אם אתם משתמשים במקור מידע היררכי, אתם צריכים להריץ את הפקודה nomos init כדי לאתחל ספרייה היררכית:
nomos init
כך נוצר מבנה הספריות הבסיסי של מקור מידע אמין היררכי, כולל הספריות system/, cluster/ ו-namespaces/.
nomos init flags
כדי להתאים אישית את nomos init, מוסיפים את הדגלים הבאים:
| דגל | תיאור |
|---|---|
--force |
כתיבה לספרייה גם אם היא לא ריקה, והחלפה של קבצים מתנגשים |
-h או --help |
עזרה בפקודה nomos init. |
--path |
מקבל מחרוזת. ספריית השורש שבה רוצים להשתמש כמקור מידע אמין. ערך ברירת המחדל הוא "." |
פתרון בעיות
ב-Linux, יכול להיות שתופיע השגיאה הבאה כשמריצים פקודה של nomos:
failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64
כדי לפתור את הבעיה, צריך ליצור משתנה סביבה USER:
export USER=$(whoami)