Présentation du contrôleur de hiérarchie

Ce document décrit le contrôleur de hiérarchie, un contrôleur Kubernetes et un contrôleur d'admission dynamique, qui ajoutent des hiérarchies aux espaces de noms Kubernetes.

Espaces de noms hiérarchiques

Le contrôleur de hiérarchie introduit le concept d'espace de noms hiérarchique, une extensions des espaces de noms Kubernetes qui facilite la gestion des groupes d'espaces de noms ayant en commun un même propriétaire. Les espaces de noms hiérarchiques sont particulièrement utiles dans les clusters partagés par plusieurs équipes, dans les cas où les propriétaires n'ont pas besoin d'être des personnes physiques. Par exemple, vous pouvez rendre un opérateur propriétaire d'un ensemble d'espaces de noms.

Pour prendre en charge les cas d'utilisation mutualisés, les espaces de noms hiérarchiques ont deux comportements clés en plus des espaces de noms Kubernetes standards :

  • Création d'espace de noms délégué. Le contrôleur de hiérarchie introduit la notion de sous-espace de nom. Un sous-espace de nom peut être créé par un utilisateur dans un espace de noms existant, même si cet utilisateur ne dispose pas de droits sur les espaces de noms au niveau du cluster.

    Par exemple, vous pouvez définir un espace de noms pour une équipe dans Anthos Config Management dans un dépôt Git, puis déléguer à l'équipe la création des sous-espaces de noms. Cela permet à l'équipe de créer ses propres sous-espaces de noms sous l'espace de noms que vous avez défini pour elle, sans aucune modification dans Git.

  • Application des règles. Prenant le relais d’Anthos Config Management qui peut propager des objets règles depuis des répertoires d'espaces de noms abstraits vers des espaces de noms Kubernetes, le contrôleur de hiérarchie peut propager ces objets vers des sous-espaces de noms. Par exemple, cela garantit que les règles appliquées dans l'espace de noms racine d'une équipe le sont également dans leurs sous-espaces.

    Cependant, il existe des différences entre la propagation des règles dans le contrôleur de hiérarchie et Anthos Config Management. Anthos Config Management copie tous les objets des répertoires d'espaces de noms abstraits dans leurs espaces de noms Kubernetes descendants. En revanche, le contrôleur de hiérarchie copie uniquement les rôles RBAC et les liaisons de rôle par défaut, bien qu'il puisse être configuré pour propager tout autre type d'objet Kubernetes.

Le contrôleur de hiérarchie est intégré à Anthos Config Management version 1.4.1 et ultérieure. Le contrôleur de hiérarchie est basé sur le contrôleur d'espace de noms hiérarchique (HNC), un projet Open Source.

Espaces de noms hiérarchiques et espaces de noms abstraits

Les espaces de noms hiérarchiques fournis par le contrôleur de hiérarchie sont similaires aux espaces de noms abstraits d'Anthos Config Management. Cependant, bien que les espaces de noms abstraits n'existent que dans le dépôt Anthos Config Management, les espaces de noms hiérarchiques sont tous des espaces de noms Kubernetes et existent sur le cluster.

Pour éviter les conflits entre les espaces de noms abstraits de Anthos Config Management et les espaces de noms du contrôleur de hiérarchie, assurez-vous qu'aucun espace de noms hiérarchique non racine n'est créé en tant qu'espace de noms abstrait ou feuille dans le dépôt Anthos Config Management.

Vous pouvez également utiliser un dépôt non structuré pour désactiver les espaces de noms abstraits Anthos Config Management et vous appuyer uniquement sur le contrôleur de hiérarchie pour définir des hiérarchies et propager des règles. Cela peut être utile si vous ne pouvez pas utiliser la structure de répertoires par défaut du dépôt, mais que vous souhaitez toujours profiter des fonctionnalités hiérarchiques.

Pour utiliser des dépôts non structurés, enregistrez soit les sous-espaces de noms, soit les espaces de noms complets. Nous vous recommandons d'utiliser les espaces de noms complets, car vous pouvez mettre à jour leurs relations hiérarchiques en modifiant l'objet HierarchicalConfiguration (que vous devez également enregistrer). En revanche, si vous enregistrez les sous-espaces de noms, vous devez enregistrer à la fois les espaces de noms et les objets SubnamespaceAnchor dans leur espace parent. Soyez conscient que ces objets n'ont pas été conçus pour être facilement modifiables après leur création.

Dans les deux cas, assurez-vous de bien configurer le contrôleur de hiérarchie afin d'appliquer tous les types d'objets Kubernetes souhaités dans toutes les hiérarchies. Par défaut, seuls les rôles RBAC et les liaisons de rôle sont appliqués.

Étape suivante