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

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

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

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/audit:
```
mkdir namespaces/audit
```
Erstellen Sie im Namespace-Verzeichnis eine Datei audit.yaml mit folgendem Inhalt. metadata.name muss dem Namen des Namespace (und dem Namen des Namespace-Verzeichnisses) entsprechen.
```
apiVersion: v1
kind: Namespace
metadata:
  name: audit
```
Erstellen Sie einen Commit, der die Konfiguration audit.yaml enthält, und übertragen Sie den Commit per Push an das Remote-Repository.
```
git add namespaces/audit/audit.yaml
git commit -m "Created audit namespace config"
git push [NAME-OF-REMOTE] [BRANCH-NAME]
```
Nach kurzer Zeit wird der audit-Namespace in jedem registrierten Cluster erstellt. Führen Sie zur Bestätigung ein "describe" auf den Namespace aus:
```
kubectl describe namespace audit
```
Wenn Sie die Konfiguration entfernen und den audit-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.
Hinweis: Entfernen Sie die Konfiguration nicht, wenn Sie dieKonfiguration eines abstrakten Namespace ausprobieren möchten.

Abstrakten Namespace konfigurieren

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

Erstellen Sie im lokalen Klon des Repositorys ein abstraktes Namespace-Verzeichnis namens regulatory. Ein abstraktes Namespace-Verzeichnis enthält keine Konfiguration für einen Namespace, die untergeordneten Namespace-Verzeichnisse jedoch schon.
```
mkdir namespaces/regulatory
```
Erstellen Sie im abstrakten Namespace-Verzeichnis regulatory eine Konfiguration für eine Rolle mit dem Namen regulator, die get und list für alle Ressourcen in einem Namespace gewährt, der schließlich die Rolle übernimmt.
```
# namespaces/regulatory/regulator_role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: regulator
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list"]
```

Erstellen Sie eine Konfiguration für ein RoleBinding mit dem Namen regulatory-admin, das die Rolle regulator an die Gruppe regulators@example.com bindet:

# namespaces/regulatory/regulator_rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: regulatory-admin
subjects:
- kind: Group
  name: regulators@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: regulator
  apiGroup: rbac.authorization.k8s.io

Verschieben Sie das Namespace-Verzeichnis audit von namespaces/ nach namespaces/regulatory/:
```
mv namespaces/audit/ namespaces/regulatory/
```
Übernehmen Sie all Ihre Änderungen und übertragen Sie sie per Push an das Remote-Repository.

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

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

Begrenzen, welche Cluster von einer Konfiguration betroffen sind

Normalerweise wendet Config Sync eine Konfiguration auf jeden registrierten Cluster an. Wenn sich die Konfiguration im Unterverzeichnis namespaces/ befindet, erstellt Config Sync zuerst den Namespace innerhalb jedes Clusters und wendet anschließend 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, welche Namespaces von einer Konfiguration betroffen sind

Ein NamespaceSelector ist ein spezieller Konfigurationstyp, der Kubernetes-labelSelectors verwendet. Mit einem NamespaceSelector in Kombination mit einer Konfiguration in namespaces/ können Sie begrenzen, welche Namespaces diese Konfiguration übernehmen können.

Hinweis: NamespaceSelectors sind ClusterSelectors ähnlich, sind aber nicht identisch. Ein NamespaceSelector begrenzt den Pool der Namespaces, die eine bestimmte Konfiguration aus einem abstrakten Namespace übernehmen können, 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

Sie können NamespaceSelectors in einem beliebigen abstrakten Namespace-Verzeichnis, jedoch nicht in einem Namespace-Verzeichnis platzieren.

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

foo-corp
...
├── namespaces
│   ├── ns_selector.yaml  # valid
|   ├──audit
|   |   ├── namespace.yaml
|   |   └── ns_selector.yaml  # invalid
|   └──shipping-app-backend
|       ├── ns_selector.yaml  # valid
|       └── shipping-prod
|           ├──namespace.yaml
|           └──ns_selector.yaml # invalid
...

Da die Verzeichnisse namespaces und shipping-app-backend abstrakte Namespaces darstellen, können Sie diese in einen Selektor einfügen. Da die Verzeichnisse audit und shipping-prod jedoch tatsächliche Namespaces darstellen, können Sie in diese keinen NamespaceSelector platzieren.

NamespaceSelector verwenden

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

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: sre-supported
spec:
  selector:
    matchLabels:
      env: prod

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

Ein NamespaceSelector hat keine Auswirkungen, bis Sie in einer anderen Konfiguration darauf verweisen. Wenn der NamespaceSelector sre-supported sich in derselben Hierarchie befindet wie das RoleBinding sre-admin, wird das RoleBinding nur in Namespaces mit dem Label env: prod erstellt:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-admin
  annotations:
    configmanagement.gke.io/namespace-selector: sre-supported
subjects:
- kind: Group
  name: sre@foo-corp.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io

Die Verwendung eines NamespaceSelector umfasst also drei Schritte:

Labels zu Namespaces hinzufügen
NamespaceSelector-Konfiguration erstellen
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

Kurzanleitung ansehen
Weitere Informationen zum Konfigurieren von Clustern und clusterbezogenen Objekten
Informationen zum Anwenden von Konfigurationen auf eine Teilmenge von Clustern