שימוש בכלי שורת הפקודה nomos

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

פקודה Usage
nomos status בדיקת הסטטוס של סנכרון התצורות
nomos vet בדיקה אם יש שגיאות במקור האמת
nomos hydrate הצגת כל ההגדרות במקור האמת
nomos bugreport יצירת דוח איתור באגים
nomos migrate העברה מאובייקט ConfigManagement אל RootSync
nomos init איך מאתחלים מקור קובע היררכי

דרישות מוקדמות

כדי להשתמש בכלי nomos כדי ליצור אינטראקציה עם אשכול, צריך להתקין את סנכרון תצורות באשכול היעד. צריך גם להתקין ולהגדיר את כלי שורת הפקודה kubectl. אם אתם מבצעים אינטראקציה עם אשכולות Google Kubernetes Engine, אתם צריכים לוודא שאתם מתקינים גם את gke-gcloud-auth-plugin.

הכלי nomos תומך בתצוגה מקדימה ובאימות של הגדרות Kustomize ושל תרשימי Helm. כדי להשתמש בתכונה הזו, צריך להתקין את Kustomize ואת Helm בתחנת העבודה המקומית. אם מקור האמת שלכם מכיל רק הגדרות שעברו רינדור מלא, השימוש ב-Kustomize וב-Helm הוא אופציונלי.

התקנת הכלי nomos

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

הכלי nomos לא נכלל כשמתקינים את סנכרון תצורות. אפשר להתקין את הכלי 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

בדיקת הסטטוס של סנכרון תצורות

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

אפשר גם להשתמש ב-nomos status כדי לבדוק אם המשאבים שמנוהלים על ידי סנכרון תצורות מוכנים. ‫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 לא מותקן סנכרון תצורות.
  • MANAGED_CLUSTER_5 מסתנכרן משני מאגרי Git. <root> מקור המידע האמין שייך לאדמין של האשכול, וbookstore מקור המידע האמין יכול להיות שייך לצוות פיתוח אפליקציות.

סטטוסים של משאבים מנוהלים

הסטטוס של המשאבים המנוהלים יכול להיות אחד מהערכים הבאים:

  • ‫InProgress: המצב בפועל של המשאב עדיין לא הגיע למצב שצוין במניפסט המשאב. המשמעות של הסטטוס הזה היא שהתאמת המשאבים עדיין לא הושלמה. משאבים שנוצרו לאחרונה מתחילים בדרך כלל עם הסטטוס הזה, אבל חלק מהמשאבים כמו ConfigMaps הם Current באופן מיידי.

  • ‫Failed: אירעה שגיאה בתהליך של התאמת המצב בפועל למצב הרצוי, או שלא חל בו מספיק שיפור.

  • ‫Current: המצב בפועל של המשאב תואם למצב הרצוי. תהליך ההתאמה נחשב למושלם עד שיש שינויים במצב הרצוי או במצב בפועל.

  • ‫Terminating: המשאב נמצא בתהליך מחיקה.

  • ‫NotFound: המשאב לא קיים באשכול.

  • ‫Unknown: סנכרון תצורות לא מצליח לקבוע את הסטטוס של המשאב.

כדי להפסיק את הצגת הסטטוס ברמת המשאב, מוסיפים את האפשרות --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 הבא:

  1. יוצרים קובץ בשם 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"]

  2. מחילים את הקובץ 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 מקבלת מחרוזת של משך זמן. הגדרה של פסק הזמן בצד הלקוח לתקשורת עם שרת ה-API של Kubernetes. ברירת המחדל היא 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 מקבל מחרוזת. הנתיב לספריית הבסיס של מקור האמת של סנכרון תצורות. ברירת המחדל היא "."
