Kubernetes-Architektur – eine Einführung zu K8s

CloudPUBLISHED ON Januar 22, 2021 | MODIFIED ON Januar 22, 2021

Author

Kubernetes artchitecture explained. An introductor guide to K8s

Der beste Einstieg in unsere Reihe „Kubernetes Beratung“ wäre eigentlich die Einführung in die Kubernetes-Architektur gewesen. Ich sage hier bewusst „wäre“, denn dies ist bereits der zigste Eintrag in unserer Reihe (ich komm‘ selbst mit dem Zählen nicht mehr hinterher J).

Aber wie heißt das Sprichwort doch so schön: besser spät, als nie! Diese grundlegende Einführung in Kubernetes basiert auf der wunderbar einfachen Erklärung der Container-Orchestrierungstechnologie von IBM.

Was ist Kubernetes?

Kubernetes ist ein Orchestrierungs-Tool, mit dem wir Container-gestützte Workloads ausführen und verwalten können. Um diesen Sachverhalt besser zu erklären, werfen wir einen Blick auf eine Referenzarchitektur verwalteter Dienste und gehen dabei ein wenig tiefer in die Bereitstellung der Microservices ein.

[text_on_the_background title=“WANN FUNKTIONIERT OUTSOURCING?“] (und wann nicht?)
HIER finden Sie die Antwort.[/text_on_the_background]

Eine Kubernetes-Architektur besteht aus zwei Seiten – Cloud und Kunde

Eine Kubernetes-Architektur kann in zwei Seiten unterteilt werden:

  • Cloud-verwaltete Seite von K8s
  • Kunden-verwaltete Seite von K8s

Cloud-Seite – API-Server und Master Node

Die wichtigste Komponente auf der Cloud-Seite der Kubernetes-Architektur ist der K8-Master beziehungsweise der Master Node. Der Kubernetes-Master enthält eine Vielzahl von unentbehrlichen Komponenten, von denen der API-Server eine der wichtigsten Rollen einnimmt.

Kubernetes API-Server

Der auf dem Master ausgeführte Kubernetes-API-Server ist ein wesentlicher Bestandteil, wenn es um die Ausführung der Workloads geht. Er bietet eine Reihe von Funktionen, mit denen wir genau definieren können, wie diese Workloads ausgeführt werden sollen.

Kundenseitig – Woker Nodes und Kubelets

Worker Nodes, die alle ebenfalls auf Kubernetes basieren, befinden sich auf der vom Kunden verwalteten Seite. Jeder Worker Node enthält ein Kubelet.

Das Kubelet ist für die Planung verantwortlich und stellt sicher, dass Apps fehlerfrei laufen und auf den Worker Nodes ausgeführt werden. Wie man hieraus bereits schlussfolgern kann, arbeiten der Master Node und Kubelets häufig zusammen.

Warum sollte man Kubernetes verwenden?

Gehen wir erstmal einen Schritt zurück und stellen uns die grundlegende Frage: „Warum sollte man Kubernetes überhaupt verwenden?“

Microservices

Wenn wir eine Cloud-native Anwendung haben, die aus Microservices besteht, müssen diese Microservices über das Netzwerk miteinander kommunizieren. Nehmen wir als vereinfachtes Beispiel an, wir haben ein Frontend und ein Backend und wir möchten diese beiden Komponenten skalieren und im Cluster bereitstellen – und das noch heute.

Kubernetes verwendet YAML, um die Ressourcen zu definieren, die an den API-Server gesendet werden und um am Ende die eigentliche Anwendung zu erstellen. Wie würde eine einfache YAML für die Bereitstellung eines Pods aussehen, einer kleinen logischen Einheit, mit der wir einen einfachen Container in einem Worker Node ausführen können?

Wir beginnen mit einem Pod und einem damit verbundenen Image. Nehmen wir an, es handelt sich hierbei um einen Container, den wir bereits auf den Docker Hub übertragen haben. Wir verwenden eine Registry und nennen die Anwendung „fv.1.0“.

Wir bedienen uns ebenfalls Labels, auf die wir in Kürze noch genauer eingehen werden. Mithilfe von Labels lässt sich genau definieren, um welche Art von Artefakt es sich handelt. Von den Labels wird erwartet, dass sie so etwas sagen wie: „Die App ist f“:

