Héritage des espaces de noms et espaces de noms d'extrait

Cette page explique comment utiliser le concept d'héritage des espaces de noms dans un dépôt hiérarchique Config Sync.

Selon la structure du dépôt, Config Sync peut appliquer automatiquement des configurations aux groupes d'espaces de noms dans tous les clusters où ces espaces de noms existent (ou devraient exister). Ces groupes d'espaces de noms sont appelés espaces de noms abstraits.

L'héritage des espaces de noms et les espaces de noms abstraits ne sont pas compatibles avec les dépôts non structurés. Si vous utilisez un dépôt non structuré et que vous souhaitez bénéficier de fonctionnalités similaires, utilisez Hierarchy Controller.

Fonctionnement de l'héritage des espaces de noms

L'héritage des espaces de noms s'applique au répertoire namespaces/ du dépôt hiérarchique et à tous ses sous-répertoires. Les configurations des autres répertoires du dépôt, tels que cluster/, ne sont pas soumises au processus d'héritage.

Dans un dépôt hiérarchique, le répertoire namespaces/ peut contenir deux types de sous-répertoires différents :

  • Un répertoire d'espace de noms qui contient une configuration pour un objet Namespace. Le nom du fichier contenant la configuration n'est pas important, mais la configuration doit contenir kind: Namespace. Un répertoire d'espace de noms peut également inclure des configurations pour d'autres genres d'objets Kubernetes. Il ne peut pas contenir de sous-répertoires. Une configuration d'objet Namespace représente un objet Namespace réel d'un cluster.

  • Un répertoire d'espace de noms abstrait qui contient des répertoires d'espaces de noms. Il peut également inclure des configurations pour d'autres objets Kubernetes. En revanche, il ne peut pas contenir directement de configuration pour un objet Namespace. Un objet d'un cluster Kubernetes n'est pas représenté par un répertoire d'espace de noms abstrait, mais par les répertoires d'espaces de noms descendants de ce dernier.

Pour vous assurer que vos dépôts d'espaces de noms et d'espace de noms abstraits disposent du type de configuration et de structure appropriés, l'erreur KNV1003: IllegalNamespaceSubdirectoryError est signalée en cas de problème.

Les configurations d'un répertoire d'espace de noms ne s'appliquent qu'à cet espace de noms. Toutefois, les configurations d'un répertoire d'espace de noms abstrait sont appliquées à tous les répertoires d'espaces de noms descendants de cet espace de noms abstrait (ou à ces espaces de noms descendants qui correspondent à l'objet NamespaceSelector d'une configuration, le cas échéant).

Exemple d'héritage d'espaces de noms

L'héritage d'une configuration dans le répertoire namespaces/ est largement basé sur son emplacement dans l'arborescence de répertoires du dépôt. Pour comprendre quelles configurations sont appliquées à un espace de noms particulier dans un cluster donné, vous pouvez parcourir l'exemple de dépôt d'héritage des espaces de noms.

Le répertoire namespaces/ de l'exemple d'héritage des espaces de noms est organisé selon l'architecture suivante :

├── namespaces # Abstract namespace directory
│   ├── eng # Abstract namespace directory
│   │   ├── analytics # Namespace directory
│   │   └── gamestore # Namespace directory
│   ├── rnd # Abstract namespace directory
│   │   ├── incubator-1 # Namespace directory
│   │   └── incubator-2 # Namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

Pour mieux comprendre le fonctionnement de cet exemple de dépôt, commencez par explorer viewers-rolebinding.yaml :

namespace-inheritance/config/namespaces/viewers-rolebinding.yaml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: viewers
subjects:
- kind: Group
  name: system:serviceaccounts:foo
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

Comme cet objet RoleBinding se trouve à la racine du répertoire namespaces/, il attribue à tout utilisateur du groupe system:serviceaccounts:foo l'objet ClusterRole view dans chaque espace de noms géré par Config Sync.

Ensuite, ouvrez le répertoire namespaces/eng/ dans votre navigateur. Le répertoire eng est un répertoire d'espace de noms abstrait, car il ne possède pas de configuration pour un objet Namespace. Le répertoire eng contient les configurations suivantes :

  • eng-role.yaml
  • eng-rolebinding.yaml
  • network-policy-allow-gamestore-ingress.yaml
  • quota.yaml
  • selectors.yaml

Le répertoire eng contient également deux sous-répertoires : analytics et gamestore. Ces sous-répertoires sont des répertoires d'espaces de noms, car ils contiennent chacun une configuration pour un espace de noms. Dans cet exemple, les configurations d'espaces de noms sont appelées namespace.yaml, mais vous pouvez les appeler comme vous le souhaitez. Chacun des espaces de noms dans analytics et gamestore hérite des configurations eng-role.yaml, eng-rolebinding.yaml et network-policy-allow-gamestore-ingress.yaml du répertoire de l'espace de noms abstrait eng.

L'objet ResourceQuota défini dans quota.yaml utilise un objet NamespaceSelector. Par conséquent, cet objet ResourceQuota n'est créé que dans les espaces de noms analytics et gamestore.

