Beste Praktiken für Kubernetes. Organisation von Kubernetes mit Namensräumen

Beste Praktiken für Kubernetes. Erstellen kleiner Container

Wenn Sie anfangen, immer mehr Kubernetes-Services zu erstellen, werden die anfangs einfachen Aufgaben komplizierter. Zum Beispiel können Entwicklerteams keine Dienste oder Deployments mit demselben Namen erstellen. Wenn Sie Tausende von Pods haben, wird allein das Auflisten viel Zeit in Anspruch nehmen, ganz zu schweigen von der ordnungsgemäßen Verwaltung. Und das ist nur die Spitze des Eisbergs.

Lassen Sie uns betrachten, wie Namespaces die Verwaltung von Kubernetes-Ressourcen erleichtern. Was ist also ein Namespace? Ein Namespace kann als virtueller Cluster innerhalb Ihres Kubernetes-Clusters angesehen werden. Sie können mehrere voneinander isolierte Namespaces innerhalb eines einzigen Kubernetes-Clusters haben. Diese können Ihnen und Ihren Teams wirklich bei der Organisation, Sicherheit und sogar der Systemleistung helfen.

In den meisten Kubernetes-Distributionen kommt der Cluster "out of the box" mit einem Namespace namens „default“. Es gibt tatsächlich drei Namespaces, mit denen Kubernetes arbeitet: default, kube-system und kube-public. Der Kube-public wird derzeit nicht sehr häufig genutzt.

Es ist eine gute Idee, den Namespace kube nicht anzufassen, insbesondere in einem so verwalteten System wie Google Kubernetes Engine. Es verwendet den Namespace „default“ als Ort, an dem Ihre Dienste und Anwendungen erstellt werden. Es gibt dort absolut nichts Besonderes, außer dass Kubernetes „out of the box“ darauf eingestellt ist und Sie ihn nicht löschen können. Dies ist ideal für den Einstieg und Systeme mit geringer Leistung, aber ich würde nicht empfehlen, den Default-Namespace in großen Produktionssystemen zu verwenden. In letzterem Fall kann ein Entwicklerteam leicht den Code eines anderen Teams überschreiben und die Arbeit des anderen Teams stören, ohne es zu merken.

Daher sollten Sie mehrere Namespaces erstellen und diese zur Segmentierung Ihrer Dienste in verwaltbare 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 sie wie jede andere Kubernetes-Ressource.

Alle Namespaces können mit dem Befehl $ kubectl get namespace angezeigt werden.

Nach der Ausführung sehen Sie drei integrierte Namespaces und einen neuen Namespace mit dem Namen „test“. Betrachten wir eine einfache YAML-Datei, die zur Erstellung eines Pods bestimmt ist. Dabei fällt auf, dass es keine Erwähnung des Namespaces gibt.

Wenn Sie kubectl verwenden, um diese Datei auszuführen, wird ein Modul mypod im aktuellen aktiven Namespace erstellt. Dies wird der Standardnamespace sein, bis Sie ihn ändern. Es gibt zwei Möglichkeiten, Kubernetes anzugeben, in welchem Namespace Sie Ihre Ressource erstellen möchten. Die erste Möglichkeit ist die Verwendung des Namespace-Flags bei der Erstellung der Ressource.

Die zweite Möglichkeit 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, schlägt der Befehl fehl. Wenn Sie jetzt versuchen, Ihren Pod zu finden, werden Sie damit kein Glück haben.

Das passiert, weil alle Befehle außerhalb des aktuellen aktiven Namespaces ausgeführt werden. Um Ihren Pod zu finden, müssen Sie das Namespace-Flag verwenden, aber das wird schnell mühsam, insbesondere wenn Sie Entwickler in einer Gruppe sind, die ihren eigenen Namespace verwendet und dieses Flag nicht für jeden einzelnen Befehl verwenden möchte. Lassen Sie uns sehen, wie wir das beheben können.

Out of the box trägt Ihr aktiver Namespace den Namen default. Wenn Sie keinen Namespace im YAML der Ressource angeben, verwenden alle Kubernetes-Befehle diesen aktiven default 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, sehen Sie alle Namespaces mit dem hervorgehobenen aktiven Namespace.

Um den aktiven Namespace auf den Namespace test umzuschalten, führen Sie einfach den Befehl $ kubens test aus. Wenn Sie danach erneut den Befehl $ kubens eingeben, sehen Sie, dass jetzt der neue aktive Namespace – test – hervorgehoben ist.

Das bedeutet, dass Sie kein Namespace-Flag benötigen, um das Pod im Namespace test zu sehen.

So sind die Namespaces untereinander verborgen, aber nicht isoliert. Ein Dienst aus einem Namespace kann relativ einfach mit einem Dienst in einem anderen Namespace kommunizieren, was häufig sehr nützlich ist. Die Möglichkeit zur Kommunikation zwischen verschiedenen Namespaces bedeutet, dass der Dienst Ihrer Entwickler mit dem Dienst eines anderen Entwicklungsteams in einem anderen Namespace interagieren kann.

