Diese Seite wurde von der Cloud Translation API übersetzt.

Namespaces und Namespace-bezogene Objekte konfigurieren

Auf dieser Seite wird beschrieben, wie Sie mit Config Sync Namespaces und namespace-bezogene Objekte verwalten können.

Namespace konfigurieren

Die Konfiguration eines Namespace funktioniert für unstrukturierte und hierarchische Repositories unterschiedlich. In den folgenden Beispielen werden die Unterschiede hervorgehoben.

Unstrukturiertes Repository

Konfigurationen für Namespaces und namespace-bezogene Objekte können sich im Verzeichnis oder in Unterverzeichnissen des Repositorys befinden.

Führen Sie die folgenden Schritte aus, um in jedem registrierten Cluster einen Namespace namens gamestore zu konfigurieren:

Erstellen Sie eine namespace-gamestore.yaml-Datei mit folgendem Inhalt:
```
apiVersion: v1
kind: Namespace
metadata:
  name: gamestore
```
Sie müssen nur eine YAML-Datei mit der Namespace-Konfiguration erstellen.
Erstellen Sie einen Commit, der die namespace-gamestore.yaml-Konfiguration enthält, und übertragen Sie den Commit per Push an das Remote-Repository.
```
git add multirepo/root/namespace-gamestore.yaml
git commit -m "Created gamestore namespace config"
git push REMOTE_NAME BRANCH_NAME
```
Dabei gilt:
- REMOTE_NAME: der Name Ihres Remote-Repositorys
- BRANCH_NAME: der Zweig, zu dem Sie einen Commit durchführen möchten
In diesem Beispiel wird die Datei dem Stammverzeichnis hinzugefügt, Sie können diese Datei jedoch in jedes der Unterverzeichnisse des Repositorys verschieben.

Hierarchisches Repository

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:

Erstellen Sie im lokalen Klon Ihres Repository 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
```
Erstellen Sie im Namespace-Verzeichnis eine Datei gamestore.yaml mit folgendem Inhalt:
```
apiVersion: v1
kind: Namespace
metadata:
  name: gamestore
```
metadata.name muss dem Namen des Namespace-Verzeichnisses entsprechen.
Erstellen Sie einen Commit, der die gamestore.yaml-Konfiguration 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 REMOTE_NAME BRANCH_NAME
```
Dabei gilt:
- REMOTE_NAME: der Name Ihres Remote-Repositorys
- BRANCH_NAME: der Zweig, zu dem Sie einen Commit durchführen möchten

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, erstellen Sie einen neuen Commit, der die Datei entfernt, und übertragen Sie ihn per Push an das Remote-Repository. Entfernen Sie die Konfiguration nicht, wenn Sie einen abstrakten Namespace für ein hierarchisches Repository konfigurieren möchten.

Namespace-bezogenes Objekt konfigurieren

In unstrukturierten Repositories können Sie namespace-bezogene Objekte in jedem Verzeichnis oder Unterverzeichnis speichern, ohne dass eine Namespace-Konfiguration erforderlich ist. Wenn eine Namespacekonfiguration fehlt, erstellt Config Sync automatisch ein implizites Namespaceobjekt und wendet alle Konfigurationen auf diesen Namespace an.

Dieses Verhalten kann über das Feld namespaceStrategy geändert werden. Wenn namespaceStrategy auf explicit festgelegt ist, wird von Config Sync kein impliziter Namespace erstellt. Weitere Informationen finden Sie unter Namespace-Strategie.

In hierarchischen Repositories müssen Sie im Unterverzeichnis namespaces/NAMESPACE explizit eine Namespace-Konfiguration angeben. Dabei muss NAMESPACE mit dem Namen des Namespace übereinstimmen. Alle anderen Konfigurationen auf Namespaceebene müssen ebenfalls im selben Unterverzeichnis gespeichert sein. Wenn eine Namespace-Konfiguration fehlt, gibt Config Sync den Fehler KNV1044 zurück, der auf eine fehlende Namespace-Konfiguration hinweist.

Abstrakten Namespace konfigurieren

Dieser Abschnitt gilt nur für hierarchische Repositories, da abstrakte Namespaces in unstrukturierten Repositories nicht unterstützt werden.

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.

