Namespaces und Namespace-bezogene Objekte konfigurieren

Auf dieser Seite wird beschrieben, wie Sie mit Config Sync Namespaces und Namespace-bezogene Objekte verwalten können. Außerdem erfahren Sie einiges über das Konfigurieren von Clustern und clusterbezogenen Objekten.

Namespace konfigurieren

Unstrukturiertes Format

Konfigurationen für Namespaces und Namespace-bezogene Objekte können sich an einer beliebigen Stelle im Verzeichnis oder in Unterverzeichnissen befinden.

So konfigurieren Sie einen Namespace namens gamestore in jedem registrierten Cluster: Sie müssen nur eine YAML-Datei mit der Namespace-Konfiguration erstellen. In diesem Beispiel wird die Datei im Stammverzeichnis hinzugefügt. Sie können sie in beliebige Unterverzeichnisse verschieben.

  1. Erstellen Sie eine namespace-gamestore.yaml-Datei mit folgendem Inhalt:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    
  2. Erstellen Sie einen Commit, der die Konfiguration namespace-gamestore.yaml enthält, und übertragen Sie den Commit an das Remote-Repository.

    git add multirepo/root/namespace-gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push [NAME-OF-REMOTE] [BRANCH-NAME]
    

Hierarchisches Format

Alle Konfigurationen für Namespaces und Namespace-bezogene Objekte befinden sich im Verzeichnis namespaces/ des hierarchischen Repositorys und in den untergeordneten Verzeichnissen.

So konfigurieren Sie einen Namespace namens gamestore in jedem registrierten Cluster:

  1. Erstellen Sie im lokalen Klon des Repositorys ein Namespace-Verzeichnis. Ein Namespace-Verzeichnis enthält eine Konfiguration für einen Namespace. Der Name des Namespace-Verzeichnisses muss mit dem Namen des Namespace übereinstimmen. In diesem Beispiel heißt das Verzeichnis namespaces/gamestore:

    mkdir namespaces/gamestore
    
  2. Erstellen Sie im Namespace-Verzeichnis eine Datei gamestore.yaml mit folgendem Inhalt. metadata.name muss dem Namen des Namespace (und dem Namen des Namespace-Verzeichnisses) entsprechen.

    apiVersion: v1
    kind: Namespace
    metadata:
      name: gamestore
    
  3. Erstellen Sie einen Commit, der die Konfiguration gamestore.yaml enthält, und übertragen Sie den Commit per Push an das Remote-Repository.

    git add namespaces/gamestore/gamestore.yaml
    git commit -m "Created gamestore namespace config"
    git push [NAME-OF-REMOTE] [BRANCH-NAME]
    

Nach kurzer Zeit wird der gamestore-Namespace in jedem registrierten Cluster erstellt. Führen Sie zur Bestätigung ein "describe" auf den Namespace aus:

kubectl describe namespace gamestore

Wenn Sie die Konfiguration entfernen und den gamestore-Namespace aus registrierten Clustern löschen möchten, können Sie einen neuen Commit erstellen, der die Datei entfernt und per Push an das Remote-Repository übertragen.

Abstrakten Namespace konfigurieren

Dieses Beispiel erweitert das Beispiel aus Namespace konfigurieren um das Verschieben des Namespace-Verzeichnisses gamestore in einen abstrakten Namespace, der zusätzliche, vom gamestore-Namespace übernommene Konfigurationen enthält.

  1. Erstellen Sie im lokalen Klon des Repositorys ein abstraktes Namespace-Verzeichnis namens eng. Ein abstraktes Namespace-Verzeichnis enthält keine Konfiguration für einen Namespace, die untergeordneten Namespace-Verzeichnisse jedoch schon.

    mkdir namespaces/eng
    
  2. Erstellen Sie im abstrakten Namespace-Verzeichnis eng eine Konfiguration für eine Rolle mit dem Namen eng-viewer, die get und list für alle Ressourcen in einem Namespace gewährt, der schließlich die Rolle übernimmt.

    # namespaces/eng/eng-role.yaml
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: eng-viewer
    rules:
    - apiGroups: [""]
      resources: ["*"]
      verbs: ["get", "list"]
    
  3. Erstellen Sie eine Konfiguration für ein RoleBinding mit dem Namen eng-admin, das die Rolle eng-viewer an die Gruppe eng@example.com bindet:

    # namespaces/eng/eng-rolebinding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: eng-admin
    subjects:
    - kind: Group
      name: eng@example.com
      apiGroup: rbac.authorization.k8s.io
    roleRef:
      kind: Role
      name: eng-viewer
      apiGroup: rbac.authorization.k8s.io
    
  4. Verschieben Sie das Namespace-Verzeichnis gamestore von namespaces/ nach namespaces/eng/:

    mv namespaces/gamestore/ namespaces/eng/
    
  5. Übernehmen Sie all Ihre Änderungen und übertragen Sie sie an das Remote für das Repository.

Der Config Management Operator bemerkt die Änderung und wendet die neue Rolle und RoleBinding auf allen registrierten Clustern auf den gamestore-Namespace an.

