Configurer des espaces de noms et des objets à l'échelle d'un espace de noms

Cette page explique comment utiliser Config Sync pour gérer des objets Namespace et des objets à l'échelle d'un espace de noms. Vous pouvez également découvrir comment configurer des clusters et des objets à l'échelle d'un cluster.

Configurer un objet Namespace

Toutes les configurations des objets Namespace et des objets définis à l'échelle d'un espace de noms se trouvent dans le répertoire namespaces/ du dépôt et ses répertoires descendants.

Procédez comme suit pour configurer un objet Namespace appelé audit dans chaque cluster enregistré.

Dans le clone local du dépôt, créez un répertoire d'espace de noms. Un répertoire d'espace de noms contient une configuration pour un objet Namespace. Le nom du répertoire d'espace de noms doit correspondre au nom de l'objet Namespace. Dans cet exemple, le répertoire est appelé namespaces/audit :
```
mkdir namespaces/audit
```
Dans le répertoire d'espace de noms, créez un fichier audit.yaml avec le contenu suivant. Le champ metadata.name doit correspondre au nom de l'objet Namespace et au nom du répertoire d'espace de noms.
```
apiVersion: v1
kind: Namespace
metadata:
  name: audit
```

Créez un commit incluant la configuration audit.yaml, puis transférez le commit vers le dépôt distant.

git add namespaces/audit/audit.yaml
git commit -m "Created audit namespace config"
git push [NAME-OF-REMOTE] [BRANCH-NAME]

Après quelques instants, l'objet Namespace audit est créé dans chaque cluster enregistré. Pour le valider, décrivez l'objet Namespace :
```
kubectl describe namespace audit
```
Pour supprimer la configuration et supprimer l'objet Namespace audit des clusters enregistrés, vous pouvez créer un commit qui supprime le fichier, puis le transférer vers le dépôt distant.
Remarque : Ne supprimez pas la configuration si vous souhaitez essayer de configurer un espace de noms abstrait.

Configurer un espace de noms abstrait

Cet exemple élargit l'exemple de la section Configurer un objet Namespace en déplaçant le répertoire d'espace de noms audit dans un espace de noms abstrait contenant des configurations supplémentaires héritées par l'objet Namespace audit.

Dans le clone local du dépôt, créez un répertoire d'espace de noms abstrait appelé regulatory. Un répertoire d'espace de noms abstrait ne contient pas de configuration pour un objet Namespace, contrairement à ses répertoires d'espaces de noms descendants.
```
mkdir namespaces/regulatory
```
Dans le répertoire d'espace de noms abstrait regulatory, créez une configuration pour un rôle appelé regulator qui accorde les autorisations get et list sur toutes les ressources de n'importe quel objet Namespace qui hérite du rôle.
```
# namespaces/regulatory/regulator_role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: regulator
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list"]
```

Créez une configuration pour un objet RoleBinding appelé regulatory-admin qui lie le rôle regulator au groupe regulators@example.com :

# 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

Déplacez le répertoire d'espaces de noms audit du répertoire namespaces/ vers le répertoire namespaces/regulatory/ :
```
mv namespaces/audit/ namespaces/regulatory/
```
Validez toutes vos modifications et transférez-les vers le dépôt distant.

Config Sync Operator remarque la modification et applique le nouveau rôle et l'objet RoleBinding à l'objet Namespace audit sur tous les clusters enregistrés.

Pour supprimer les configurations et supprimer l'objet Namespace audit des clusters enregistrés, vous pouvez créer un commit qui supprime la totalité de l'espace de noms abstrait regulatory, puis le transférer vers le dépôt distant.

Limiter les clusters affectés par une configuration

Généralement, Config Sync applique une configuration à chaque cluster enregistré. Si la configuration se trouve dans le sous-répertoire namespaces/, Config Sync crée d'abord l'espace de noms dans chaque cluster, puis applique toutes les configurations héritées à cet espace de noms.

Pour limiter les clusters affectés par une configuration donnée en fonction des libellés de chaque cluster, consultez la section Appliquer des configurations à un sous-ensemble de clusters.

Limiter les objets Namespace affectés par une configuration

NamespaceSelector est un type de configuration spécial qui utilise les objets labelSelector Kubernetes. Vous pouvez utiliser conjointement un objet NamespaceSelector et une configuration dans namespaces/ pour limiter les objets Namespace pouvant hériter de cette configuration.

Les objets NamespaceSelector ressemblent aux objets ClusterSelectors, mais sont légèrement différents. L'objet NamespaceSelector limite le groupe d'espaces de noms qui peuvent hériter d'une configuration donnée d'un espace de noms abstrait, quelle que soit la structure du répertoire namespaces/. Un objet ClusterSelector limite le groupe de clusters auquel une configuration s'applique, que la configuration cible un objet à l'échelle d'un cluster ou à l'échelle d'un espace de noms.

Emplacement de l'objet NamespaceSelector

Vous pouvez placer des objets NamespaceSelector dans n'importe quel répertoire d'espaces de noms abstraits, mais pas dans un répertoire d'espaces de noms.

L'exemple de dépôt suivant montre les emplacements valides et non valides pour les objets NamespaceSelector :

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
...

Comme les répertoires namespaces et shipping-app-backend représentent des espaces de noms abstraits, vous pouvez y ajouter un sélecteur. Toutefois, comme les répertoires audit et shipping-prod représentent des espaces de noms réels, vous ne pouvez pas y inclure d'objet NamespaceSelector.

Utiliser un objet NamespaceSelector

La configuration suivante crée un objet NamespaceSelector appelé sre-supported. Si une autre configuration référence cet objet NamespaceSelector, elle ne peut être appliquée qu'aux objets présents dans les objets Namespace portant le libellé env: prod.

kind: NamespaceSelector
apiVersion: configmanagement.gke.io/v1
metadata:
  name: sre-supported
spec:
  selector:
    matchLabels:
      env: prod

Pour référencer un objet NamespaceSelector dans une configuration, définissez l'annotation configmanagement.gke.io/namespace-selector sur le nom de l'objet NamespaceSelector.

Un objet NamespaceSelector n'a aucun effet tant que vous ne le référencez pas dans une autre configuration. Si l'objet NamespaceSelector sre-supported se trouve dans la même hiérarchie que l'objet RoleBinding suivant, sre-admin, l'objet RoleBinding n'est créé que dans les objets Namespace auxquels le libellé env: prod est appliqué :

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

En résumé, vous devez suivre les trois étapes suivantes pour utiliser un objet NamespaceSelector :

Ajouter des libellés aux objets Namespace
Créer une configuration d'objet NamespaceSelector
Référencer l'objet NamespaceSelector dans une autre configuration

Désactiver l'héritage pour un type d'objet

Vous pouvez désactiver de manière sélective l'héritage de toute configuration en définissant le champ hierarchyMode sur none. Les ressources HierarchyConfig sont stockées dans le répertoire system/ du dépôt. Dans l'exemple ci-dessous, l'héritage est désactivé pour les objets RoleBinding.

# 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

Étapes suivantes

Lisez le guide de démarrage rapide.
Découvrez comment configurer des clusters et des objets à l'échelle d'un cluster.
Découvrez comment appliquer des configurations à un sous-ensemble de clusters.