Etiketten – a:f

Nachdem der Pod erstellt wurde, möchten wir ihn durch unseren Prozess in eine Worker Node verschieben.

Kubectl

Genau hier kommt Kubectl ins Spiel. Mit Kubectl stellen wir das einfache Manifest, das von unserem Pod dargestellt wird, in einem der Worker Nodes bereit. Das Pod-Manifest wird durch den Kubetcl geschoben, trifft auf die Kubernetes-API, die auf dem K8s-Master ausgeführt wird und spricht dann wiederum mit einem der Kubelets auf der Kundenseite unserer Architektur.

Das Kubelet startet dann den Pod in seinem Worker Node. Dem Pod wird außerdem eine interne IP-Adresse zugewiesen. Zu diesem Zeitpunkt könnten wir SSH in jeden der Worker Nodes einbinden und die IP verwenden, um diese Anwendung zu erreichen.

Dies umfasst die Bereitstellung einer einfachen Anwendung innerhalb einer Kubernetes-Architektur. Gehen wir also noch einen Schritt weiter…

Kubernetes-Deployments und Desired State

Kubernetes hat eine Abstraktion namens „Deployments“ (zu Deutsch: Bereitstellungen) mit der wir etwas erstellen können, das als „Desired State“ (Soll-Zustand) bezeichnet wird. Wir können die Anzahl der Replikate definieren, die wir für einen Pod benötigen. Wenn mit diesem Pod etwas passiert, wird einfach ein neuer erstellt.

Kehren wir nun zum Pod zurück, den wir auf einem Worker Node bereitgestellt und als App:f gekennzeichnet haben:. Wir möchten 3 Replikate zu diesem Pod erstellen. Kehren wir auch zu unserem ursprünglichen Manifest auf der Cloud-Seite zurück. Eine Sache, die wir Kubernetes mitteilen müssten, wäre, dass wir keinen Pod, sondern eine Vorlage für einen Pod benötigen.

Darüber hinaus gibt es noch ein paar andere Dinge, die wir beachten sollten. Wir müssen die Anzahl der Replikate definieren, zum Beispiel 3. Wir haben zudem einen Selector und verwenden diesen, um das Deployment anzuweisen, alle Anwendungen zu verwalten, die mit dem Namen (app: f) bereitgestellt werden, der ebenfalls auf unserem Worker Node ausgeführt wird.

Und zum Schluss müssen wir definieren, um welche Art von Artefakt es sich handelt – ein Deployment. Unser neues Manifest wird dementsprechend ungefähr so ​​aussehen:

Kubernetes deployment manifest YAML

Wir schieben das neue Manifest durch Kubectl und es erreicht den API-Server. Hierbei sollte beachtet werden, dass das Manifest kein kurzlebiges Objekt ist. Kubernetes muss den Soll-Zustand verwalten. Solange wir die Bereitstellung haben und sie nicht gelöscht wurde, wird sie von Kubernetes in unserem Master Node verwaltet.

Kubernetes master node

Unser Master Node erstellt jetzt ein Deployment. Da wir drei Replikate haben, wird sichergestellt, dass immer drei ausgeführt werden. Sobald das Deployment erstellt wurde, wird festgestellt, dass derzeit nur ein einziges Replikat auf unserem Working Node ausgeführt wird und dass zwei weitere erforderlich sind.

Der Master Node plant die Bereitstellung der Anwendung in 3 Replikaten überall dort, wo unsere Kubernetes-Architektur über Ressourcen auf der Kundenseite verfügt. Es werden also weitere zwei in leere Worker Nodes platziert, die noch verfügbar sind.

Kubernetes architecture sketch 1

Wir haben nun unser Kubernetes-Deployment erstellt. Wenn wir dasselbe für das Backend unserer Anwendung machen müssen, erstellen wir hierzu ein weiteres Anwendungs-Deployment. In unserem Main Node fügen wir App: Backend hinzu und skalieren es beispielsweise mit 2 Replikaten. Wir haben jetzt so etwas wie:

Kubernetes architecture sketch 2

Wie kommunizieren Services in einer Kubernetes-Architektur?

