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 basé sur le projet Open Source Hierarchical Namespace Controller (HNC). Celui-ci est mis 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é élémentaire d'isolation et de 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 définissant le champ d'application de chaque espace de nom, afin de ne contenir que le plus petit nombre de ressources, tel qu'un seul microservice, ainsi que ses ressources et ses règles. Cependant, cela peut engendrer 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 des 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 via la propagation. Cela vous permet, par exemple, d'accorder des autorisations RBAC dans un espace de noms "racine". Hierarchy Controller s'assure que ces autorisations sont également présentes dans tous les espaces de noms descendants en copiant (propageant) les objets RBAC vers ces descendants. La propagation peut également être précisément contrôlée à 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 des règles telles que la validation des configurations de webhooks 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. 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 approuvés pour l'application des règles peuvent également être utilisés pour observer des charges de travail hiérarchiques, par exemple pour filtrer les 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 leur création. À la place, 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 ont é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 dans les 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 règle (comme les rôles) et les objets de ressource (comme 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. L'utiliser de cette manière peut entraîner des conséquences inattendues. 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 sur 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, ce qui indique à 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 tous les quotas de ressources hiérarchiques. Cependant, vous ne pouvez pas définir de ressources qui ne doivent exister que 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é.