Wenn Sie die Konfigurationen entfernen und den gamestore-Namespace aus registrierten Clustern löschen möchten, können Sie einen neuen Commit erstellen, bei dem der gesamte abstrakte Namespace eng entfernt wird, und ihn per Push an das Remote-Repository übertragen.

Konfiguration auf bestimmte Cluster begrenzen

Im Normalfall wendet Config Sync eine Konfiguration auf jeden registrierten Cluster an. Befindet sich die Konfiguration im Unterverzeichnis namespaces/ eines hierarchischen Repositorys, erstellt Config Sync zuerst den Namespace in jedem Cluster und wendet dann alle übernommenen Konfigurationen auf diesen Namespace an.

Wenn Sie anhand der Labels der einzelnen Cluster begrenzen möchten, auf welche Cluster sich eine bestimmte Konfiguration auswirkt, finden Sie weitere Informationen unter Nur eine Teilmenge von Clustern konfigurieren.

Begrenzen, auf welche Namespaces sich eine Konfiguration auswirkt

Ein NamespaceSelector ist ein spezieller Konfigurationstyp, der Kubernetes-labelSelectors verwendet. Sie können NamespaceSelectors in Kombination mit Konfigurationen für namespace-bezogene Objekte in einem unstrukturierten Repository oder einem hierarchischen Repository deklarieren, um einzuschränken, welche Namespaces diese Konfiguration übernehmen können.

Hinweis: NamespaceSelectors sind ClusterSelectors ähnlich, sind aber nicht identisch. Ein NamespaceSelector begrenzt den Pool der Namespaces, auf die eine Konfiguration angewendet wird. In einem unstrukturierten Repository werden Objekte, die die Annotation NamespaceSelector deklarieren, auf alle Namespaces angewendet, die die Bedingungen des NamespaceSelector erfüllen. In einem hierarchischen Repository werden Objekte, die die Annotation NamespaceSelector deklarieren, auf Namespaces angewendet, die eine bestimmte Konfiguration von einem abstrakten Namespace übernehmen, unabhängig von der Verzeichnisstruktur des Verzeichnisses namespaces/. Ein ClusterSelector begrenzt den Pool von Clustern, auf die eine Konfiguration angewendet wird, unabhängig davon, ob sich die Konfiguration auf ein cluster- oder namespace-bezogenes Objekt bezieht.

NamespaceSelector-Speicherort

  • Unstrukturiertes Format: In einem unstrukturierten Repository können Sie die NamespaceSelectors in beliebigen Verzeichnissen und Unterverzeichnissen platzieren.
  • Hierarchisches Format: In einem hierarchischen Repository können Sie NamespaceSelectors in einem abstrakten Namespace-Verzeichnis platzieren, jedoch nicht in einem Namespace-Verzeichnis.

    Im folgenden Beispiel-Repository sehen Sie gültige und ungültige Speicherorte für NamespaceSelectors:

    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
    

    Da die Verzeichnisse namespaces, eng und rnd abstrakte Namespaces darstellen, können Sie in diese einen Selektor einfügen. Da die Verzeichnisse gamestore und incubator-1 jedoch tatsächliche Namespaces darstellen, können Sie in diesen keinen NamespaceSelector platzieren.

NamespaceSelector verwenden

Mit der folgenden Konfiguration wird ein NamespaceSelector mit dem Namen gamestore-selector erstellt. Wenn eine andere Konfiguration auf diesen NamespaceSelector verweist, kann diese Konfiguration nur auf Objekte in Namespaces mit dem Label app: gamestore angewendet werden.

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: gamestore-selector
spec:
  selector:
    matchLabels:
      app: gamestore

Wenn Sie in einer Konfiguration auf einen NamespaceSelector verweisen möchten, geben Sie in der Annotation configmanagement.gke.io/namespace-selector den Namen des NamespaceSelectors an.

Ein NamespaceSelector hat keine Auswirkungen, bis Sie in einer anderen Konfiguration darauf verweisen. Wenn der NamespaceSelector gamestore-selector sich in derselben Hierarchie befindet wie das ResourceQuota quota, wird das ResourceQuota nur in Namespaces mit dem Label app: gamestore erstellt:

kind: ResourceQuota
apiVersion: v1
metadata:
  name: quota
  annotations:
    configmanagement.gke.io/namespace-selector: gamestore-selector
spec:
  hard:
    pods: "1"
    cpu: "200m"
    memory: "200Mi"

Die Verwendung eines NamespaceSelector umfasst also drei Schritte:

  1. Labels zu Namespaces hinzufügen
  2. NamespaceSelector-Konfiguration erstellen
  3. NamespaceSelector-Objekt in einer anderen Konfiguration referenzieren

Übernahme für einen Objekttyp deaktivieren

Sie können die Übernahme für jede Konfiguration selektiv deaktivieren, indem Sie das Feld hierarchyMode auf none setzen. HierarchyConfigs werden im Verzeichnis system/ des Repositorys gespeichert. In diesem Beispiel wird die Übernahme für RoleBindings deaktiviert.

# 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

Nächste Schritte