Hierarchy Controller – Übersicht

Der Hierarchy Controller fügt Kubernetes-Namespaces hierarchische Features hinzu. So können Sie aussagekräftigere Richtlinien schreiben, die Beobachtbarkeit verbessern und die Clusterverwaltung delegieren.

Der Hierarchy Controller ist in Config Sync ab Version 1.4.1 eingebunden, erfordert jedoch nicht die Verwendung eines Config Sync-Repositorys. Das heißt, Sie können den Hierarchy Controller vollständig auf dem Cluster verwenden, ohne GitOps zu verwenden.

Er basiert auf dem Open-Source-Projekt Hierarchical Namespace Controller (HNC). Die Implementierung erfolgt über Kubernetes-Controller und dynamische Zugangs-Controller, die in Ihrem Cluster ausgeführt werden.

Hierarchische Namespaces

In Kubernetes sind Namespaces die grundlegende Organisationseinheit der meisten Objekte. Sie bilden auch die grundlegende Einheit von Isolation und Sicherheit in Kubernetes. Die meisten Richtlinien und Isolationsobjekte arbeiten auf Namespace-Ebene wie RBAC-Rollen, Secrets, Dienstkonten, Ressourcenkontingente und Netzwerkrichtlinien.

Sie können die Sicherheit und Isolation Ihres Clusters normalerweise verbessern, indem Sie jeden Namespace so einschränken, dass er die kleinste Anzahl von Ressourcen enthält, z. B. einen einzelnen Mikrodienst, zusammen mit seinen Ressourcen und Richtlinien. Dies kann jedoch zu einer großen Anzahl von Namespaces in Ihren Clustern führen, die sich schwierig verwalten lassen.

Um dieses Problem zu lösen, wird mit dem Hierarchy Controller das Konzept hierarchischer Namespaces eingeführt. Damit können Sie Kubernetes-Namespaces gemäß ihren Inhabern gruppieren und diese Gruppen als zusammenhängende Einheiten bearbeiten. Sie sind besonders hilfreich in Clustern, die von mehreren Teams gemeinsam genutzt werden, deren Inhaber aber keine Personen sein müssen. Beispielsweise kann es sein, dass Sie ein automatisiertes Tool zum Inhaber einer Reihe von Namespaces machen, insbesondere wenn es sehr weitreichende Berechtigungen erfordert, aber nur Zugriff auf eine kleine Gruppe zugehöriger Namespaces benötigt.

Zur Unterstützung mehrmandantenfähiger Anwendungsfälle unterstützen hierarchische Namespaces neben den regulären Kubernetes-Namespaces mehrere Features:

  • Richtlinienerzwingung. Hierarchische Namespaces können bestimmte Richtlinien von ihren Ancestors übernehmen. Dazu kann die Weitergabe verwendet werden. Mit dieser Rolle können Sie beispielsweise RBAC-Berechtigungen in einem „Stamm”-Namespace gewähren. Der Hierarchy Controller stellt sicher, dass diese Berechtigungen auch in allen untergeordneten Namespaces vorhanden sind. Dazu werden die RBAC-Objekte an diese untergeordneten Elemente kopiert. Die Weitergabe kann außerdem mit Ausnahmen präzise kontrolliert werden.
  • Richtlinienanwendung. Alle hierarchischen Namespaces haben vertrauenswürdige, bekannte Labels, die ihre Ancestors enthalten. Diese Labels können in Labelselektoren für Richtlinien wie die Validierung von Webhook-Konfigurationen oder Netzwerkrichtlinien verwendet werden.
  • Hierarchisches Kontingent. Sie können ein einzelnes hierarchisches Kontingent in einem Ancestor-Namespace definieren. Die Limits werden automatisch für die aggregierte Nutzung dieses Namespace und aller untergeordneten Elemente erzwungen.
  • Hierarchische Beobachtbarkeit. Die für die Richtlinienanwendung verwendeten vertrauenswürdigen Labels können auch zum Beobachten von hierarchischen Arbeitslasten verwendet werden, z. B. zum Filtern von Logs oder zur Nutzung.
  • 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.

Hierarchische Namespaces unterstützen auch umfangreiche Verwaltungsfunktionen, einschließlich Delegierungen.

Hierarchische Namespaces im Vergleich zu abstrakten Namespaces

