Wenn Sie beginnen, immer mehr Kubernetes-Dienste zu erstellen, werden zunächst einfache Aufgaben immer komplexer. Beispielsweise können Entwicklungsteams keine Dienste oder Bereitstellungen unter demselben Namen erstellen. Wenn Sie über Tausende von Pods verfügen, wird das bloße Auflisten viel Zeit in Anspruch nehmen, ganz zu schweigen von der ordnungsgemäßen Verwaltung. Und das ist nur die Spitze des Eisbergs.
Sehen wir uns an, wie der Namespace die Verwaltung von Kubernetes-Ressourcen erleichtert. Was ist also ein Namespace? Namespace kann als virtueller Cluster innerhalb Ihres Kubernetes-Clusters betrachtet werden. Sie können innerhalb eines einzelnen Kubernetes-Clusters mehrere voneinander isolierte Namespaces haben. Sie können Ihnen und Ihren Teams bei der Organisation, Sicherheit und sogar der Systemleistung wirklich helfen.
Bei den meisten Kubernetes-Distributionen verfügt der Cluster standardmäßig über einen Namespace namens „default“. Tatsächlich gibt es drei Namespaces, mit denen sich Kubernetes befasst: default, kube-system und kube-public. Derzeit wird Kube-public nicht sehr häufig verwendet.
Es ist eine gute Idee, den Kube-Namespace in Ruhe zu lassen, insbesondere auf einem verwalteten System wie Google Kubernetes Engine. Es verwendet den „Standard“-Namespace als Ort, an dem Ihre Dienste und Anwendungen erstellt werden. Es gibt absolut nichts Besonderes daran, außer dass Kubernetes standardmäßig für die Verwendung konfiguriert ist und Sie es nicht entfernen können. Dies eignet sich hervorragend für den Einstieg und für Systeme mit geringer Leistung, ich würde jedoch nicht empfehlen, den Standard-Namespace auf großen Produktionssystemen zu verwenden. Im letzteren Fall kann ein Entwicklungsteam leicht den Code eines anderen umschreiben und die Arbeit eines anderen Teams zerstören, ohne es überhaupt zu merken.
Daher sollten Sie mehrere Namespaces erstellen und diese verwenden, um Ihre Dienste in verwaltbare Einheiten zu segmentieren. Ein Namespace kann mit einem einzigen Befehl erstellt werden. Wenn Sie einen Namespace namens 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.
Sie können alle Namespaces mit dem Befehl $ kubectl get namespace anzeigen.
Sobald dies erledigt ist, sehen Sie drei integrierte Namespaces und einen neuen Namespace namens „test“. Schauen wir uns eine einfache YAML-Datei zum Erstellen eines Pods an. Sie werden feststellen, dass der Namespace nicht erwähnt wird.
Wenn Sie diese Datei mit kubectl ausführen, wird das Modul „mypod“ im aktuell aktiven Namespace erstellt. Dies bleibt der Standard-Namespace, bis Sie ihn ändern. Es gibt zwei Möglichkeiten, Kubernetes mitzuteilen, in welchem Namespace Sie Ihre Ressource erstellen möchten. Die erste Möglichkeit besteht darin, beim Erstellen einer Ressource ein Namespace-Flag zu verwenden.
Die zweite Möglichkeit besteht darin, den Namespace in der YAML-Deklaration anzugeben.
Wenn Sie in YAML einen Namespace angeben, wird die Ressource immer in diesem Namespace erstellt. Wenn Sie versuchen, einen anderen Namespace zu verwenden, während Sie das Namespace-Flag verwenden, schlägt der Befehl fehl. Wenn Sie nun versuchen, Ihren Pod zu finden, wird Ihnen dies nicht gelingen.
Dies liegt daran, dass alle Befehle außerhalb des aktuell aktiven Namespace ausgeführt werden. Um Ihren Pod zu finden, müssen Sie ein Namespace-Flag verwenden. Dies wird jedoch schnell veraltet, insbesondere wenn Sie Entwickler in einem Team sind, das seinen eigenen Namespace verwendet und dieses Flag nicht für jeden einzelnen Befehl verwenden möchte. Mal sehen, wie wir das beheben können.
Standardmäßig heißt Ihr aktiver Namespace „Default“. Wenn Sie im Ressourcen-YAML keinen Namespace angeben, verwenden alle Kubernetes-Befehle diesen aktiven Standard-Namespace. Leider kann der Versuch, den aktiven Namespace mit kubectl zu verwalten, fehlschlagen. Es gibt jedoch ein sehr gutes Tool namens Kubens, das diesen Prozess erheblich vereinfacht. Wenn Sie den Befehl kubens ausführen, werden alle Namespaces angezeigt, wobei der aktive Namespace hervorgehoben ist.
Um den aktiven Namespace auf den Test-Namespace umzustellen, führen Sie einfach den Befehl $kubens test aus. Wenn Sie dann den Befehl $kubens erneut ausführen, werden Sie sehen, dass jetzt ein neuer aktiver Namespace zugewiesen ist – testen Sie.
Das bedeutet, dass Sie das Namespace-Flag nicht benötigen, um den Pod im Test-Namespace zu sehen.
Auf diese Weise sind die Namensräume voneinander verborgen, aber nicht voneinander isoliert. Ein Dienst in einem Namespace kann ganz einfach mit einem Dienst in einem anderen Namespace kommunizieren, was oft sehr nützlich ist. Die Möglichkeit, über verschiedene Namespaces hinweg zu kommunizieren, bedeutet, dass der Dienst Ihres Entwicklers mit dem Dienst eines anderen Entwicklerteams in einem anderen Namespace kommunizieren kann.
Wenn Ihre Anwendung auf einen Kubernetes-Dienst zugreifen möchte, verwenden Sie normalerweise den integrierten DNS-Erkennungsdienst und geben Ihrer Anwendung einfach den Namen des Dienstes. Allerdings können Sie auf diese Weise einen Dienst unter demselben Namen in mehreren Namespaces erstellen, was nicht akzeptabel ist.
Glücklicherweise lässt sich dies leicht umgehen, indem man die erweiterte Form der DNS-Adresse verwendet. Dienste in Kubernetes stellen ihre Endpunkte mithilfe einer gemeinsamen DNS-Vorlage bereit. Es sieht ungefähr so aus:
Normalerweise benötigen Sie nur den Dienstnamen und DNS ermittelt automatisch die vollständige Adresse.
Wenn Sie jedoch auf einen Dienst in einem anderen Namespace zugreifen müssen, verwenden Sie einfach den Dienstnamen plus den Namespace-Namen:
Wenn Sie beispielsweise eine Verbindung zu einer Dienstdatenbank in einem Test-Namespace herstellen möchten, können Sie die Adressdatenbank „database.test“ verwenden
Wenn Sie eine Verbindung zur Servicedatenbank im Namespace prod herstellen möchten, verwenden Sie „database.prod“.
Wenn Sie den Namespace-Zugriff wirklich isolieren und einschränken möchten, können Sie dies mit Kubernetes mithilfe von Kubernetes-Netzwerkrichtlinien tun. Darüber werde ich in der nächsten Folge sprechen.
Mir wird oft die Frage gestellt, wie viele Namespaces soll ich erstellen und zu welchem Zweck? Was ist ein verwaltetes Datenelement?
Wenn Sie zu viele Namespaces erstellen, stehen Ihnen diese nur im Weg. Wenn es zu wenige davon gibt, verlieren Sie alle Vorteile einer solchen Lösung. Ich denke, dass es vier Hauptphasen gibt, die jedes Unternehmen beim Aufbau seiner Organisationsstruktur durchläuft. Abhängig vom Entwicklungsstadium Ihres Projekts oder Unternehmens möchten Sie möglicherweise eine geeignete Namespace-Strategie übernehmen.
Stellen Sie sich vor, Sie sind Teil eines kleinen Teams, das an der Entwicklung von 5–10 Microservices arbeitet, und Sie können problemlos alle Entwickler in einem Raum versammeln. In dieser Situation ist es sinnvoll, alle Produktdienste im Standard-Namespace auszuführen. Für mehr Flexibilität können Sie natürlich zwei Namespaces verwenden – getrennt für prod und dev. Und höchstwahrscheinlich testen Sie Ihre Entwicklung auf Ihrem lokalen Computer mit etwas wie Minikube.
Nehmen wir an, die Dinge ändern sich und Sie haben jetzt ein schnell wachsendes Team, das gleichzeitig an mehr als 10 Microservices arbeitet. Es kommt der Zeitpunkt, an dem es notwendig ist, mehrere Cluster oder Namespaces getrennt für Prod und Dev zu verwenden. Sie können das Team in mehrere Unterteams aufteilen, sodass jedes über seine eigenen Microservices verfügt und jedes dieser Teams seinen eigenen Namensraum wählen kann, um den Prozess der Softwareentwicklung und -freigabe zu vereinfachen.
Da jedes Teammitglied einen Einblick in die Funktionsweise des Systems als Ganzes erhält, wird es immer schwieriger, jede Änderung mit allen anderen Entwicklern zu koordinieren. Der Versuch, einen vollständigen Stapel auf Ihrem lokalen Computer hochzufahren, wird von Tag zu Tag schwieriger.
In großen Unternehmen wissen Entwickler in der Regel nicht, wer genau woran arbeitet. Teams kommunizieren über Serviceverträge oder nutzen die Service-Mesh-Technologie, die dem Netzwerk eine Abstraktionsschicht hinzufügt, wie zum Beispiel das Istio-Konfigurationstool. Der Versuch, einen gesamten Stack lokal auszuführen, ist einfach nicht möglich. Ich empfehle dringend die Verwendung einer CD-Plattform (Continuous Delivery) wie Spinnaker auf Kubernetes. Es kommt also ein Punkt, an dem jeder Befehl definitiv seinen eigenen Namensraum benötigt. Jedes Team kann sogar mehrere Namespaces für die Entwicklungsumgebung und die Produktionsumgebung auswählen.
Schließlich gibt es große Unternehmerunternehmen, in denen eine Gruppe von Entwicklern nicht einmal von der Existenz anderer Gruppen weiß. Ein solches Unternehmen stellt im Allgemeinen Drittentwickler ein, die über gut dokumentierte APIs mit ihm interagieren. Jede dieser Gruppen enthält mehrere Teams und mehrere Microservices. In diesem Fall müssen Sie alle Tools verwenden, über die ich zuvor gesprochen habe.
Programmierer sollten Dienste nicht manuell bereitstellen und keinen Zugriff auf Namespaces haben, die sie nicht betreffen. In dieser Phase ist es ratsam, über mehrere Cluster zu verfügen, um den „Blast-Radius“ schlecht konfigurierter Anwendungen zu verringern und Abrechnungsprozesse und Ressourcenverwaltung zu vereinfachen.
Durch die ordnungsgemäße Nutzung von Namespaces durch Ihr Unternehmen können Sie Kubernetes somit verwaltbarer, kontrollierbarer, sicherer und flexibler machen.
Einige Anzeigen 🙂
Vielen Dank, dass Sie bei uns geblieben sind. Gefallen Ihnen unsere Artikel? Möchten Sie weitere interessante Inhalte sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder an Freunde weiterempfehlen. , ein einzigartiges Analogon von Einstiegsservern, das von uns für Sie erfunden wurde: (verfügbar mit RAID1 und RAID10, bis zu 24 Kerne und bis zu 40 GB DDR4).
Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur hier in den Niederlanden! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbit/s 100 TB – ab 99 $! Lesen über
Source: habr.com