Présentation de Hierarchy Controller

Hierarchy Controller ajoute des fonctionnalités hiérarchiques aux espaces de noms Kubernetes, ce qui vous permet d'écrire des règles plus expressives, d'améliorer l'observabilité et de déléguer l'administration du cluster.

Hierarchy Controller est intégré à Config Sync 1.4.1 et versions ultérieures, mais ne nécessite pas l'utilisation d'un dépôt Config Sync. Autrement dit, vous pouvez utiliser Hierarchy Controller entièrement sur le cluster, sans GitOps.

Hierarchy Controller est basé sur le projet Open Source Hierarchical Namespace Controller (HNC). Il est mise en œuvre à l'aide de contrôleurs Kubernetes et de contrôleurs d'admission dynamiques qui s'exécutent dans votre cluster.

Espaces de noms hiérarchiques

Dans Kubernetes, les espaces de noms constituent l'unité élémentaire de l'organisation de la plupart des objets. Ils forment également l'unité fondamentale de l'isolation et de la sécurité dans Kubernetes. La plupart des règles et des objets d'isolation fonctionnent au niveau de l'espace de noms, tels que les rôles RBAC, les secrets, les comptes de service, les quotas de ressources et les règles de réseau.

Vous pouvez généralement améliorer la sécurité et l'isolation de votre cluster en limitant chaque espace de noms pour contenir le plus petit nombre de ressources, par exemple un seul microservice, ainsi que ses ressources et ses règles. Cependant, cela peut entraîner un grand nombre d'espaces de noms dans vos clusters, ce qui peut être difficile à gérer.

Pour résoudre ce problème, Hierarchy Controller introduit la notion d'espace de noms hiérarchique, qui vous permet de regrouper les espaces de noms Kubernetes en fonction de leurs propriétaires et de manipuler ces groupes en tant qu'unités cohérentes. Les espaces de noms hiérarchiques sont particulièrement utiles dans les clusters partagés entre plusieurs équipes, dans les cas où les propriétaires n'ont pas besoin d'être des personnes physiques. Par exemple, vous pouvez rendre un outil automatisé propriétaire d'un ensemble d'espaces de noms, en particulier s'il nécessite d'autorisations étendues, mais n'a besoin d'accéder qu'à un petit ensemble d'espaces de noms associés.

Pour les cas d'utilisation mutualisés, les espaces de noms hiérarchiques offrent plusieurs fonctionnalités en plus de celles des espaces de noms Kubernetes standards :

  • Application des règles. Les espaces de noms hiérarchiques peuvent hériter de certaines règles de leurs ancêtres à l'aide de la propagation. Par exemple, cela vous permet d'accorder des autorisations RBAC dans un espace de noms "racine" et Hierarchy Controller garantit que ces autorisations se trouvent également dans tous les espaces de noms descendants en copiant (propageant) les objets RBAC vers ces descendants. La propagation peut également être contrôlée à des niveaux précis à l'aide d'exceptions.
  • Application des règles. Tous les espaces de noms hiérarchiques incluent des libellés connus et approuvés qui reflètent leurs ancêtres. Ces libellés peuvent être utilisés dans les sélecteurs de libellés de règles telles que la validation des configurations webhook ou des règles de réseau.
  • Quota hiérarchique. Vous pouvez définir un seul quota hiérarchique dans un espace de noms ancêtre, et les limites sont automatiquement appliquées à l'utilisation globale de cet espace de noms et de tous ses descendants.
  • Observabilité hiérarchique. Les libellés de confiance utilisés pour l'application de règles peuvent également servir à observer des charges de travail hiérarchiques, en filtrant par exemple des journaux ou l'utilisation.
  • 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.

Les espaces de noms hiérarchiques sont également compatibles avec des fonctionnalités d'administration étendues, y compris la délégation.

Espaces de noms hiérarchiques et espaces de noms abstraits

