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.
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 Namenregulator
, dieget
undlist
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 Rolleregulator
an die Grupperegulators@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
vonnamespaces/
nachnamespaces/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