Jetzt gilt es, über die Kommunikation zwischen den Services nachzudenken, die wir auf der Kundenseite unserer K8-Architektur bereitgestellt haben. Wie bereits erwähnt, hat jeder Pod eine IP-Adresse. Aber einige könnten Fehler aufweisen oder müssen irgendwann aktualisiert werden.

Wenn ein Pod verschwindet und zurückkommt, geschieht dies mit einer anderen IP-Adresse. Wenn wir jedoch vom Backend oder sogar von externen Benutzern auf einen dieser Pods zugreifen möchten, benötigen wir eine IP-Adresse, auf die wir uns verlassen können. Dies ist ein seit langem bestehendes Problem – daher wurden Service-Registry- und Service-Recovery-Funktionen speziell für dieses Problem entwickelt.

Diese Funktionen sind in Kubernetes integriert. Jetzt werden wir einen Dienst erstellen, um eine stabilere IP-Adresse festzulegen, damit wir durch eine einzelne App und nicht durch separate Services auf unsere Pods zugreifen können.

Wir treten erneut einen Schritt zurück und erstellen eine Service-Definition für unsere drei Pods. Hierzu benötigen wir einige neue Manifeste in YAML, wofür wir einen neuen Abschnitt in unserer Datei erstellen. Wir müssen kind: service und einen Selector hinzufügen, der mit dem App-Label übereinstimmt. Zuletzt brauchen wir noch einen type – dies ist unsere Cluster-IP, damit wir auf Dinge innerhalb des Kubernetes-Clusters zugreifen können. Das Resultat sieht in etwa wie folgt aus:

Kubernetes deployment manifest YAML with service and selector for clustering

Wir stellen unser YAML erneut über Kubectl bereit. Es wird unseren Master erreichen und dann auf die Kundenseite übertragen, um die jeweilige Abstraktion zu erstellen, die unsere Pods zu einer einzigen Anwendung gruppiert. Wir haben jetzt eine interne Cluster-IP, mit der wir die Kommunikation zwischen unseren Diensten gewährleisten können:

Kubernetes architecture sketch 3

Darüber hinaus ermöglicht der DNS-Dienst von Kubernetes, der normalerweise standardmäßig ausgeführt wird, dass selbst unsere Services leichter aufeinander zugreifen können, indem nur ihre Namen wie Frontend und Backend oder kurz f und b verwendet werden.

Wie stellen wir Nutzern unser Frontend zur Verfügung?

Um nun einen Schritt weiterzugehen und das Frontend unserer Anwendung Endnutzern zugänglich zu machen, müssen wir die Art des Dienstes definieren. In diesem Falle brauchen wir einen Load Balancer. Es gibt andere Optionen, um dies zu erreichen, wie beispielsweise Node Ports, aber ein Load Balancer erstellt eine externe IP zu unserem Cluster.

Wir geben diese externe IP-Adresse dann direkt an Endnutzer weiter, die anschließend hierüber direkt auf das Frontend zugreifen können.

Kubernetes architecture sketch 4

Unser Fazit

Wir haben drei Hauptkomponenten einer Kubernetes-Architektur besprochen:

  1. Pods
  2. Bereitgestellte und anschließend von Deployments verwaltete Pods
  3. Erleichterung des Zugriffs auf die von diesen Deployments erstellten Pods mithilfe von Services

Dies sind die drei Hauptkomponenten, die mit den Kubernetes-Master- und Worker Node zusammenarbeiten, damit wir den DevOps-Workflow für die Bereitstellung von Anwendungen in einem verwalteten Kubernetes-Dienst nach unseren Wünschen neu definieren können.

[text_on_the_background title=“K&C – WIR KREIEREN EINZIGARTIGE TECH-LÖSUNGEN SEIT ÜBER 20 JAHREN. WIR VERSCHAFFEN IHNEN IHREN WETTBEWERBSVORTEIL!“] Schreiben Sie uns eine Nachricht, um Ihre individuellen Bedürfnisse oder das nächste Projekt zu besprechen.
HIER finden Sie die Antwort.[/text_on_the_background]

Related Service

Webentwicklungsagentur – Angular

Read more >

Cloud+Web Entwicklung

Read more >

Softwareentwicklung für Startups

Read more >