יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

סנכרון אובייקטים למרחבי שמות מרובים

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

אובייקטים של משאבים ב-Kubernetes יכולים להיות בהיקף של אשכול או בהיקף של מרחב שמות, בהתאם לסוג המשאב. בוחרים את האשכול על ידי הגדרת הלקוח כך שיפנה לאשכול ספציפי. בוחרים את מרחב השמות על ידי הגדרת השדה metadata.namespace במניפסט האובייקט. ‫סנכרון תצורות מוסיף יכולות נוספות: בוררי אשכולות ובוררי מרחבי שמות, שמאפשרים לכם לדייק עוד יותר את האובייקטים שמסונכרנים.

לפני שקוראים את הדף הזה, חשוב להכיר את המושגים הבאים של Kubernetes:

מידע על הגדרת היקף לאובייקטים באמצעות סנכרון תצורות

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

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

הגדרת אובייקטים בהיקף האשכול באמצעות בורר אשכולות
הגדרת אובייקטים בהיקף האשכול באמצעות תוויות של חבילות צי (גרסת Preview)
הגדרת אובייקטים בהיקף של מרחב שמות באמצעות בורר מרחב שמות (בדף הזה)

שימוש במרחבי שמות מפורשים

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

ההגדרה שמוגדרת כברירת מחדל היא implicit, אבל אפשר לשנות את שיטת מרחב השמות באובייקט RootSync או RepoSync על ידי הגדרת השדה namespaceStrategy לערך explicit. מידע נוסף זמין במאמר בנושא אסטרטגיית מרחב שמות.

מידע על בוררי namespace

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

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

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

מוסיפים או בוחרים תווית קיימת במרחבי השמות שרוצים לפרוס בהם.
מגדירים אובייקט משאב NamespaceSelector במקור האמת. ‫סנכרון תצורות לא מסנכרן אובייקטים מסוג NamespaceSelector עם האשכול.
לכל אובייקט שרוצים לסנכרן עם מרחב שמות אחד או יותר, משנים את ההגדרה של האובייקט כדי להסיר את השדה metadata.namespace ולהוסיף את ההערה configmanagement.gke.io/namespace-selector עם ערך שתואם ל-metadata.name של NamespaceSelector.

בדוגמאות שבקטע הבא מוסבר איך להגדיר אובייקטים מסוג NamespaceSelector ולהוסיף הערות לאובייקטים אחרים כדי להשתמש ב-NamespaceSelector.

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

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

שימוש בסלקטורים של מרחב שמות

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

דוגמה לבורר תוויות מבוסס-שוויון

בדוגמה הבאה אפשר לראות איך משתמשים בסלקטורים מבוססי-שוויון כדי לבחור את מרחבי השמות שההגדרה חלה עליהם:

כדי להוסיף תווית למרחב שמות אחד או יותר:
```
kubectl label namespace NAMESPACE app=gamestore
```
מחליפים את NAMESPACE בשם של מרחב השמות.

מריצים את הפקודה הזו לכל מרחב שמות שרוצים להוסיף לו תווית.
יוצרים בורר של מרחב שמות בשם gamestore-selector.
```
kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: gamestore-selector
spec:
  selector:
    matchLabels:
      app: gamestore
```
אם הגדרות של אובייקט אחר מפנות לבורר מרחב השמות הזה, אפשר להחיל את ההגדרות האלה רק על אובייקטים במרחבי שמות עם התווית app: gamestore.
לבורר מרחב שמות אין השפעה עד שמפנים אליו בהגדרה אחרת. יוצרים מכסת אובייקטים לדוגמה שמפנה לבורר מרחב השמות:
```
kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
  annotations:
    configmanagement.gke.io/namespace-selector: gamestore-selector
spec:
  hard:
    pods: "1"
    cpu: "200m"
    memory: "200Mi"
```
מכסת המשאבים נוצרת רק במרחבי שמות עם התווית app: gamestore.

דוגמה לבורר תוויות מבוסס-קבוצות

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

כדי להוסיף תווית למרחב שמות אחד או יותר:
```
kubectl label namespace NAMESPACE quota-exempt=exempt
```
מחליפים את NAMESPACE בשם של מרחב השמות.

מריצים את הפקודה הזו לכל מרחב שמות שרוצים להוסיף לו תווית.

