Mit der zunehmenden Erstellung von Kubernetes-Services werden anfangs einfache Aufgaben immer komplexer. Zum Beispiel können Entwicklerteams keine Dienste oder Deployments mit demselben Namen erstellen. Wenn Sie Tausende von Pods haben, wird allein das Auflisten eine Menge Zeit in Anspruch nehmen, ganz zu schweigen von der ordnungsgemäßen Verwaltung. Und das ist nur die Spitze des Eisbergs.
Lassen Sie uns untersuchen, wie Namespaces die Verwaltung von Kubernetes-Ressourcen erleichtern. Was ist ein Namespace? Ein Namespace kann als virtueller Cluster innerhalb Ihres Kubernetes-Clusters betrachtet werden. Sie können mehrere voneinander isolierte Namespaces innerhalb eines Clusters haben. Diese können Ihnen und Ihren Teams tatsächlich bei der Organisation, Sicherheit und sogar der Systemleistung helfen.
In den meisten Kubernetes-Distributionen wird der Cluster standardmäßig mit einem Namespace namens „default“ geliefert. Es gibt tatsächlich drei Namespaces, mit denen Kubernetes umgeht: default, kube-system und kube-public. Aktuell wird kube-public nicht allzu häufig verwendet.
Es ist ratsam, den Namespace kube unberührt zu lassen, insbesondere in einem verwalteten System wie Google Kubernetes Engine. Dieses nutzt den Namespace "default" als Ort, an dem Ihre Dienste und Anwendungen erstellt werden. Es gibt nichts Besonderes daran, außer dass Kubernetes standardmäßig darauf eingestellt ist, ihn zu verwenden, und Sie ihn nicht löschen können. Dies ist ideal für den Einstieg und Systeme mit geringer Leistung, doch in größeren Produktionsumgebungen würde ich empfehlen, den Standard-Namespace nicht zu verwenden. In letzterem Fall könnte ein Entwicklerteam den Code eines anderen Teams leicht überschreiben und die Arbeit eines anderen Teams beeinträchtigen, ohne es zu merken.
Deshalb sollte man mehrere Namespaces erstellen und diese zur Segmentierung Ihrer Dienste in verwaltete Einheiten nutzen. Ein Namespace kann mit einem einzigen Befehl erstellt werden. Wenn Sie einen Namespace mit dem Namen "test" erstellen möchten, verwenden Sie den Befehl $ kubectl create namespace test oder erstellen Sie einfach eine YAML-Datei und verwenden Sie diese wie jede andere Kubernetes-Ressource.
Um alle Namespaces anzuzeigen, können Sie den Befehl $ kubectl get namespace verwenden.
Nach der Ausführung sehen Sie drei integrierte Namespaces sowie einen neuen Namespace mit dem Namen „test“. Lassen Sie uns eine einfache YAML-Datei betrachten, die zur Erstellung eines Pods dient. Es ist anzumerken, dass darin kein Hinweis auf den Namespace enthalten ist.
Wenn Sie kubectl verwenden, um diese Datei auszuführen, wird das Modul mypod im derzeit aktiven Namespace erstellt. Dies ist der Standard-Namespace, bis Sie ihn ändern. Es gibt zwei Möglichkeiten, Kubernetes anzugeben, in welchem Namespace Sie Ihre Ressource erstellen möchten. Der erste Weg ist die Verwendung des Namespace-Flags beim Erstellen der Ressource.
Der zweite Weg besteht darin, den Namespace in der YAML-Deklaration anzugeben.
Wenn Sie den Namespace in YAML angeben, wird die Ressource immer in diesem Namespace erstellt. Wenn Sie versuchen, einen anderen Namespace mit dem Namespace-Flag zu verwenden, wird der Befehl mit einem Fehler beendet. Jetzt, wenn Sie versuchen, Ihren Pod zu finden, werden Sie ihn nicht finden können.
Dies geschieht, weil alle Befehle außerhalb des derzeit aktiven Namensraums ausgeführt werden. Um Ihren Pod zu finden, müssen Sie das Namensraum-Flag verwenden, was jedoch schnell lästig werden kann, insbesondere wenn Sie als Entwickler in einer Gruppe arbeiten, die ihren eigenen Namensraum verwendet und nicht für jeden einzelnen Befehl ein solches Flag nutzen möchte. Lassen Sie uns anschauen, wie wir das beheben können.
Standardmäßig trägt Ihr aktiver Namensraum den Namen default. Wenn Sie das Namensraum im YAML-Ressourcen nicht angeben, verwenden alle Kubernetes-Befehle diesen aktiven Standardnamensraum. Leider kann der Versuch, das aktive Namensraum über kubectl zu verwalten, fehlschlagen. Es gibt jedoch ein sehr nützliches Tool namens Kubens, das diesen Prozess erheblich vereinfacht. Wenn Sie den Befehl kubens ausführen, sehen Sie alle Namensräume mit dem hervorgehobenen aktiven Namensraum.
Um den aktiven Namespace auf den Namespace test zu wechseln, führen Sie einfach den Befehl $ kubens test aus. Wenn Sie danach erneut den Befehl $ kubens eingeben, wird angezeigt, dass jetzt der neue aktive Namespace – test – zugewiesen ist.
Das bedeutet, dass Sie kein Namespace-Flag benötigen, um das Pod im Namespace test zu sehen.
Namespace sind somit voneinander verborgen, aber nicht voneinander isoliert. Ein Dienst aus einem Namespace kann recht einfach mit einem Dienst in einem anderen Namespace kommunizieren, was oft sehr nützlich ist. Die Möglichkeit der Kommunikation zwischen verschiedenen Namespaces ermöglicht es, dass der Dienst Ihrer Entwickler mit dem Dienst eines anderen Entwicklungsteams in einem anderen Namespace interagiert.
Normalerweise, wenn Ihre Anwendung auf einen Kubernetes-Dienst zugreifen möchte, verwenden Sie den integrierten DNS-Dienst zur Dienstentdeckung und geben einfach den Namen des Dienstes an Ihre Anwendung weiter. Dabei können Sie jedoch einen Dienst mit demselben Namen in mehreren Namespaces erstellen, was nicht zulässig ist.
Glücklicherweise lässt sich das leicht umgehen, indem man die erweiterte Form der DNS-Adresse verwendet. Dienste in Kubernetes stellen ihre Endpunkte mithilfe eines allgemeinen DNS-Musters bereit. Das sieht etwa so aus:
In der Regel benötigen Sie einfach den Namen des Dienstes, und das DNS bestimmt automatisch die vollständige Adresse.
Wenn Sie jedoch auf einen Dienst in einem anderen Namensraum zugreifen möchten, verwenden Sie einfach den Dienstnamen plus den Namen des Namensraums:
Wenn Sie beispielsweise eine Verbindung zur Datenbank eines Dienstes im Test-Namensraum herstellen möchten, können Sie die Adresse database.test verwenden.
Wenn Sie hingegen auf die Datenbank des Dienstes im Namensraum prod zugreifen möchten, verwenden Sie database.prod.
Wenn Sie den Zugriff auf einen Namensraum wirklich isolieren und einschränken möchten, ermöglicht Kubernetes dies mit Kubernetes-Netzwerkrichtlinien. Darüber werde ich in der nächsten Reihe berichten.
Ich bekomme oft die Frage, wie viele Namensräume man erstellen sollte und zu welchen Zwecken. Was genau ist ein verwalteter Datenfragment?
Wenn Sie zu viele Namensräume erstellen, werden sie Sie nur behindern. Wenn es zu wenig sind, verlieren Sie alle Vorteile dieser Lösung. Ich denke, dass jede Firma vier grundlegende Phasen durchläuft, wenn sie ihre Organisationsstruktur aufbaut. Je nach Entwicklungsstand Ihres Projekts oder Unternehmens können Sie eine geeignete Strategie zur Erstellung von Namensräumen anwenden.
Stellen Sie sich vor, Sie sind Teil eines kleinen Teams, das an der Entwicklung von 5-10 Mikrodiensten arbeitet, und Sie können alle Entwickler problemlos in einem Raum versammeln. In dieser Situation macht es Sinn, alle Produktionsdienste im Standard-Namensraum zu betreiben. Natürlich können Sie für mehr Flexibilität zwei Namensräume verwenden – einen für Produktion und einen für Entwicklung. Wahrscheinlich testen Sie Ihre Entwicklung auch lokal auf Ihrem Computer mit etwas wie Minikube.
Angenommen, die Rahmenbedingungen haben sich geändert und Sie haben jetzt ein schnell wachsendes Team, das gleichzeitig an mehr als 10 Mikrodiensten arbeitet. Es kommt der Zeitpunkt, an dem Sie mehrere Cluster oder Namensräume benötigen, sowohl für Prod als auch für Dev. Sie können das Team in mehrere Untergruppen aufteilen, sodass jede Gruppe ihre eigenen Mikrodienste hat und jede dieser Gruppen ihren eigenen Namensraum wählen kann, um den Entwicklungs- und Release-Prozess zu erleichtern.
Während jedes Teammitglied ein besseres Verständnis dafür entwickelt, wie das System insgesamt funktioniert, wird es immer schwieriger, jede Änderung mit den anderen Entwicklern abzustimmen. Es wird zunehmend komplizierter, den gesamten Stack auf Ihrem lokalen Computer zum Laufen zu bringen.
In großen Unternehmen wissen die Entwickler oft nicht, wer genau an was arbeitet. Teams kommunizieren über Serviceverträge oder nutzen Technologien wie Service Mesh, die eine Abstraktionsschicht über dem Netzwerk hinzufügen, ähnlich wie das Konfigurationstool Istio. Es ist praktisch unmöglich, den gesamten Stack lokal auszuführen. Ich empfehle dringend, in Kubernetes eine Continuous Delivery (CD)-Plattform wie Spinnaker zu verwenden. Jeder Zeitpunkt, an dem jede Gruppe definitiv ihren eigenen Namensraum benötigt, ist entscheidend. Jede Gruppe kann sogar mehrere Namensräume für die Entwicklungs- und Produktionsumgebung auswählen.
Schließlich gibt es große Unternehmen, in denen eine Entwicklergruppe nicht einmal über die Existenz anderer Gruppen Bescheid weiß. Solch ein Unternehmen kann sogar externe Entwickler einstellen, die über gut dokumentierte APIs interagieren. In jeder dieser Gruppen gibt es mehrere Teams und mehrere Mikrodienste. In diesem Fall ist es notwendig, alle Werkzeuge zu verwenden, über die ich zuvor gesprochen habe.
Entwickler sollten Dienste nicht manuell bereitstellen und keinen Zugriff auf Namespaces haben, die für sie irrelevant sind. In dieser Phase ist es sinnvoll, mehrere Cluster zu verwenden, um den "Explosionradius" schlecht konfigurierter Anwendungen zu reduzieren sowie um die Abrechnungs- und Ressourcenmanagementprozesse zu erleichtern.
Durch die richtige Nutzung der Namespaces in Ihrer Organisation wird Kubernetes kontrollierbarer, sicherer und flexibler.
Ein wenig Werbung 🙂
Danke, dass Sie bei uns bleiben. Gefallen Ihnen unsere Artikel? Möchten Sie mehr interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder uns Ihren Freunden empfehlen. , eine einzigartige Alternative zu Einsteiger-Servern, die wir für Sie entwickelt haben: (Verfügbar sind Optionen mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40GB DDR4).
Dell R730xd im Equinix Tier IV Rechenzentrum in Amsterdam zum halben Preis? Nur bei uns in den Niederlanden! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab 99 $! Lesen Sie darüber
Quelle: habr.com