Les espaces de noms hiérarchiques fournis par Hierarchy Controller sont similaires aux espaces de noms abstraits que vous pouvez utiliser si vous utilisez un dépôt hiérarchique Config Sync. Toutefois, ils présentent plusieurs différences conceptuelles :

  • Les espaces de noms abstraits ne peuvent être définis que dans un dépôt hiérarchique, qui applique une structure particulière sur vos configurations. Les espaces de noms hiérarchiques peuvent être utilisés dans des dépôts non structurés, ce qui vous permet d'organiser vos fichiers de configuration comme vous le souhaitez.
  • Les espaces de noms abstraits n'existent que dans les dépôts Git, tandis que les espaces de noms hiérarchiques sont également des espaces de noms Kubernetes standards et existent dans le cluster. Par conséquent, les espaces de noms hiérarchiques peuvent être définis soit dans un dépôt, soit directement dans le cluster.
  • Les espaces de noms hiérarchiques ne nécessitent pas d'autorisations au niveau du cluster pour être créés. Au lieu de cela, vous pouvez utiliser des sous-espaces de noms pour la création d'espaces de noms délégués.
  • Les quotas de ressources hiérarchiques ne sont compatibles qu'avec les espaces de noms hiérarchiques, et non avec les espaces de noms abstraits.
  • Les espaces de noms abstraits ne sont disponibles que pour Config Sync, tandis que les espaces de noms hiérarchiques sont basés sur des concepts Open Source.

Les espaces de noms abstraits et hiérarchiques présentent également des comportements par défaut différents. Par défaut, tous les objets créés dans un espace de noms abstrait sont propagés vers ses descendants. En revanche, les objets des espaces de noms hiérarchiques ne sont propagés que si Hierarchy Controller a été configuré pour propager ce type d'objet.

Par défaut, seuls les rôles RBAC et les liaisons de rôles sont propagés, mais tout objet d'espace de noms peut être propagé. Nous vous recommandons de ne propager que les objets de stratégie (tels que les rôles) et les objets de ressource (tels que les mappages de configuration). Hierarchy Controller n'est pas conçu pour propager des objets de charge de travail tels que des pods, des déploiements ou des tâches. Des conséquences inattendues sont à prévoir s'il est utilisé de cette manière. Nous vous recommandons de placer des charges de travail dans des espaces de noms feuilles.

Utiliser Hierarchy Controller avec Config Sync

Hierarchy Controller vous permet de définir et d'appliquer des règles à l'aide de concepts hiérarchiques adaptés à de nombreuses applications, y compris les clusters utilisés par plusieurs équipes. Config Sync vous permet de stocker ces stratégies dans un dépôt Git et de les appliquer à des groupes de clusters. Bien que différentes, ces deux fonctionnalités sont gratuites et vous permettent d'appliquer GitOps de façon efficace dans des environnements multiéquipes et multiclusters.

Lorsque vous utilisez Hierarchy Controller avec Config Sync, nous vous recommandons d'utiliser un dépôt non structuré pour désactiver les espaces de noms abstraits Config Sync et d'utiliser Hierarchy Controller pour la définition des hiérarchies et la propagation des règles. Pour les espaces de noms que vous souhaitez enregistrer dans votre dépôt, nous vous recommandons de ne rechercher dans les configurations que les espaces de noms complets, pas les sous-espaces de noms, car vous pouvez mettre à jour leurs relations hiérarchiques en modifiant l'objet HierarchicalConfiguration.

Il est possible d'utiliser Hierarchy Controller avec les espaces de noms abstraits de Config Sync dans un dépôt hiérarchique, mais de manière limitée. Par exemple, Hierarchy Controller ne vous permet pas de créer une relation hiérarchique entre deux espaces de noms définis dans un dépôt hiérarchique, car cela pourrait entrer en conflit avec des espaces de noms abstraits dans ce dépôt. Cependant, vous pouvez utiliser des espaces de noms hiérarchiques avec un dépôt hiérarchique de différentes manières :

  • Vous pouvez créer des sous-espaces de noms en libre-service dans le cluster, sous un espace de noms créé à partir d'un dépôt hiérarchique. Toutefois, nous vous déconseillons d'enregistrer les configurations de ces sous-espaces de noms.
  • Si vous utilisezplusieurs dépôts , vous pouvez créer des ancres de sous-espaces de noms dans les dépôts d'espaces de noms, qui indiqueront à Hierarchy Controller de créer des sous-espaces de noms sous l'espace de noms spécifié. Ces sous-espaces de noms hériteront de toutes les ressources configurées de leurs ancêtres et seront limités par les quotas de ressources hiérarchiques. Cependant, vous ne pouvez pas définir de ressources qui doivent uniquement exister dans ces sous-espaces de noms. Config Sync synchronise tous les objets du dépôt d'espaces de noms avec l'espace de noms spécifié.

Étape suivante