יוצרים בורר מרחבי שמות בשם exclude-exempt-namespaces:

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: excludes-exempt-namespaces
spec:
  selector:
    matchExpressions:
      - key: quota-exempt
        operator: NotIn
          values:
            - exempt

אם ההגדרה של אובייקט אחר מפנה לבורר מרחב השמות הזה, ההגדרה הזו חלה על כל מרחבי השמות חוץ מאלה עם זוג המפתח-ערך quota-exempt: exempt.

לבורר מרחב שמות אין השפעה עד שמפנים אליו בהגדרה אחרת. יוצרים מכסת אובייקטים לדוגמה שמפנה לבורר מרחב השמות:
```
kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
  annotations:
    configmanagement.gke.io/namespace-selector: exclude-exempt-namespaces
spec:
  hard:
    pods: "1"
    cpu: "200m"
    memory: "200Mi"
```
מכסת המשאבים נוצרת בכל מרחבי השמות, למעט אלה שיש להם את צמד המפתח/ערך quota-exempt: exempt.

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

מרחבי שמות של צי נוצרים ב- Cloud de Confiance by S3NS באופן אוטומטי עם התווית fleet.gke.io/fleet-scope: your-scope. בנוסף, לכל מרחבי השמות יש את התווית Kubernetes kubernetes.io/metadata.name: your-namespace. אתם יכולים להשתמש בתוויות ברירת המחדל האלה כדי להגדיר בורר של מרחבי שמות לבחירת מרחבי שמות של צי.

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

אובייקטים בהיקף מרחב שמות במצב היררכי

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

מגבלות

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

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

המיקום של הכלי לבחירת מרחב שמות

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

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

namespace-inheritance
...
├── namespaces
│   ├── eng
│   │   ├── gamestore
│   │   │   ├── namespace.yaml
│   │   │   └── ns_selector.yaml  # invalid
│   │   └── ns_selector.yaml  # valid
│   ├── ns_selector.yaml  # valid
│   ├── rnd
│   │   ├── incubator-1
│   │   │   ├── namespace.yaml
│   │   │   └── ns_selector.yaml  # invalid
│   │   └── ns_selector.yaml  # valid

מכיוון שהספריות namespaces,‏ eng ו-rnd מייצגות מרחבי שמות מופשטים, אפשר להציב בהן בורר. עם זאת, מכיוון שהספריות gamestore ו-incubator-1 מייצגות מרחבי שמות בפועל, אי אפשר להציב בהן בורר מרחבי שמות.

הגדרת מרחב שמות מופשט

במאגר היררכי, אפשר להשתמש במרחבי שמות מופשטים.

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

במאגר, יוצרים ספרייה של מרחב שמות מופשט. ספריית מרחב השמות המופשטת לא מכילה הגדרות של מרחבי שמות, אבל ספריות מרחבי השמות הצאצאות כן מכילות הגדרות.
בספרייה של מרחב השמות המופשט שיצרתם, יוצרים הגדרה לתפקיד שמעניקה הרשאות get ו-list לכל האובייקטים בכל מרחב שמות שבסופו של דבר יורש את התפקיד:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ROLE_NAME
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list"]
```
מחליפים את ROLE_NAME בשם התפקיד.

יוצרים הגדרה לקישור תפקיד שמקשר את התפקיד לקבוצת אימייל:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: ROLE_NAME
subjects:
- kind: Group
  name: group@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name:  ROLEBINDING_NAME
  apiGroup: rbac.authorization.k8s.io

מחליפים את ROLEBINDING_NAME בשם התפקיד.

מעבירים את הגדרת מרחב השמות שיצרתם בקטע הקודם מהספרייה namespaces/ לספרייה של מרחב השמות המופשט שיצרתם בקטע הזה.

השבתת תכונות שעוברות בירושה לאובייקטים

אפשר להשבית את ההורשה באופן סלקטיבי לכל הגדרה על ידי הגדרת השדה hierarchyMode לערך none. קבצים מסוג HierarchyConfigs מאוחסנים בספרייה system/ של המאגר. בדוגמה הזו, השבתנו את ההורשה של קישורי התפקידים:

# system/hierarchy-config.yaml
kind: HierarchyConfig
apiVersion: configmanagement.gke.io/v1
metadata:
  name: rbac
spec:
  resources:
  # Configure role to only be allowed in leaf namespaces.
  - group: rbac.authorization.k8s.io
    kinds: [ "RoleBinding" ]
    hierarchyMode: none