Namespaces und Namespace-bezogene Objekte konfigurieren

Dieses Thema zeigt, wie Sie mit Anthos Config Management Namespaces und Namespace-Objekte verwalten. 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.

Um einen Namespace namens audit in jedem registrierten Cluster zu konfigurieren, gehen Sie so vor:

  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/audit:

    mkdir namespaces/audit
    
  2. 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
    
  3. 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]
    
  4. 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
    
  5. 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.

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.

  1. 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
    
  2. 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 beliebigen 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"]
    
  3. 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
    
  4. Verschieben Sie das Namespace-Verzeichnis audit von namespaces/ nach namespaces/regulatory/:

    mv namespaces/audit/ namespaces/regulatory/
    
  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 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 Anthos Config Management eine Konfiguration auf jeden registrierten Cluster an. Wenn sich die Konfiguration im Unterverzeichnis namespaces/ befindet, erstellt Anthos Config Management 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.

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:

  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

Weitere Informationen