Hierarchy Controller – Übersicht
Der Hierarchy Controller fügt hierarchische Features zu Kubernetes-Namespaces hinzu. Damit können Sie aussagekräftigere Richtlinien schreiben, die Beobachtbarkeit verbessern und die Clusterverwaltung delegieren.
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 für 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 in der Regel verbessern, indem Sie jeden Namespace so einschränken, dass nur die kleinste Anzahl von Ressource, z. B. ein einzelner Mikrodienst, zusammen mit seinen Ressourcen und Richtlinien enthalten ist. Dies kann jedoch zu einer großen Anzahl von Namespaces in Ihren Clustern führen, was in der Verwaltung schwierig sein kann.
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 zusätzlich zu regulären Kubernetes-Namespaces-Features weitere Features:
- Richtlinienerzwingung. Hierarchische Namespaces können Übernehmen bestimmte Richtlinien von ihren Ancestors durch die Nutzung der Weitergabe. So können Sie beispielsweise RBAC-Berechtigungen in einem "Stamm"-Namespace gewähren. Der Hierarchy Controller stellt dann sicher, dass diese Berechtigungen auch in allen untergeordneten Namespaces vorhanden sind. Dazu werden die RBAC-Objekte in diese untergeordneten Elemente kopiert (weitergegeben). Die Weitergabe kann auch mithilfe von Ausnahmen bis auf Detailebene gesteuert werden.
- Richtlinienanwendung. Alle hierarchischen Namespaces enthalten vertrauenswürdige, bekannte Labels, die ihre Ancestors widerspiegeln. Diese Labels können in der Labelauswahl 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 bei der aggregierten Nutzung dieses Namespace sowie bei allen Nachfolgerelementen 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.
- Delegierte Namespace-Erstellung. Mit dem Hierarchy Controller wird das Konzept eines untergeordneten Namespace eingeführt, der von Nutzern unter einem vorhandenen Namespace erstellt werden kann, auch wenn dieser Nutzer keine Namespace-Berechtigungen auf Clusterebene hat.
Hierarchische Namespaces unterstützen auch umfangreiche Verwaltungsfeatures, einschließlich Delegierung.
Hierarchische Namespaces im Vergleich zu abstrakten Namespaces
Die von Hierarchy Controller bereitgestellten hierarchischen Namespaces ähneln den abstrakten Namespaces, die Sie verwenden können, wenn Sie ein hierarchisches Repository von Config Sync verwenden. Sie unterscheiden sich jedoch hinsichtlich mehrerer Konzepte:
- 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 immer reguläre Kubernetes-Namespaces und sind 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 zum Erstellen erforderlich. Stattdessen können Sie untergeordnete Namespaces zum Erstellen von delegierten Namespaces verwenden.
- Hierarchische Ressourcenkontingente werden nur in hierarchischen Namespaces und nicht in abstrakten Namespaces unterstützt.
- 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 ein unterschiedliches Standardverhalten. Standardmäßig werden alle Objekte, die in einem abstrakten Namespace erstellt werden, an die Nachfolgerelemente weitergegeben. Objekte in hierarchischen Namespaces werden hingegen nur weitergegeben, wenn Hierarchy Controller für die Verteilung dieses Objekttyps konfiguriert wurde.
Standardmäßig werden nur RBAC-Rollen und -Rollenbindungen weitergegeben. Es kann aber auch jedes Namespace-Objekt weitergegeben werden. Wir empfehlen, nur Richtlinienobjekte (z. B. Rollen) und Ressourcenobjekte (z. B. Konfigurationspläne) weiterzugeben. Hierarchy-Controller ist nicht für die Weitergabe von Arbeitslastobjekten wie Pods, Deployments oder Jobs konzipiert und kann bei einer solchen Verwendung unbeabsichtigte Folgen haben. Wir empfehlen, Arbeitslasten in Blatt-Namespaces einzufügen.
Hierarchy Controller mit Config Sync verwenden
Mit Hierarchy Controller können Sie Richtlinien mithilfe hierarchischer Konzepte definieren und anwenden. Diese Konzepte sind für viele Anwendungen geeignet, einschließlich Clustern, 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 Features sind unterschiedlich, ergänzen sich aber und bieten 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 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.