Best Practices von Kubernetes. Kubernetes Organisation mit Namespace

Best Practices von Kubernetes. Erstellen kleiner Container

Wenn Sie mehr und mehr Kubernetes-Dienste erstellen, werden einfach zu startende Aufgaben komplizierter. Beispielsweise können Entwicklungsteams keine Services oder Bereitstellungen unter demselben Namen erstellen. Wenn Sie Tausende von Herden haben, wird eine einfache Auflistung viel Zeit in Anspruch nehmen, ganz zu schweigen von der normalen Verwaltung. Und das ist nur die Spitze des Eisbergs.

Lassen Sie uns einen Blick darauf werfen, wie der Namespace-Namespace die Ressourcenverwaltung von Kubernetes vereinfacht. Was genau ist ein Namespace? Der Namespace kann als virtueller Cluster in Ihrem Kubernetes-Cluster betrachtet werden. Innerhalb desselben Kubernetes-Clusters können mehrere Namespaces voneinander isoliert sein. Sie können Ihnen und Ihren Teams bei Organisation, Sicherheit und sogar Systemleistung wirklich helfen.



Bei den meisten Kubernetes-Distributionen ist der Cluster "out of the box" mit einem Namespace namens "default". Es gibt tatsächlich drei Namespaces, mit denen sich Kubernetes befasst: default, kube-system und kube-public. Derzeit wird Kube-public nicht sehr oft verwendet.



Es ist eine gute Idee, den Kube-Namespace nicht zu berühren, insbesondere auf einem verwalteten System wie der Google Kubernetes Engine. Es verwendet den Standard-Namespace als Ort, an dem Ihre Dienste und Anwendungen erstellt werden. Es ist absolut nichts Besonderes daran, außer dass Kubernetes standardmäßig für die Verwendung konfiguriert ist und Sie es nicht entfernen können. Dies ist ideal für den Einstieg und für Systeme mit geringer Leistung. Ich würde jedoch nicht empfehlen, den Standard-Namespace in großen Produktsystemen zu verwenden. Im letzteren Fall kann ein Entwicklungsteam den Code eines anderen leicht umschreiben und die Arbeit eines anderen Teams stören, ohne es zu merken.

Daher sollten Sie mehrere Namespaces erstellen und diese verwenden, um Ihre Dienste in verwaltbare Links 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 sie wie jede andere Kubernetes-Ressource.



Sie können alle Namespaces mit dem Befehl $ kubectl get namespace anzeigen.



Nach der Ausführung sehen Sie drei integrierte Namespaces und einen neuen Namespace namens "test". Schauen wir uns eine einfache YAML-Datei zum Erstellen von Pods an. Möglicherweise stellen Sie fest, dass darin kein Namespace erwähnt wird.



Wenn Sie diese Datei mit kubectl ausführen, wird das mypod-Modul im aktuell aktiven Namespace erstellt. Dies ist 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 der Ressource das 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 Bereich erstellt. Wenn Sie versuchen, bei Verwendung des Namespace-Flags einen anderen Namespace zu verwenden, schlägt der Befehl fehl. Wenn Sie jetzt versuchen, Ihren Pod zu finden, können Sie dies nicht tun.



Dies liegt daran, dass alle Befehle außerhalb des aktuell aktiven Namespace ausgeführt werden. Um Ihren Pod zu finden, müssen Sie das Namespace-Flag verwenden. Dies ist jedoch schnell langweilig, insbesondere wenn Sie als Entwickler in einer Gruppe arbeiten, die einen eigenen Namespace verwendet und nicht für jeden einzelnen Befehl ein solches Flag verwenden möchte. Mal sehen, wie das behoben werden kann.



Ihr aktiver Namespace wird standardmäßig als Standard bezeichnet. Wenn Sie den Namespace nicht in der YAML der Ressource angeben, verwenden alle Kubernetes-Befehle diesen aktiven Standard-Namespace. Leider kann ein 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 mit dem hervorgehobenen aktiven Namespace angezeigt.



Um den aktiven Namespace in den Test-Namespace zu ändern, führen Sie einfach den Testbefehl $ kubens aus. Wenn Sie danach den Befehl $ kubens erneut eingeben, können Sie sehen, dass jetzt ein neuer aktiver Namespace zugewiesen ist - test.



Dies bedeutet, dass Sie kein Namespace-Flag benötigen, um den Pod im Test-Namespace anzuzeigen.



Daher sind Namespaces voneinander verborgen, aber nicht voneinander isoliert. Ein Dienst aus einem Namespace kann recht einfach mit einem Dienst in einem anderen Namespace kommunizieren, was häufig sehr nützlich ist. Die Fähigkeit, zwischen verschiedenen Namespaces zu kommunizieren, bedeutet, dass der Dienst Ihrer Entwickler mit dem Dienst eines anderen dev-Befehls in einem anderen Namespace interagieren kann.

Wenn Ihre Anwendung auf den Kubernetes-Dienst zugreifen möchte, verwenden Sie normalerweise den integrierten DNS-Erkennungsdienst und geben Ihrer Anwendung nur den Namen des Dienstes. Sie können jedoch einen Dienst unter demselben Namen in mehreren Namespaces erstellen, was ungültig ist.



Glücklicherweise kann dies durch die Verwendung der erweiterten Form der DNS-Adresse leicht umgangen werden. Dienste bei Kubernetes legen ihre Endpunkte mithilfe eines gemeinsamen DNS-Musters offen. Es sieht ungefähr so ​​aus:



In der Regel benötigen Sie nur den Namen des Dienstes, und DNS ermittelt automatisch die vollständige Adresse.



Wenn Sie jedoch in einem anderen Namespace auf den Dienst zugreifen müssen, verwenden Sie einfach den Dienstnamen plus den Namespace-Namen:



Wenn Sie beispielsweise im Test-Namespace eine Verbindung zur Dienstdatenbank herstellen möchten, können Sie die Datenbankadresse database.test verwenden.



Wenn Sie eine Verbindung herstellen möchten Für die Servicedatenbank im Prod-Namespace verwenden Sie database.prod.



Wenn Sie den Zugriff auf den Namespace wirklich isolieren und einschränken möchten, können Sie dies mit Kubernetes mithilfe der Kubernetes-Netzwerkrichtlinien tun. Ich werde in der nächsten Serie darüber sprechen.

Ich werde oft gefragt, wie viele Namespaces für welche Zwecke erstellt werden müssen. Was ist ein verwaltetes Datenelement?

Wenn Sie zu viele Namespaces erstellen, stehen diese Ihnen 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 bei der Erstellung seiner eigenen Organisationsstruktur durchläuft. Abhängig von der Entwicklungsphase, in der sich Ihr Projekt oder Unternehmen befindet, können Sie die entsprechende Strategie zum Erstellen eines Namespace festlegen.

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 zusammenstellen. In dieser Situation ist es sinnvoll, alle Produktdienste im Standard-Namespace auszuführen. Für einen größeren Handlungsspielraum können Sie natürlich zwei Namespaces verwenden - getrennt für prod und dev. Und höchstwahrscheinlich testen Sie Ihre Entwicklung auf einem lokalen Computer mit etwas wie Minikube.

Angenommen, die Bedingungen haben sich geändert und jetzt haben Sie ein schnell wachsendes Team, das gleichzeitig an mehr als 10 Microservices arbeitet. Es kommt eine Zeit, in der Sie mehrere Cluster oder Namespaces separat für prod und dev verwenden müssen. Sie können ein Team in mehrere Untergruppen aufteilen, sodass jede über eigene Microservices verfügt und jedes dieser Teams einen eigenen Namespace auswählen kann, um die Verwaltung der Entwicklung und Veröffentlichung von Software zu vereinfachen.



Da jedes Teammitglied eine Vorstellung davon bekommt, wie das System insgesamt funktioniert, wird es immer schwieriger, jede Änderung mit allen anderen Entwicklern zu koordinieren. Der Versuch, einen vollständigen Stapel auf Ihrem lokalen Computer zu drehen, wird von Tag zu Tag schwieriger.

In großen Unternehmen wissen Entwickler überhaupt nicht, wer genau an was arbeitet. Teams kommunizieren über Serviceverträge oder verwenden die Service-Mesh-Technologie, die eine Abstraktionsschicht über das Netzwerk hinzufügt, z. B. das Istio-Konfigurationstool. Der Versuch, den gesamten Stack lokal auszuführen, ist einfach nicht möglich. Ich empfehle dringend, eine CD-Plattform (Continuous Delivery) wie Spinnaker auf Kubernetes zu verwenden. Es kommt also der Moment, in dem jedes Team definitiv seinen eigenen Namespace benötigt. Jeder Befehl kann sogar mehrere Namespaces für die Entwicklungsumgebung und die Produktumgebung auswählen.

Schließlich gibt es große unternehmerische Unternehmen, in denen eine Entwicklungsgruppe nicht einmal über die Existenz anderer Gruppen informiert ist. Ein solches Unternehmen kann im Allgemeinen Entwickler von Drittanbietern einstellen, die über gut dokumentierte APIs interagieren. In jeder dieser Gruppen gibt es mehrere Teams und mehrere Mikrodienste. In diesem Fall müssen Sie alle zuvor genannten Tools verwenden.



Programmierer sollten Dienste nicht manuell bereitstellen und keinen Zugriff auf Namespaces haben, die sie nicht betreffen. In dieser Phase ist es ratsam, mehrere Cluster zu haben, um den "Explosionsradius" schlecht konfigurierter Anwendungen zu verringern und die Abrechnungs- und Ressourcenverwaltungsprozesse zu vereinfachen.

Durch die korrekte Verwendung der Namespaces Ihres Unternehmens werden Kubernetes übersichtlicher, verwaltbarer, sicherer und flexibler.

Best Practices von Kubernetes. Kubernetes Lebensfähigkeitstest mit Bereitschafts- und Lebendigkeitstests

Ein bisschen Werbung :)

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden Cloud-basiertes VPS für Entwickler ab 4,99 US-Dollar empfehlen , ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10 GB DDR4 480 GB SSD 1 Gbit / s ab 19 $ oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

Dell R730xd 2-mal günstiger im Equinix Tier IV-Rechenzentrum in Amsterdam? Nur wir haben 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2,6 GHz 14C 64 GB DDR4 4 x 960 GB SSD 1 Gbit / s 100 TV von 199 US-Dollar in den Niederlanden!Dell R420 - 2x E5-2430 2,2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbit / s 100 TB - ab 99 US-Dollar! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse C mit Dell R730xd E5-2650 v4-Servern für 9.000 Euro für einen Cent?