Erstellen Sie im lokalen Klon des Repository ein abstraktes Namespace-Verzeichnis namens eng:
```
mkdir namespaces/eng
```
Ein abstraktes Namespace-Verzeichnis enthält keine Konfiguration für einen Namespace, die untergeordneten Namespace-Verzeichnisse jedoch schon.
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"]
```

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

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

Config Sync merkt sich die Änderung und wendet die neue Role 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 jedoch innerhalb des Unterverzeichnisses namespaces/ eines hierarchischen Repositorys, erstellt Config Sync zuerst den Namespace in jedem Cluster und wendet dann alle übernommenen Konfigurationen auf diesen Namespace an. Verwenden Sie einen ClusterSelector, wenn Sie anhand der Labels jedes Clusters begrenzen möchten, welche Cluster durch eine bestimmte Konfiguration beeinflusst werden. Weitere Informationen finden Sie unter ClusterSelectors verwenden.

Begrenzen, auf welche Namespaces sich eine Konfiguration auswirkt

Verwenden Sie einen NamespaceSelector, um zu 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. NamespaceSelectors sind ClusterSelectors ähnlich, sind aber nicht damit identisch. Ein NamespaceSelector begrenzt den Pool der Namespaces, auf die eine Konfiguration angewendet wird.

Um einen NamespaceSelector zu deklarieren, fügen Sie entweder die Annotation metadata.namespace oder die Annotation NamespaceSelector hinzu. Die Angabe beider Annotationen ist ungültig. Wenn in namespace-bezogenen Ressourcen metadata.namespace oder die Annotation NamespaceSelector nicht deklariert wird, verwendet Config Sync den „Standard“-Namespace des Clusters.

NamespaceSelectors in unstrukturierten Repositories

Ein unstrukturiertes Repository muss nicht alle Namespaces für die namespace-bezogenen Objekte im Repository deklarieren. Ein Objekt kann einen metadata.namespace definieren, ohne ein übereinstimmendes Namespace-Objekt in einem unstrukturierten Repository zu haben. Wenn der Namespace bereits im Cluster vorhanden ist, erstellt Config Sync das Objekt in diesem Namespace. Wenn der Namespace noch nicht im Cluster vorhanden ist, erstellt Config Sync den Namespace implizit.

Bevor Sie ein unstrukturiertes Repository mit Objekten erstellen, die zuvor in einem hierarchischen Repository verwendet wurden, sollten Sie kontrollieren, dass Ihre NamespaceSelectors nicht auf zusätzliche Ressourcen angewendet werden.

Wenn Sie Namespace-bezogene Objekte aus einem unstrukturierten Repository entfernen, löscht Config Sync diese Objekte, jedoch keine Namespaces, die möglicherweise implizit für diese Objekte erstellt wurden. Dies liegt daran, dass Config Sync nicht ermitteln kann, wann sich ein Namespace, der implizit erstellt wurde, ohne Folgen löschen lässt. Deshalb verbleibt er dauerhaft im Cluster.

NamespaceSelector-Modus

In einem unstrukturierten Repository werden Objekte, die die Annotation NamespaceSelector deklarieren, auf alle Namespaces angewendet, die die Bedingungen eines NamespaceSelector erfüllen. Namespaces können statisch in der Quelle der Wahrheit deklariert werden oder dynamisch sein. Wenn Sie die dynamische Auswahl aktivieren möchten, setzen Sie spec.mode auf dynamic. Im dynamischen Modus umfasst die Auswahl sowohl statisch deklarierte Namespaces als auch dynamisch im Cluster vorhandene Namespaces. Dynamisch ausgewählte Namespaces sind bereits im Cluster vorhanden und werden daher nicht von Config Sync verwaltet. Der Standardmodus ist static.

NamespaceSelectors in hierarchischen Repositories

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

In einem unstrukturierten Repository können Sie die NamespaceSelectors in jedem beliebigen Verzeichnis oder in Unterverzeichnissen platzieren.

In einem hierarchischen Repository können Sie NamespaceSelectors in jedem Verzeichnis für abstrakte Namespaces ablegen, jedoch nicht in einem Namespace-Verzeichnis.

Die folgende Beispiel-Repository-Architektur zeigt gültige und ungültige Speicherorte für NamespaceSelectors, wenn Sie ein hierarchisches Repository verwenden:

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 darin keinen NamespaceSelector platzieren.

NamespaceSelector-Beispiele

Sie können eine NamespaceSelector mit Label-Selektoren verwenden, um Namespaces ein- oder auszuschließen. Kubernetes unterstützt Gleichheits- und Satzbasierte Auswählten. Sie können beide Arten von Selectors kombinieren, um die Auswahl der Namespaces weiter einzugrenzen.

Gleichheitsbasierter Label-Selektor

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 ihn in einer anderen Konfiguration referenzieren. Wenn sich der NamespaceSelector gamestore-selector in derselben Hierarchie wie das folgende ResourceQuota quota befindet, 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:

Labels zu Namespaces hinzufügen
NamespaceSelector-Konfiguration erstellen
NamespaceSelector-Objekt in einer anderen Konfiguration referenzieren

Satz-basierter Label-Selektor

Mit Namespace-Selektoren können bestimmte Namespaces von der Übernahme einer Ressource in der Struktur ausgenommen werden. Verwenden Sie dazu satzbasierte Label-Selektoren.

Wenn in diesem Beispiel ResourceQuota durch Festlegen der Annotation configmanagement.gke.io/namespace-selector: excludes-exempt-namespaces mit NamespaceSelector annotiert ist, wird ResourceQuota in jedem Namespace mit Ausnahme von Namespaces erstellt, die mit dem Label quota-exempt: exempt versehen sind:

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

Einbindung in Teambereiche und Flotten-Namespaces

In Google Cloud erstellte Flotten-Namespaces erhalten automatisch das Label fleet.gke.io/fleet-scope: your-scope. Alle Namespaces haben außerdem das Kubernetes-Label kubernetes.io/metadata.name: your-namespace. Mit diesen Standardlabels können Sie die NamespaceSelector für die Auswahl von Flotten-Namespaces einrichten.

Übernahme für einen Objekttyp deaktivieren

HierarchyConfig-Kubernetes-Objekte werden in unstrukturierten Repositories nicht unterstützt. Das folgende Beispiel gilt nur für die hierarchischen Repositories.

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

Informationen zum Konfigurieren von Clustern und clusterbezogenen Objekten