Hierarchy Controller – Übersicht

In diesem Dokument wird der Hierarchy Controller erläutert, ein Kubernetes-Controller und dynamischer Admission-Controller, mit dem Kubernetes-Namespaces Hierarchien hinzugefügt werden.

Hierarchische Namespaces

Der Hierarchy Controller implementiert das Konzept hierarchischer Namespaces. Dies sind Erweiterungen von Kubernetes-Namespaces, mit denen Namespace-Gruppen, die das Konzept der Inhaberschaft teilen, einfach verwaltet werden können. Sie sind besonders hilfreich 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.

Zur Unterstützung mehrmandantenfähiger Anwendungsfälle bieten hierarchische Namespaces über reguläre Kubernetes-Namespaces hinaus zwei zusätzliche Möglichkeiten:

  • 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 z. B. einen Namespace für ein Team in Config Sync in einem Git-Repository definieren und dann die Erstellung der untergeordneten Namespace 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. So wie Config Sync Richtlinienobjekte aus abstrakten Namespace-Verzeichnissen an Kubernetes-Namespaces weitergeben kann, lassen sich diese Objekte mit dem Hierarchy Controller an untergeordnete Namenspaces weitergeben. Damit wird beispielsweise gewährleistet, dass die Richtlinien, die auf den Stamm-Namespace eines Teams angewendet werden, auch auf dessen untergeordnete Namenspaces angewendet werden.

    Es gibt jedoch einige Unterschiede zwischen der Weitergabe von Richtlinien durch den Hierarchy Controller und durch Config Sync. Config Sync kopiert alle Objekte in abstrakten Namespace-Verzeichnissen in die untergeordneten Kubernetes-Namespaces. Im Gegensatz dazu kopiert der Hierarchy Controller standardmäßig nur RBAC-Rollen und Rollenbindungen. Dieser kann aber für die Weitergabe jedes anderen Typs eines Kubernetes-Objekts konfiguriert werden.

Der Hierarchie-Controller ist in Config Sync 1.4.1 und höher integriert. Er basiert auf dem Open-Source-Projekt Hierarchical Namespace Controller (HNC).

Hierarchische Namespaces im Vergleich zu abstrakten Namespaces

Die vom Hierarchy Controller bereitgestellten hierarchischen Namespaces sind mit den abstrakten Namespaces von Config Sync vergleichbar. Abstrakte Namespaces sind aber nur im Config Sync-Repository vorhanden. Hierarchische Namespaces sind dagegen immer Kubernetes-Namespaces und im Cluster verfügbar.

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

Alternativ können Sie ein unstrukturiertes Repository verwenden, um die abstrakten Namespaces von Config Sync zu deaktivieren und um ausschließlich mit dem Hierarchy Controller Hierarchien zu definieren und Richtlinien weiterzugeben. Dies kann hilfreich sein, wenn Sie die Standard-Verzeichnisstruktur des Repositorys nicht verwenden können, aber dennoch hierarchische Funktionen nutzen möchten.

Um unstrukturierte Repositories zu nutzen, müssen Sie entweder untergeordnete Namenspaces oder vollständige Namespaces einchecken. Wir empfehlen die Verwendung vollständiger Namespaces, da Sie deren hierarchische Beziehungen durch Änderung des HierarchicalConfiguration-Objekts aktualisieren können. Dieses Objekt müssen Sie ebenfalls einchecken. Wenn Sie dagegen untergeordnete Namenspaces einchecken, achten Sie darauf, dass Sie sowohl die Namespaces als auch die SubnamespaceAnchor-Objekte in deren übergeordneten Namespaces einchecken. Beachten Sie aber, dass diese nach dem Erstellen nicht mehr so einfach geändert werden können.

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