Hierarchy Controller – Übersicht

In diesem Dokument wird der Hierarchy Controller beschrieben, ein Kubernetes-Controller und dynamischer Admission-Controller, der Kubernetes-Namespaces Hierarchien hinzufügt.

Hierarchische Namespaces

Hierarchy Controller führt das Konzept hierarchischer Namespaces ein. Diese sind Erweiterungen von Kubernetes-Namespaces, mit denen Namespace-Gruppen, die ein gemeinsames Konzept der Eigentümerschaft haben, einfach verwaltet werden können. Sie sind besonders nützlich in Clustern, die von mehreren Teams gemeinsam genutzt werden, deren Inhaber aber keine Personen sein müssen. So können Sie beispielsweise einen Operator zum Inhaber einer Reihe von Namespaces machen.

Um mehrmandantenfähige Anwendungsfälle zu unterstützen, haben hierarchische Namespaces neben regulären Kubernetes-Namespaces zwei wichtige Verhaltensweisen:

  • Erstellung delegierter Namespaces. Mit dem Hierarchy Controller wird das Konzept eines Sub-Namespace eingeführt. Er kann von Nutzern unter einem vorhandenen Namespace erstellt werden, auch wenn dieser Nutzer keine Namespace-Berechtigungen auf Clusterebene hat.

    Sie können beispielsweise einen Namespace für ein Team in Anthos Config Management in einem Git-Repository definieren und dann die Erstellung der Unter-Namespaces an das Team delegieren. Dadurch können sie unter dem Namespace auf Teamebene, den Sie für sie definiert haben, eigene Subnamespaces erstellen, ohne Änderungen in Git vorzunehmen.

  • Richtlinienerzwingung Genau wie Anthos Config Management Richtlinienobjekte aus abstrakten Namespace-Verzeichnissen an Kubernetes-Namespaces weiterleiten kann, kann Hierarchy Controller diese Objekte in Sub-Namespaces weitergeben. So wird beispielsweise sichergestellt, dass die Richtlinien, die auf den Stamm-Namespace eines Teams angewendet werden, auch auf dessen untergeordnete Namespaces angewendet werden.

    Es gibt jedoch einige Unterschiede zwischen der Verteilung der Controller-Controller und Anthos Config Management. Anthos Config Management kopiert alle Objekte in abstrakten Namespace-Verzeichnissen in die untergeordneten Kubernetes-Namespaces. Standardmäßig kopiert der Hierarchie-Controller standardmäßig nur RBAC-Rollen und -Rollenbindungen. Sie können ihn jedoch so konfigurieren, dass jeder andere Typ des Kubernetes-Objekts.

Der Hierarchie-Controller ist in Anthos Config Management Version 1.4.1 und höher integriert. Hierarchie-Controller basieren auf dem Open-Source-Projekt Hierarchy Namespace Controller (HNC).

Hierarchische Namespaces im Vergleich zu abstrakten Namespaces

Die von Hierarchy Controller bereitgestellten hierarchischen Namespaces ähneln den abstrakten Namespaces von Anthos Config Management. Obwohl abstrakte Namespaces nur im Anthos Config Management-Repository vorhanden sind, sind hierarchische Namespaces Kubernetes-Namespaces und damit auf dem Cluster vorhanden.

Um Konflikte zwischen den abstrakten Namespaces von Anthos Config Management und den Hierarchy Controller-Namespaces zu vermeiden, dürfen Sie im Anthos Config Management-Repository keinen hierarchischen Nicht-Stamm-Namespace als abstrakten oder untergeordneten Namespace erstellen.

Alternativ können Sie ein unstrukturiertes Repository verwenden, um die abstrakten Namespaces von Anthos Config Management zu deaktivieren, und sich ausschließlich auf den Hierarchy Controller verlassen, um Hierarchien zu definieren und Richtlinien weiterzugeben. Dies kann nützlich sein, wenn Sie die Standard-Verzeichnisstruktur des Repositorys nicht verwenden können, aber dennoch hierarchische Funktionen nutzen möchten.

Wenn Sie unstrukturierte Repositories verwenden möchten, müssen Sie entweder Sub-Namespaces oder vollständige Namespaces einchecken. Wir empfehlen die Verwendung vollständiger Namespaces, da Sie deren hierarchische Beziehungen aktualisieren können, indem Sie das HierarchicalConfiguration-Objekt ändern (das Sie ebenfalls einchecken müssen). Wenn Sie dagegen Sub-Namespaces einchecken, achten Sie darauf, dass Sie sowohl die Namespaces als auch die SubnamespaceAnchor-Objekte in deren übergeordneten Elementen einchecken. Beachten Sie jedoch, dass sie nicht dafür geeignet sind, sie nach dem Erstellen zu ändern.

In beiden Fällen muss der Hierarchie-Controller so konfiguriert werden, dass alle gewünschten Kubernetes-Objekttypen auf alle Hierarchien angewendet werden. Standardmäßig werden nur RBAC-Rollen und -Rollenbindungen angewendet.

Nächste Schritte