--source-format מקבלים hierarchy או unstructured. ‫If hierarchy or unset, validates the source of truth as a hierarchical source of truth. אם unstructured, המקור הקובע מאומת כ מקור קובע לא מובנה. חובה להשתמש בדגל הזה אם משתמשים במקור אמת לא מובנה.
--threshold אפשר להזין מספר שלם. הגדרת המספר המקסימלי של אובייקטים שמותרים לכל מאגר. אם חורגים מהמספר הזה, מוצגת שגיאה. כדי להשבית את האימות של מספר האובייקטים המקסימלי, משמיטים את הדגל או משתמשים בדגל --threshold=0. כדי להשתמש בערך ברירת המחדל 1000, צריך להזין את הדגל בלי ערך. כדי להגדיר מגבלה ספציפית, צריך להשתמש בערך --threshold=N.

אימות בצד השרת

אם הפקודה nomos vet לא יכולה לקבוע אם הסוג הוא במרחב שמות, הכלי nomos מתחבר לשרת ה-API של ההקשר הנוכחי kubectl. כברירת מחדל, הכלי nomos מבין סוגים בסיסיים של Kubernetes ו-CRD של סנכרון תצורות, ולכן הוא מנסה להתחבר לשרת ה-API רק אם ל-CR אין CRD תואם מוצהר. במקרה כזה, אם ה-CRD לא הוחל על שרת ה-API, הפקודה nomos vet מחזירה את השגיאה KNV1021. כדי להשבית את הבדיקה הזו ולמנוע שגיאות שנובעות מ-CRD חסרים, מעבירים את הדגל --no-api-server-check.

שמירת מטא-נתונים של שרת ה-API במטמון

במקום להשבית את הבדיקות של שרת ה-API, אפשר לשמור את הנתונים במטמון בשרת ה-API עבור הפקודה nomos vet. כדי לשמור את api-resources במטמון, פועלים לפי השלבים הבאים:

  1. מתחברים לאשכול שמכיל את כל ה-CRD שדרושים למקור האמת. אין צורך להפעיל את סנכרון תצורות באשכול.
  2. עוברים אל policyDir של המקור היחיד למידע מהימן. זו אותה ספרייה שצוינה במשאב ConfigManagement או RootSync.
  3. מריצים את הפקודה הבאה: 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. היא לא משנה את אופן הפעולה של סנכרון תצורות בשום צורה.

אפשר להוסיף לקובץ api-resources.txt רשומות נוספות שמתייחסות לסוגים שלא נמצאים במקור האמת שמאומת. ‫nomos vet מייבא את ההגדרות, אבל לא עושה איתן שום דבר.

עדכון הקובץ api-resources.txt

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

kubectl api-resources > api-resources.txt

בדיקה אוטומטית של שגיאות תחביר כשמבצעים קומיט

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

שימוש ב-nomos vet ב-hook לפני ביצוע commit

אתם יכולים להגדיר ווּק לפני ביצוע (pre-commit hook) שמריץ את הפקודה nomos vet כדי לבדוק אם יש שגיאות תחביר כשאתם מבצעים שינוי בשיבוט המקומי של מאגר ה-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 שלכם.

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

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

כברירת מחדל, מגבלת הגודל של etcd בצד השרת היא ‎1.5 MiB. פרטים נוספים זמינים במסמכי התיעוד של etcd. החלת אובייקט שגדול מהמגבלה הזו גורמת לאחת מהשגיאות הבאות, בהתאם לגודל האובייקט:

  • etcdserver: request is too large
  • rpc error: code = ResourceExhausted desc = trying to send message larger than max
  • Request entity too large: limit is 3145728

כדי למנוע חריגה ממגבלת הגודל של Kubernetes באובייקטים מסוג ResourceGroup, אפשר להשתמש ב-nomos vet --threshold כדי לאמת את מספר האובייקטים במאגר המקור.

כברירת מחדל, כשמשתמשים בפקודה nomos vet, לא נאכף סף. העברת האפשרות --threshold תגרום לפקודה vet להחזיר שגיאה אם מספר האובייקטים במאגר המקור חורג מהסף.

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

