Objekte mit mehreren Namespaces synchronisieren

Auf dieser Seite wird beschrieben, wie Sie mit Config Sync Namespaces verwalten und auswählen können, welche Objekte Config Sync mit Ihren Namespaces synchronisiert.

Kubernetes-Ressourcenobjekte können je nach Ressourcentyp entweder clusterbezogen oder namespacebezogen sein. Sie wählen den Cluster aus, indem Sie Ihren Client so konfigurieren, dass er mit einem bestimmten Cluster kommuniziert. Sie wählen den Namespace aus, indem Sie das Feld metadata.namespace im Objektmanifest konfigurieren. Config Sync bietet zusätzliche Funktionen: Cluster-Selektoren und Namespace-Selektoren, mit denen Sie genauer festlegen können, welche Objekte synchronisiert werden.

Bevor Sie diese Seite lesen, sollten Sie mit den folgenden Kubernetes-Konzepten vertraut sein:

Bereich von Objekten mit Config Sync festlegen

Wenn Sie Config Sync standardmäßig in einem Cluster oder als Flottenstandard installieren, synchronisiert Config Sync alle Kubernetes-Objekte in Ihrer Source of Truth mit Clustern, in denen Config Sync installiert ist, oder mit allen Clustern in einer Flotte. Wenn Sie Objekte auf einen Cluster oder Namespace beschränken, können Sie jedoch steuern, welche Objekte mit einem Cluster oder Namespace synchronisiert werden.

Config Sync bietet die folgenden Methoden zum Festlegen des Bereichs Ihrer Objekte:

Explizite Namespaces verwenden

Wir empfehlen, beim Konfigurieren von Config Sync eine explizite Namespace-Deklaration zu verwenden, da Sie damit Namespace-Metadaten verwalten und Namespaces später bei Bedarf löschen können.

Die Standardeinstellung ist implicit. Sie können die Namespace-Strategie jedoch in Ihrem RootSync- oder RepoSync-Objekt ändern, indem Sie das Feld namespaceStrategy auf explicit festlegen. Weitere Informationen finden Sie unter Namespace-Strategie.

Namespace-Selektoren

Namespace-Selektoren sind eine Funktion von Config Sync, mit der Sie ansonsten identische Ressourcenobjekte in mehreren Namespaces bereitstellen können.

Die Verwendung von Namespace-Selektoren ähnelt der Verwendung von Kubernetes-Labelselektoren, um einen Dienst einer Gruppe von Pods zuzuordnen, jedoch mit einer zusätzlichen Indirektionsebene. Da Sie vorhandenen Ressourcentypen keine benutzerdefinierten Felder hinzufügen können, definieren Sie den Selektor stattdessen in einem NamespaceSelector-Objekt. Anschließend verweisen Sie in einer Anmerkung zu den Objekten, für die Sie diesen Selektor verwenden möchten, auf den Selektor.

So verwenden Sie Namespace-Selektoren:

  1. Fügen Sie den Namespaces, in denen Sie die Bereitstellung vornehmen möchten, ein Label hinzu oder wählen Sie ein vorhandenes Label aus.
  2. Definieren Sie ein NamespaceSelector-Ressourcenobjekt in Ihrer Source of Truth. Config Sync synchronisiert NamespaceSelector-Objekte nicht mit Ihrem Cluster.
  3. Ändern Sie für jedes Objekt, das Sie mit einem oder mehreren Namespaces synchronisieren möchten, die Konfiguration des Objekts, um das Feld metadata.namespace zu entfernen und die Annotation configmanagement.gke.io/namespace-selector mit einem Wert hinzuzufügen, der mit dem metadata.name Ihrer NamespaceSelector übereinstimmt.

In den Beispielen im nächsten Abschnitt finden Sie weitere Informationen dazu, wie Sie NamespaceSelector-Objekte definieren und andere Objekte annotieren, um das NamespaceSelector zu verwenden.

Hinweise

Namespace-Selektoren verwenden

Namespace-Selektoren werden entweder mit auf Gleichheit basierenden Anforderungen oder mit auf Mengen basierenden Anforderungen definiert. Sie können mehrere Anforderungen kombinieren.

Beispiel für einen gleichheitsbasierten Label-Selektor

Das folgende Beispiel zeigt, wie Sie mit auf Gleichheit basierenden Selektoren auswählen, auf welche Namespaces eine Konfiguration angewendet wird:

  1. Fügen Sie einem oder mehreren Namespaces ein Label hinzu:

    kubectl label namespace NAMESPACE app=gamestore
    

    Ersetzen Sie NAMESPACE durch den Namen Ihres Namespace:

    Führen Sie diesen Befehl für jeden Namespace aus, den Sie mit einem Label versehen möchten.

  2. Erstellen Sie einen Namespace-Selektor mit dem Namen gamestore-selector.

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

    Wenn die Konfiguration eines anderen Objekts auf diesen NamespaceSelector verweist, kann diese Konfiguration nur auf Objekte in Namespaces mit dem Label app: gamestore angewendet werden.

  3. Ein NamespaceSelector hat keine Auswirkungen, bis Sie ihn in einer anderen Konfiguration referenzieren. Erstellen Sie ein Beispiel für ein Objektkontingent, das auf die Namespace-Auswahl verweist:

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

    Das Ressourcenkontingent wird nur in Namespaces mit dem Label app: gamestore erstellt.

Beispiel für einen satzbasierten Label-Selektor