Le répertoire d'espace de noms gamestore contient une configuration supplémentaire pour l'objet RoleBinding bob-rolebinding, mais le répertoire d'espace de noms analytics ne contient pas cette configuration. L'espace de noms analytics ne possède donc pas cet objet RoleBinding (sauf si quelqu'un le crée manuellement).

Le dépôt pour l'héritage d'espaces de noms contient également un fichier README.md qui comporte d'autres exemples illustrant le fonctionnement de l'héritage d'espaces de noms.

Espaces de noms restreints

config-management-system est un espace de noms restreint. Vous ne pouvez pas l'utiliser comme répertoire d'espace de noms abstrait. À partir de la version 1.11.0, vous pouvez définir un espace de noms config-management-system. Cependant, le seul type de ressource autorisé pour l'espace de noms config-management-system est RootSync.

Exclure les espaces de noms de l'héritage

Vous pouvez utiliser des sélecteurs d'espace de noms pour empêcher des espaces de noms spécifiques d'hériter d'une ressource de l'arborescence.

L'exemple suivant permet à un objet ResourceQuota correctement annoté dans le répertoire racine /namespaces d'être hérité par chaque espace de noms, à l'exception de ceux portant le libellé quota-exempt: exempt :

kind: NamespaceSelector
 apiVersion: configmanagement.gke.io/v1
 metadata:
   name: excludes-exempt-namespaces
 spec:
   selector:
     matchExpressions:
       - key: quota-exempt
         operator: NotIn
          values:
            - exempt

Pour en savoir plus sur NamespaceSelectors dans Config Sync, consultez la section Limiter les objets Namespace affectés par une configuration.

Effets des opérations Git sur les espaces de noms

Les opérations Git qui créent ou suppriment des répertoires d'espaces de noms à partir du répertoire namespaces/ peuvent avoir des effets différents de ceux initialement prévus. Ces interactions sont décrites dans les sections suivantes.

Créer un répertoire dans namespaces/

Lorsqu'une hiérarchie namespaces/ valide fait l'objet d'un commit dans le dépôt, Config Sync crée des espaces de noms. Il crée ensuite des objets Kubernetes dans ces espaces de noms pour chaque configuration que le répertoire d'espace de noms contient ou dont il hérite.

Supprimer un répertoire de namespaces/

La suppression d'un répertoire d'espace de noms est une opération destructive. L'objet Namespace est supprimé, ainsi que tout son contenu, sur chaque cluster géré par Config Sync où il est présent.

Si vous supprimez un répertoire d'espace de noms abstrait contenant des répertoires d'espaces de noms descendants, tous ces objets Namespace et leur contenu sont supprimés de chaque cluster géré par Config Sync.

Renommer un répertoire dans namespaces/

Le changement de nom d'un répertoire d'espace de noms se traduit par une suppression, suivie d'une création. Il s'agit donc également d'une opération destructive.

Le changement de nom d'un répertoire d'espace de noms abstrait n'a aucun effet visible de l'extérieur.

Déplacer un répertoire dans namespaces/

Le déplacement d'un objet Namespace ou d'un répertoire d'espace de noms abstrait dans namespaces/ n'a pas pour effet de supprimer l'objet Namespace ni les objets qu'il contient, sauf si ce dernier commence à hériter d'une configuration d'un répertoire d'espace de noms abstrait ou cesse d'en hériter à la suite d'une modification de sa hiérarchie.

Intégration avec Hierarchy Controller

Hierarchy Controller vous permet d'utiliser des espaces de noms hiérarchiques, qui sont similaires aux espaces de noms abstraits. Hierarchy Controller est également compatible avec des fonctionnalités supplémentaires telles que les quotas de ressources hiérarchiques et les espaces de noms en libre-service.

Sélectionner les espaces de noms associés

Il peut arriver que vous souhaitiez appliquer des règles à des ensembles d'espaces de noms liés par un ancêtre commun. Hierarchy Controller est compatible avec cette fonctionnalité grâce à un concept appelé libellés d'arborescence. Les libellés d'arborescence sont également acceptés par les espaces de noms abstraits, même si Hierarchy Controller n'est pas activé.

Les libellés d'arborescence sont des libellés Kubernetes qui se présentent au format suivant :

NAMESPACE_NAME.tree.hnc.x-k8s.io/depth: DEPTH

Ces libellés vous permettent d'écrire des sélecteurs d'espace de noms pouvant, par exemple, être utilisés dans le cadre d'une règle de réseau pour autoriser le trafic dans une sous-arborescence des espaces de noms associés, mais interdire le trafic en dehors de cette sous-arborescence.

Nous pouvons illustrer ce concept en revenant à l'exemple de dépôt.

├── namespaces # Abstract namespace directory
│   ├── eng # Abstract namespace directory
│   │   ├── analytics # Namespace directory
│   │   └── gamestore # Namespace directory
│   ├── rnd # Abstract namespace directory
│   │   ├── incubator-1 # Namespace directory
│   │   └── incubator-2 # Namespace directory
|   |── network-policy-default-deny-all.yaml
|   |── viewers-rolebinding.yaml

Imaginons que dans cet exemple, l'élément namespace.yaml du répertoire d'espace de noms abstrait gamestore comporte les libellés d'arborescence suivants:

eng.tree.hnc.x-k8s.io/depth: "1"
gamestore.tree.hnc.x-k8s.io/depth: "0"

Vous pouvez utiliser les commandes kubectl pour inspecter ces relations directement sur le cluster, sans avoir accès au dépôt Git :

# View all descendants of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth'

# View any immediate children of 'eng'
kubectl get namespaces -l 'eng.tree.hnc.x-k8s.io/depth=1'

Hierarchy Controller propage également les libellés d'arborescence des espaces de noms abstraits dans les espaces de noms descendants. Par exemple, si vous créez un espace de noms enfant de gamestore comme suit :

kubectl hns create gamestore-v1 -n gamestore

Dans ce cas, l'espace de noms gamestore-v1 inclut tous les libellés du parent, ainsi que les siens, avec une profondeur ajustée de manière appropriée :

eng.tree.hnc.x-k8s.io/depth: 2
gamestore-v1.tree.hnc.x-k8s.io/depth: 0
gamestore.tree.hnc.x-k8s.io/depth: 1

Étapes suivantes