הסף הזה מאומת רק על ידי הפקודה nomos vet, ולא על ידי סנכרון תצורות עצמו. כדי לאכוף את הסף, משתמשים בפקודה nomos vet --threshold בבדיקה לפני שליחה במאגר מקור או בוו לפני ביצוע commit ב-Git.

הצגת כל ההגדרות במקור האמת

אפשר להשתמש בפקודה nomos hydrate כדי לראות את התוכן המשולב של מקור האמת בכל אשכול רשום.

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

הפקודה הזו יכולה גם להמיר מקור אמת היררכי לאחד או יותר מקורות אמת לא מובנים, באמצעות התוכן בספרייה compiled/.

nomos hydrate flags

כדי להתאים אישית את הפקודה nomos hydrate, מוסיפים את הדגלים הבאים:

סימון תיאור
--api-server-timeout מקבלת מחרוזת של משך זמן. הגדרה של פסק הזמן בצד הלקוח לתקשורת עם שרת ה-API של Kubernetes. ברירת המחדל היא 15s.
--clusters מקבל רשימה מופרדת בפסיקים של שמות אשכולות. משתמשים בדגל הזה כדי להגביל את הפלט לאשכול אחד או לרשימה של אשכולות. ברירת המחדל היא כל האשכולות. משתמשים ב-"" אם לא רוצים להשתמש באשכולות.
--flat אם האפשרות הזו מופעלת, כל הפלט מודפס לקובץ אחד. משתמשים בדגל הזה אם רוצים לחקות את ההתנהגות של nomos view.
--format אפשר להזין בו את הערך yaml או json. הפורמט של הפלט. ערך ברירת המחדל הוא yaml.
-h או --help עזרה בפקודה nomos hydrate.
--no-api-server-check מקבל ערך בוליאני. אם true, ההגדרה משביתה את התקשורת עם שרת ה-API לצורך גילוי. מידע נוסף על הדגל הזה זמין בקטע אימות בצד השרת.
--output מקבל מחרוזת. המיקום לכתיבת התצורה של נתוני מאזן הנוזלים. ברירת המחדל היא הספרייה compiled. אם האפשרות --flat לא מופעלת, כל מניפסט של משאב נכתב כקובץ נפרד. אם האפשרות --flat מופעלת, נכתב קובץ יחיד שמכיל את כל מניפסטים של המשאבים.
--path מקבל מחרוזת. הנתיב לספריית הבסיס של מקור האמת של סנכרון תצורות. ברירת המחדל היא "."
--source-format מקבלים hierarchy או unstructured. ‫If hierarchy or unset, validates the source of truth as a hierarchical source of truth. אם unstructured, המקור הקובע מאומת כ מקור קובע לא מובנה. חובה להשתמש בדגל הזה אם משתמשים במקור אמת לא מובנה.

יצירת דוח על באג

אם נתקלתם בבעיה ב-Config Sync שדורשת עזרה מGoogle Cloud התמיכה, אתם יכולים להשתמש בפקודה nomos bugreport כדי לספק להם מידע חשוב לניפוי באגים. אפשר להשתמש בפקודה הזו כמקור קובע יחיד לכמה מאגרי קוד.

nomos bugreport

הפקודה הזו יוצרת קובץ ZIP עם חותמת זמן ומידע על אשכול Kubernetes שהוגדר בהקשר kubectl. הקובץ מכיל גם יומנים מ-Pods של סנכרון תצורות. הוא לא מכיל מידע מהמשאבים שמסונכרנים עם סנכרון תצורות. מידע נוסף על התוכן של קובץ ה-ZIP זמין במאמר nomos bugreport reference.

מגבלות

אם קובץ בודד כלשהו גדול מ-1GiB, הפקודה nomos bugreport תיכשל וייווצר קובץ ZIP לא שלם. לרוב זה קורה בגלל קובצי יומן גדולים.

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

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

העברה מאובייקט 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 סנכרון תצורות על ידי הסרת האופרטור ConfigManagement וה-CRD‏ ConfigManagement.
--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)

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