Im folgenden Beispiel wird gezeigt, wie Sie satzbasierte Selektoren verwenden, um Namespaces vom Erben von Objekten auszuschließen:

  1. Fügen Sie einem oder mehreren Namespaces ein Label hinzu:

    kubectl label namespace NAMESPACE quota-exempt=exempt
    

    Ersetzen Sie NAMESPACE durch den Namen Ihres Namespace:

    Führen Sie diesen Befehl für jeden Namespace aus, den Sie mit einem Label versehen möchten.

  2. Erstellen Sie einen Namespace-Selektor mit dem Namen 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
    

    Wenn die Konfiguration eines anderen Objekts auf diesen Namespace-Selektor verweist, wird diese Konfiguration auf alle Namespaces außer denen mit dem Schlüssel-Wert-Paar quota-exempt: exempt angewendet.

  3. Ein NamespaceSelector hat keine Auswirkungen, bis Sie ihn in einer anderen Konfiguration referenzieren. Erstellen Sie ein Beispiel für ein Objektkontingent, das auf die Namespace-Auswahl verweist:

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

    Das Ressourcenkontingent wird in allen Namespaces erstellt, mit Ausnahme der Namespaces mit dem Schlüssel-Wert-Paar quota-exempt: exempt.

Einbindung in Teambereiche und Flotten-Namespaces

Flotten-Namespaces, die in Google Cloud erstellt werden, haben automatisch das Labelfleet.gke.io/fleet-scope: your-scope. Alle Namespaces haben auch das Kubernetes-Label kubernetes.io/metadata.name: your-namespace. Mit diesen Standardlabels können Sie einen Namespace-Selektor zum Auswählen von Flotten-Namespaces einrichten.

Im Tutorial zur Mandantenfähigkeit von Flotten wird genauer erläutert, wie Sie Namespace-Selektoren mit Flotten und Teambereichen verwenden, um Objekte für verschiedene Teams selektiv zu verwalten.

Namespace-bezogene Objekte im hierarchischen Modus

Obwohl unstrukturierte Repositories für die meisten Anwendungsfälle empfohlen werden, können Sie Namespace-Selektoren verwenden, um den Umfang Ihrer Objekte mit einem hierarchischen Repository festzulegen. Die Verwendung von Namespace-Selektoren ist dieselbe, es gibt jedoch zusätzliche Einschränkungen und Anforderungen für die Organisation der Namespace-Konfiguration in Ihrer Source of Truth.

Beschränkungen

Wenn Sie eine Namespace-Selektorkonfiguration mit einem hierarchischen Repository verwenden, beachten Sie die folgenden Einschränkungen und Anforderungen:

  • Alle Konfigurationsdateien für Namespaces und Namespace-bezogene Objekte müssen im Verzeichnis namespaces/ des hierarchischen Repositorys und in den untergeordneten Verzeichnissen gespeichert werden.
  • Sie müssen explizit eine Namespace-Konfiguration im Unterverzeichnis namespaces/NAMESPACE angeben, wobei NAMESPACE mit dem Namen des Namespace übereinstimmt. Alle anderen Objekte mit Namespace-Bereich müssen im selben Unterverzeichnis gespeichert werden. Wenn eine Namespace-Konfiguration fehlt, gibt Config Sync den Fehler KNV1044 zurück.
  • Ressourcen, die auf einen NamespaceSelector verweisen, werden auf Namespaces angewendet, die eine bestimmte Konfiguration von einem abstrakten Namespace übernehmen, unabhängig von der Verzeichnisstruktur des Verzeichnisses namespaces/.

Speicherort der Namespace-Auswahl

In einem hierarchischen Repository können Sie eine NamespaceSelector-Konfiguration in einem beliebigen abstrakten Namespace-Verzeichnis, jedoch nicht in einem Namespace-Verzeichnis platzieren.

Die folgende Beispiel-Repository-Architektur zeigt gültige und ungültige Speicherorte für Namespace-Selektoren:

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 Namespace-Selektor platzieren.

Abstrakten Namespace konfigurieren

Bei einem hierarchischen Repository können Sie optional abstrakte Namespaces verwenden.

Im folgenden Beispiel wird gezeigt, wie Sie Ihr Namespace-Verzeichnis in einen abstrakten Namespace verschieben, der zusätzliche, vom Namespace übernommene Konfigurationen enthält:

  1. Erstellen Sie in Ihrem Repository ein abstraktes Namespace-Verzeichnis. Das abstrakte Namespace-Verzeichnis enthält keine Konfigurationen für Namespaces, die untergeordneten Namespace-Verzeichnisse jedoch schon.

  2. Erstellen Sie im abstrakten Namespace-Verzeichnis, das Sie erstellt haben, eine Konfiguration für eine Rolle, die die Berechtigungen get und list für alle Objekte in einem Namespace gewährt, der schließlich die Rolle übernimmt:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: ROLE_NAME
    rules:
    - apiGroups: [""]
      resources: ["*"]
      verbs: ["get", "list"]
    

    Ersetzen Sie ROLE_NAME durch den Namen der Rolle.

  3. Erstellen Sie eine Konfiguration für eine Rollenbindung, die die Rolle an eine E-Mail-Gruppe bindet:

    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
    

    Ersetzen Sie ROLEBINDING_NAME durch den Namen der Rolle.

  4. Verschieben Sie die Namespace-Konfiguration, die Sie im vorherigen Abschnitt erstellt haben, aus dem Verzeichnis namespaces/ in das abstrakte Namespace-Verzeichnis, das Sie in diesem Abschnitt erstellt haben.

Übernahme für Objekte 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 Rollenbindungen 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