Die vom Hierarchy Controller bereitgestellten hierarchischen Namespaces sind mit den abstrakten Namespaces vergleichbar, die Sie verwenden können, wenn Sie ein hierarchisches Repository von Config Sync verwenden. Sie unterscheiden sich jedoch in mehreren Konzepten:

  • Abstrakte Namespaces können nur in einem hierarchischen Repository definiert werden, das eine bestimmte Struktur in Ihren Konfigurationen erzwingt. Hierarchische Namespaces können in unstrukturierten Repositories verwendet werden, sodass Sie Ihre Konfigurationsdateien beliebig anordnen können.
  • Abstrakte Namespaces sind nur in Git-Repositories vorhanden. Hierarchische Namespaces sind dagegen auch reguläre Kubernetes-Namespaces und im Cluster verfügbar. Deshalb können hierarchische Namespaces entweder in einem Repository oder direkt im Cluster definiert werden.
  • Für hierarchische Namespaces sind keine Berechtigungen auf Clusterebene erforderlich. Stattdessen können Sie Sub-Namespaces zum Erstellen von delegierten Namespaces verwenden.
  • Hierarchische Ressourcenkontingente werden nur in hierarchischen Namespaces unterstützt, nicht in abstrakten Namespaces.
  • Abstrakte Namespaces sind nur für Config Sync verfügbar, während hierarchische Namespaces auf Open-Source-Konzepten basieren.

Abstrakte und hierarchische Namespaces haben auch unterschiedliche Standardverhalten. Standardmäßig werden alle Objekte, die in einem abstrakten Namespace erstellt werden, an die untergeordneten Objekte weitergegeben. Objekte in hierarchischen Namespaces werden nur weitergegeben, wenn der Hierarchy Controller für die Verteilung dieses Objekttyps konfiguriert wurde.

Standardmäßig werden nur RBAC-Rollen und Rollenbindungen weitergegeben, aber jedes Namespace-Objekt kann weitergegeben werden. Wir empfehlen, nur Richtlinienobjekte (z. B. Rollen) und Ressourcenobjekte (z. B. Konfigurationspläne) weiterzugeben. Der Hierarchy Controller ist nicht für die Weitergabe von Arbeitslastobjekten wie Pods, Deployments oder Jobs konzipiert und kann unbeabsichtigte Folgen haben, wenn er auf diese Weise verwendet wird. Wir empfehlen, Arbeitslasten in Blatt-Namespaces einzufügen.

Hierarchy Controller mit Config Sync verwenden

Mit dem Hierarchy Controller können Sie Richtlinien mithilfe hierarchischer Konzepte definieren und anwenden. Diese Konzepte sind für viele Anwendungen geeignet, einschließlich Cluster, die von mehreren Teams verwendet werden. Mit Config Sync können Sie diese Richtlinien in einem Git-Repository speichern und auf Gruppen von Clustern anwenden. Diese beiden Funktionen sind zwar kostenlos, bieten aber eine leistungsstarke Möglichkeit, GitOps in Multi-Team- und Multi-Cluster-Umgebungen anzuwenden.

Wenn Sie einen Hierarchy Controller mit Config Sync verwenden, empfehlen wir Ihnen, ein unstrukturiertes Repository zu verwenden, um die abstrakten Namespaces von Config Sync zu deaktivieren. Mit dem Hierarchy Controller können Sie Hierarchien definieren und Richtlinien übertragen. Für die Namespaces, die Sie in Ihrem Repository anmelden möchten, empfehlen wir, nur die Konfigurationen für vollständige Namespaces anzumelden, nicht für Sub-Namespaces, da Sie deren hierarchische Beziehungen durch Ändern des HierarchicalConfiguration-Objekts aktualisieren können.

Sie können Hierarchy Controller zusammen mit den abstrakten Namespaces von Config Sync in einem hierarchischen Repository verwenden, jedoch nur in eingeschränktem Umfang. Mit dem Hierarchy Controller können Sie beispielsweise keine hierarchische Beziehung zwischen zwei Namespaces erstellen, die in einem hierarchischen Repository definiert wurden, da dies mit abstrakten Namespaces in diesem Repository in Konflikt stehen könnte. Sie können jedoch hierarchische Namespaces mit einem hierarchischen Repository auf folgende Weise verwenden:

  • Sie können untergeordnete Self-Service-Sub-Namespaces im Cluster erstellen, unter einem Namespace, der aus einem hierarchischen Repository erstellt wurde. Es wird jedoch nicht empfohlen, die Konfigurationen für diese Sub-Namespaces anzumelden.
  • Wenn Sie mehrere Repositories verwenden, können Sie Subnamespace-Anker in den Namespace-Repositories erstellen, die den Hierarchy Controller anweisen, Sub-Namespaces unter dem angegebenen Namespace zu erstellen. Diese Sub-Namespaces übernehmen alle konfigurierten Ressourcen von ihren Ancestors und werden durch alle hierarchischen Ressourcenkontingente eingeschränkt. Sie können jedoch keine Ressourcen definieren, die nur in diesen Sub-Namespaces vorhanden sein sollen. Config Sync synchronisiert alle Objekte im Namespace-Repository mit dem angegebenen Namespace.

Nächste Schritte