In der Regel, wenn Ihre Anwendung auf einen Kubernetes-Dienst zugreifen möchte, nutzen Sie den integrierten DNS-Dienst zur Entdeckung und geben einfach den Namen des Dienstes an. Dabei können Sie jedoch einen Dienst mit demselben Namen in mehreren Namespaces erstellen, was nicht zulässig ist.

Glücklicherweise ist dies leicht zu umgehen, indem Sie die voll ausgeschriebene Form der DNS-Adresse verwenden. Dienste in Kubernetes exponieren ihre Endpunkte unter Verwendung einer gemeinsamen DNS-Vorlage. Das sieht ungefähr so aus:

In der Regel benötigen Sie einfach den Namen des Dienstes, 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 auf die Datenbank des Dienstes im Test-Namespace zugreifen möchten, können Sie die Adresse database.test verwenden.

Wenn Sie hingegen auf die Datenbank des Dienstes im Prod-Namespace zugreifen möchten, verwenden Sie database.prod.

Wenn Sie wirklich isolieren und den Zugriff auf einen Namespace einschränken möchten, ermöglicht Kubernetes dies durch die Kubernetes Network Policies. Darüber werde ich in der nächsten Folge sprechen.

Ich bekomme häufig die Frage, wie viele Namespaces erstellt werden sollen und zu welchem Zweck. Was ist also ein verwalteter Datenausschnitt?

Wenn Sie zu viele Namensräume erstellen, stehen sie Ihnen einfach im Weg. Sind es jedoch zu wenige, verlieren Sie alle Vorteile einer solchen Lösung. Ich denke, es gibt vier grundlegende Phasen, die jedes Unternehmen bei der Erstellung seiner Organisationsstruktur durchläuft. Je nach Entwicklungsphase, in der sich Ihr Projekt oder Unternehmen befindet, können Sie die entsprechende Strategie zur Erstellung von Namensräumen übernehmen.

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 Prod-Dienste im Namensraum 'default' zu starten. Natürlich können Sie für mehr Spielraum auch 2 Namensräume verwenden – getrennt für Prod und Dev. Wahrscheinlich 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 Mikrodiensten arbeitet. Der Zeitpunkt kommt, an dem Sie mehrere Cluster oder Namensräume verwenden müssen, getrennt für Prod und Dev. Sie können das Team in mehrere Untergruppen aufteilen, sodass jede ihre eigenen Mikrodienste hat und jedes dieser Teams seinen eigenen Namensraum auswählen kann, um den Entwicklungs- und Veröffentlichungsprozess zu erleichtern.

Während jedes Teammitglied ein Verständnis dafür entwickelt, wie das System insgesamt funktioniert, wird es immer schwieriger, jede Änderung mit allen 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 überhaupt nicht, wer an was konkret arbeitet. Teams kommunizieren über Serviceverträge oder verwenden eine Service-Mesh-Technologie, die über dem Netzwerk eine Abstraktionsebene wie das Konfigurationstool Istio hinzufügt. Es ist schlichtweg unmöglich, den gesamten Stack lokal zu starten. Ich empfehle dringend, in Kubernetes eine kontinuierliche Bereitstellungsplattform (CD) wie Spinnaker zu verwenden. Damit kommt der Zeitpunkt, an dem jedes Team definitiv seinen eigenen Namensraum benötigt. Jedes Team kann sogar mehrere Namensräume für die Entwicklungs- und Produktionsumgebung auswählen.

Schließlich gibt es große Unternehmensunternehmen, in denen eine Entwicklergruppe nicht einmal von der Existenz anderer Gruppen weiß. Ein solches 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 Tools zu nutzen, von denen ich zuvor gesprochen habe.

Programmierer sollten Dienste nicht manuell bereitstellen und sollten keinen Zugriff auf Namensräume haben, die sie nicht betreffen. An diesem Punkt ist es sinnvoll, mehrere Cluster zu haben, um den «Sprengradius» schlecht konfigurierter Anwendungen zu verringern, sowie um die Abrechnungs- und Ressourcenmanagementprozesse zu vereinfachen.

So ermöglicht die richtige Nutzung von Namensräumen durch Ihre Organisation, Kubernetes verwaltbarer, kontrollierbarer, sicherer und flexibler zu gestalten.

Beste Praktiken für Kubernetes. Überprüfen der Lebensfähigkeit von Kubernetes mit Readiness- und Liveness-Tests

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 Freunden empfehlen, Cloud-VPS für Entwickler ab 4,99 $, ein einzigartiges Äquivalent zu Einsteigerservern, das wir für Sie entwickelt haben: Die ganze Wahrheit über VPS (KVM) E5-2697 v3 (6 Kerne) 10GB DDR4 480GB SSD 1Gbps ab 19 $ oder wie man einen Server richtig teilt? (es sind Optionen mit RAID1 und RAID10 bis zu 24 Kernen und bis zu 40GB DDR4 verfügbar).

Dell R730xd ist im Equinix Tier IV Rechenzentrum in Amsterdam doppelt so günstig? Nur bei uns 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB ab $199 in den Niederlanden! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ab $99! Lesen Sie, wie man eine Unternehmensinfrastruktur der Klasse C mit Dell R730xd E5-2650 v4-Servern für 9000 Euro im Preis-Leistungs-Verhältnis aufbaut?

Quelle: habr.com