Es war schon immer schwierig, eine große Anzahl von Benutzern in einem einzelnen Kubernetes-Cluster sicher zu hosten. Der Hauptgrund ist, dass alle Organisationen Kubernetes unterschiedlich verwenden, sodass ein einzelnes Mehrbenutzermodell wahrscheinlich nicht für alle funktioniert. Stattdessen bietet Kubernetes Komponenten zum Erstellen Ihrer eigenen Lösung an, z. B. Role Based Access Control (RBAC) und NetworkPolicies. Je besser diese Komponenten sind, desto einfacher ist es, einen sicheren Mehrbenutzercluster zu erstellen.
Namespaces eilen zur Rettung
Die mit Abstand wichtigsten dieser Komponenten sind Namespaces . Sie sind die Grundlage für fast alle Richtlinien zur gemeinsamen Nutzung von Sicherheits- und Kontrollebenen in Kubernetes. Beispielsweise unterstützen RBAC, NetworkPolicies und ResourceQuotas standardmäßig Namespaces, während Objekte wie Secret, ServiceAccount und Ingress innerhalb eines Bereichs frei verfügbar sind, jedoch vollständig von anderen isoliert sind .
Namespaces verfügen über einige wichtige Funktionen, die sie ideal für die Durchsetzung von Richtlinien machen. Erstens können sie zur Darstellung von Eigentum verwendet werden . Die meisten Kubernetes-Objekte solltenin einem beliebigen Namespace sein. Durch die Verwendung von Namespaces zur Darstellung des Eigentums können Sie sich immer darauf verlassen, dass diese Objekte einen Eigentümer haben.
Zweitens können nur Benutzer mit den entsprechenden Rechten Namespaces erstellen und verwenden . Sie benötigen erhöhte Berechtigungen, um Namespaces zu erstellen, und andere Benutzer benötigen explizite Berechtigungen, um mit ihnen zu arbeiten, dh um Objekte in diesen Namespaces zu erstellen, anzuzeigen oder zu ändern. Daher wird zunächst ein Namespace mit einer Reihe von Richtlinien erstellt, und erst danach können nicht privilegierte Benutzer "normale" Objekte wie Pods und Dienste erstellen.
Namespace-Einschränkungen
Leider sind Namespaces in der Praxis nicht flexibel genug und passen in einigen gängigen Anwendungsfällen nicht gut. Beispielsweise besitzt ein bestimmtes Team mehrere Microservices mit unterschiedlichen Geheimnissen und Quoten. Im Idealfall sollten sie diese Dienste in separate Namespaces aufteilen, um sie voneinander zu isolieren. Dies führt jedoch zu zwei Problemen.
Erstens fehlt diesen Namespaces ein einziges Konzept des Eigentums, obwohl sie beide demselben Team gehören. Dies bedeutet, dass nicht nur Kubernetes nichts über die Tatsache weiß, dass diese Namespaces einen Eigentümer haben, sondern auch nicht in der Lage ist, globale Richtlinien auf alle kontrollierten Namespaces gleichzeitig anzuwenden.
Zweitens ist, wie Sie wissen, Autonomie der Schlüssel zu effektiver Teamarbeit. Da für die Erstellung von Namespaces erhöhte Berechtigungen erforderlich sind, ist es unwahrscheinlich, dass jemand im Entwicklungsteam über diese Berechtigungen verfügt. Mit anderen Worten, wenn ein Team beschließt, einen neuen Namespace zu erstellen, muss es sich an den Clusteradministrator wenden. Dies mag für ein kleines Unternehmen durchaus akzeptabel sein, aber mit zunehmendem Wachstum werden die negativen Auswirkungen einer solchen Organisation stärker.
Einführung in hierarchische Namespaces
Hierarchische Namespaces sind ein neues Konzept, das von der Kubernetes-Arbeitsgruppe für Mandantenfähigkeit ( wg-Multitenancy ) entwickelt wurde, um diese Probleme anzugehen. In vereinfachter Form ist ein hierarchischer Namespace ein regulärer Kubernetes-Namespace mit einer kleinen benutzerdefinierten Ressource, die auf einen (optionalen) übergeordneten Namespace verweist. Dies erweitert das Konzept des Eigentums auf die Namespaces selbst , nicht nur auf die Objekte in ihnen.
Das Konzept des Eigentums implementiert auch zwei zusätzliche Arten von Beziehungen:
- : namespace' . : subnamespaces, .
Dies löst beide Probleme eines typischen Entwicklerteams. Der Clusteradministrator kann einen "Root" -Bereich zusammen mit den erforderlichen Richtlinien erstellen und die Berechtigung zum Erstellen von Unterbereichen an Teammitglieder delegieren. Auf diese Weise können Entwickler Subnamespaces für den eigenen Gebrauch erstellen, ohne die von den Clusteradministratoren festgelegten Richtlinien zu verletzen.
Ein bisschen Übung
Hierarchische Namespaces werden mithilfe einer Kubernetes-Erweiterung namens Hierarchical Namespace Controller oder HNC implementiert . HNC besteht aus zwei Komponenten:
- Manager arbeitet in einem Cluster, verwaltet Subnamespaces, verteilt Richtlinienobjekte, stellt sicher, dass Hierarchien gültig sind, und verwaltet Erweiterungspunkte.
- Ein Kubectl-Plugin namens
kubectl-hnsermöglicht es Benutzern, mit dem Manager zu interagieren.
Das Handbuch zur Komponenteninstallation finden Sie auf der Release- Seite im Projekt-Repository.
Werfen wir einen Blick darauf, wie HNC funktioniert. Angenommen, ich habe nicht das Recht, Namespaces zu erstellen, aber ich kann den Namespace durchsuchen
team-aund darin Subnamespaces erstellen *. Mit dem Plugin kann ich folgenden Befehl eingeben:
$ kubectl hns create svc1-team-a -n team-a
* Technisch gesehen erstellen Sie im übergeordneten Bereich ein kleines Objekt namens "Subnamespace-Anker", und dann erstellt HNC einen Subnamespace.
Dadurch wird ein Namespace erstellt
svc1-team-a. Bitte beachten Sie, dass sich Subnamespaces nicht von regulären Kubernetes-Namespaces unterscheiden, daher müssen ihre Namen eindeutig sein.
Sie können die resultierende Struktur mit dem folgenden Befehl anzeigen
tree:
$ kubectl hns tree team-a
# Output:
team-a
└── svc1-team-a
Wenn sich im übergeordneten Bereich Richtlinien befinden, werden diese in das untergeordnete Element * kopiert. Angenommen, Sie
team-ahaben eine RBAC-Rollenbindung aufgerufen sres. Diese Rollenbindung wird auch im entsprechenden Namespace angezeigt:
$ kubectl describe rolebinding sres -n svc1-team-a
# Output:
Name: sres
Labels: hnc.x-k8s.io/inheritedFrom=team-a # inserted by HNC
Annotations: <none>
Role:
Kind: ClusterRole
Name: admin
Subjects: …
* Standardmäßig werden nur Rollen und Rollenbindungen in RBAC neu verteilt. Sie können HNC jedoch so konfigurieren, dass jedes Kubernetes-Objekt weitergegeben wird.
Schließlich fügt HNC diesen Namespaces Beschriftungen mit nützlichen Informationen zur Hierarchie hinzu. Sie können verwendet werden, um andere Richtlinien durchzusetzen. Sie können beispielsweise die folgende NetworkPolicy erstellen:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-team-a
namespace: team-a
spec:
ingress:
- from:
- namespaceSelector:
matchExpressions:
- key: 'team-a.tree.hnc.x-k8s.io/depth' # Label created by HNC
operator: Exists
Diese Richtlinie wird an Nachkommen weitergegeben
team-aund ermöglicht auch den eingehenden Datenverkehr zwischen all diesen Namespaces. Nur HNC kann die Bezeichnung "Baum" zuweisen. Es wird garantiert, dass es die aktuelle Hierarchie widerspiegelt.
Details zur HNC-Funktionalität finden Sie im Benutzerhandbuch .
Nächste Schritte und Teilnahme am Prozess
Wenn Sie der Meinung sind, dass ein hierarchischer Namespace in Ihrer Organisation nützlich ist, ist die Version HNC v0.5.1 auf GitHub verfügbar (verfügbar ab 28. August bis Version v0.5.2 - ca. Perevi ..) . Wir möchten wissen, was Sie davon halten, welche Probleme Sie damit lösen und welche Funktionen Sie hinzufügen möchten. Wie bei jeder Software in den frühen Entwicklungsstadien muss bei der Verwendung von HNC in der Produktion vorsichtig vorgegangen werden. Und je mehr Feedback wir erhalten, desto schneller können wir zu HNC 1.0 gelangen.
Wir begrüßen auch Beiträge von Drittanbietern, sei es Fehlerbehebungen / Informationen über diese oder Hilfe beim Prototyping neuer Funktionen wie Ausnahmen, verbesserte Überwachung, hierarchische Ressourcenangabe oder Konfigurationsoptimierung.
Sie können uns im Repository , Newsletter oder Slack kontaktieren . Wir freuen uns auf Ihre Kommentare!
Die ursprüngliche Ankündigung erfolgte durch Adrian Ludwin , Software Engineer und Technical Lead für den Hierarchical Namespace Controller.
Bonus! Roadmap und Themen
Bitte poste Ausgaben - je mehr, desto mehr Spaß! Fehler werden zuerst analysiert und Feature-Anfragen werden priorisiert. Danach werden sie in den Arbeitsplan oder den Rückstand aufgenommen.
HNC hat den GA-Status noch nicht erreicht. Seien Sie also vorsichtig, wenn Sie es in Clustern mit Konfigurationsobjekten verwenden, deren Verlust Sie sich nicht leisten können (z. B. solche, die nicht in einem Git-Repository gespeichert sind).
Alle HNC-Probleme sind im entsprechenden Arbeitsplan enthalten. Derzeit wurden die folgenden Hauptphasen dieses Plans umgesetzt oder geplant:
- v1.0: Ende von I - Beginn von II Quartal 2021; HNC wird für die Produktion empfohlen.
- v0.8: Anfang 2021; Möglicherweise werden neue kritische Funktionen angezeigt.
- v0.7: Ende 2020; höchstwahrscheinlich wird die v1beta1-API angezeigt.
- v0.6: 2020-; v1alpha2 API .
- v0.5: 2020-; , .
- v0.4: 2020-; API production-.
- v0.3: 2020-; UX subnamespace'.
- v0.2: 2019-; non-production.
- v0.1: 2019-; . , - .
- : .
PS vom Übersetzer
Lesen Sie auch in unserem Blog: