Auf dieser Seite wird beschrieben, wie Sie mit Config Sync Namespaces verwalten und auswählen, welche Objekte mit Config Sync mit Ihren Namespaces synchronisiert werden.
Kubernetes-Ressourcenobjekte können je nach Ressourcentyp cluster- 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- und Namespace-Selektoren, mit denen Sie festlegen können, welche Objekte synchronisiert werden.
Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Kubernetes-Konzepten vertraut:
Objekte mit Config Sync eingrenzen
Wenn Sie Config Sync in einem Cluster oder als Standardeinstellung für eine Flotte installieren, werden standardmäßig alle Kubernetes-Objekte in Ihrer Source of Truth mit Clustern synchronisiert, in denen Config Sync installiert ist, oder mit allen Clustern in einer Flotte. Wenn Sie Objekte jedoch auf einen Cluster oder Namespace beschränken, können Sie festlegen, welche Objekte mit einem Cluster oder Namespace synchronisiert werden.
Config Sync bietet die folgenden Methoden, um den Geltungsbereich Ihrer Objekte festzulegen:
- Clusterbezogene Objekte mit einer Clusterauswahl konfigurieren
- Clusterbezogene Objekte mit Flottenpaketlabels konfigurieren (Vorabversion)
- Namespace-bezogene Objekte mit einem Namespace-Selector konfigurieren (diese Seite)
Ausdrückliche Namespaces verwenden
Wir empfehlen die Verwendung einer expliziten Namespacedeklaration, wenn Sie Config Sync konfigurieren, da Sie so Namespacemetadaten verwalten und Namespaces bei Bedarf später löschen können.
Die Standardeinstellung ist implicit
. Sie können die Namespacestrategie in Ihrem RootSync
- oder RepoSync
-Objekt jedoch ändern, indem Sie das Feld namespaceStrategy
auf explicit
festlegen. Weitere Informationen finden Sie unter Namespace-Strategie.
Namespace-Selektoren
Mit Namespace-Auswählen können Sie ansonsten identische Ressourcenobjekte in mehreren Namespaces bereitstellen.
Die Verwendung von Namespace-Selektoren ähnelt der Verwendung von Kubernetes-Label-Selektoren, um einen Dienst einer Gruppe von Pods zuzuordnen, jedoch mit einer zusätzlichen Ebene der Indirektion.
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 die Auswahl verwenden möchten, auf diese Auswahl.
So verwenden Sie Namespace-Auswahlen:
- Fügen Sie den Namespaces, in denen Sie die Bereitstellung vornehmen möchten, ein Label hinzu oder wählen Sie ein vorhandenes Label aus.
- Definieren Sie ein
NamespaceSelector
-Ressourcenobjekt in Ihrer Source of Truth. Config Sync synchronisiert keineNamespaceSelector
-Objekte mit Ihrem Cluster. - Ändern Sie für jedes Objekt, das Sie mit einem oder mehreren Namespaces synchronisieren möchten, die Konfiguration des Objekts, indem Sie das Feld
metadata.namespace
entfernen und die Anmerkungconfigmanagement.gke.io/namespace-selector
mit einem Wert hinzufügen, der mit dermetadata.name
IhresNamespaceSelector
übereinstimmt.
In den Beispielen im folgenden Abschnitt erfahren Sie mehr darüber, wie Sie NamespaceSelector
-Objekte definieren und andere Objekte mit NamespaceSelector
annotieren.
Hinweise
- Installieren Sie Config Sync.
- Erstellen Sie eine „Source of Truth“, in der Sie Ihre Konfigurationsdateien speichern, oder greifen Sie darauf zu.
- Wenn Sie noch keinen oder mehrere Namespaces haben, erstellen Sie die Namespaces, auf die Sie Ihre Ressourcen beschränken möchten. Sie können den Namespace direkt in Ihrem Cluster oder in Ihrer „Source of Truth“ erstellen.
Namespace-Selektoren verwenden
Namespace-Auswählter werden entweder mit Gleichwertigkeitsanforderungen oder satzbasierten Anforderungen definiert. Sie können mehrere Anforderungen kombinieren.
Beispiel für einen gleichheitsbasierten Label-Selektor
Im folgenden Beispiel wird gezeigt, wie Sie mit gleichheitsbasierten Auswählen auswählen, auf welche Namespaces eine Konfiguration angewendet werden soll:
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.
Erstellen Sie eine Namespaceauswahl namens
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 Namespace-Selector verweist, kann diese Konfiguration nur auf Objekte in Namespaces mit dem Label
app: gamestore
angewendet werden.Ein Namespace-Selector hat erst dann Auswirkungen, wenn Sie in einer anderen Konfiguration darauf verweisen. Erstellen Sie ein Beispielobjektkontingent, das auf die Namespaceauswahl 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 setbasierten Label-Selektor
Im folgenden Beispiel wird gezeigt, wie Sie mit setbasierten Auswählen Namespaces vom Übernehmen von Objekten ausschließen:
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.
Erstellen Sie eine Namespace-Auswahl 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-Selector verweist, wird diese Konfiguration auf alle Namespaces angewendet, außer auf diejenigen mit dem Schlüssel/Wert-Paar
quota-exempt: exempt
.Ein Namespace-Selector hat erst dann Auswirkungen, wenn Sie in einer anderen Konfiguration darauf verweisen. Erstellen Sie ein Beispielobjektkontingent, das auf die Namespaceauswahl 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 derjenigen, die das Schlüssel/Wert-Paar
quota-exempt: exempt
haben.
Einbindung in Teambereiche und Flotten-Namespaces
In Google Cloud erstellte Flotten-Namespaces haben automatisch das Label fleet.gke.io/fleet-scope: your-scope
. Alle Namespaces haben außerdem das Kubernetes-Label kubernetes.io/metadata.name: your-namespace
. Sie können diese Standardlabels verwenden, um einen Namespace-Selektor für die Auswahl von Flotten-Namespaces einzurichten.
Im Leitfaden zur Flotten-Tenancy wird ausführlicher beschrieben, wie Sie Namespace-Auswahlen mit Flotten und Teambereichen verwenden, um Objekte für verschiedene Teams selektiv zu verwalten.
Namespace-bezogene Objekte im hierarchischen Modus
Unstrukturierte Repositories werden für die meisten Anwendungsfälle empfohlen. Sie können jedoch Namespace-Selectors verwenden, um den Geltungsbereich Ihrer Objekte mit einem hierarchischen Repository zu definieren. Die Verwendung von Namespace-Selektoren ist gleich, aber es gibt zusätzliche Einschränkungen und Anforderungen an die Organisation der Namespacekonfiguration in Ihrer „Source of Truth“.
Beschränkungen
Wenn Sie eine Namespace-Auswahlkonfiguration mit einem hierarchischen Repository verwenden, beachten Sie die folgenden Einschränkungen und Anforderungen:
- Sie müssen alle Konfigurationsdateien für Namespaces und Namespace-bezogene Objekte im Verzeichnis
namespaces/
des hierarchischen Repositorys und in den untergeordneten Verzeichnissen speichern. - Sie müssen im Unterverzeichnis
namespaces/NAMESPACE
eine Namespacekonfiguration angeben, wobeiNAMESPACE
mit dem Namen des Namespace übereinstimmen muss. Alle anderen Objekte auf Namespaceebene müssen im selben Unterverzeichnis gespeichert werden. Wenn eine Namespacekonfiguration fehlt, gibt Config Sync den Fehler KNV1044 zurück. - Ressourcen, die auf einen Namespace-Selector 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 Namespace-Selektorkonfiguration 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 Namespace-Selectors:
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 das Namespace-Verzeichnis in einen abstrakten Namespace verschieben, der zusätzliche Konfigurationen enthält, die vom Namespace übernommen werden:
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.
Erstellen Sie im von Ihnen erstellten abstrakten Namespace-Verzeichnis eine Konfiguration für eine Rolle, die
get
- undlist
-Berechtigungen für alle Objekte in einem Namespace gewährt, der die Rolle schließlich ü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.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.Verschieben Sie die im vorherigen Abschnitt erstellte Namespacekonfiguration aus dem Verzeichnis
namespaces/
in das Verzeichnis für den abstrakten Namespace, 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