Microservice- und App-Bereitstellung mit K8s

Container lokal oder als Dienst nutzen

| Autor / Redakteur: Thomas Joos / Stephan Augsten

Eine einfache Möglichkeit, um Container zu erstellen, bietet das Befehlszeilentool „kubectl“.
Eine einfache Möglichkeit, um Container zu erstellen, bietet das Befehlszeilentool „kubectl“. (Bild: Joos / Kubernetes)

Arbeiten Unternehmen mit Kubernetes, können sie Anwendungen entweder lokal bereitstellen oder mittels Container as a Service, kurz CaaS. Dieser Beitrag zeigt die Möglichkeiten auf.

Container lassen sich mithilfe lokaler Kubernetes-Installationen bereitstellen, aber auch über Cloud-Dienste. Jeder der drei großen Cloud-Anbieter – sprich Google, Amazon und Microsoft – stellt solche „Container as a Service“-Umgebungen zur Verfügung.

Dazu stehen in der jeweiligen Umgebung die Dienste Google Container Engine, Amazon EC2 Container Service und Azure Container Services zur Verfügung. Dazu kommt, dass in den jeweiligen Umgebungen auch virtuelle Server bereitgestellt werden können, in denen Kubernetes betrieben wird. Die Kubernetes-Entwickler stellen auf Ihrer Webseite Tutorials zur Verfügung, mit denen Entwickler die Erstellung von Apps und der dazugehörigen Pods und Container erlernen können.

Grundlagen für Container-Anwendungen

Um Anwendungen in Containern zur Verfügung zu stellen, muss zuerst ein Kubernetes-Cluster zur Verfügung stehen. Dieser stellt die Grundlage der Container-Anwendungen dar. Anwendungen werden mit Deployments bereitgestellt. Ein Deployment steuert Kubernetes und legt fest, wie die Anwendung in den Containern der Umgebung zur Verfügung gestellt werden soll.

Wenn das Deployment erstellt wurde, kann der Kubernetes-Master die Instanz der Anwendung auf den Knoten im Cluster zur Verfügung stellen. Die Instanzen der Anwendungen werden mit dem Kubernetes Deployment Controller auf den verschiedenen Knoten im Cluster überwacht. Die Kontrolle über den Cluster liegt weiterhin beim Master. Deployments werden zum Beispiel über eine YAML-Konfigurationsdatei zur Verfügung gestellt. In dieser sind alle Informationen für den Cluster integriert, die für das Starten einer Anwendung notwendig sind.

Der Vorteil bei dieser Architektur besteht darin, dass der Kubernetes-Cluster immer die Kontrolle über die Instanz der Anwendung hat. Fällt ein Server aus, kann Kubernetes die App auf einem anderen Knoten im Cluster bereitstellen. Aus diesem Grund lassen sich Anwendungen in einem Kubernetes-Cluster immer hochverfügbar und unabhängig von Knoten bereitstellen.

Wie sich Anwendungen in Kubernetes bereitstellen lassen, zeigen die Entwickler in weiteren Tutorials. Auf diesem Weg lassen sich zum Beispiel auch MySQL-Datenbanken in Containern bereitstellen.

Anwendungen erstellen

Eine einfache Möglichkeit, um Container zu erstellen, bietet das Befehlszeilentool „kubectl“.
Eine einfache Möglichkeit, um Container zu erstellen, bietet das Befehlszeilentool „kubectl“. (Bild: Joos / Kubernetes)

Container-Anwendungen lassen sich zum Beispiel mit „kubectl“ erstellen. Beim Erstellen einer Anwendung wird das Container-Image festgelegt, in dem die App gestartet werden soll. Außerdem kann über das Deployment auch die Anzahl der Instanzen festgelegt werden, mit denen die Anwendung gestartet werden soll. Die entsprechenden Einstellungen lassen sich nach der Erstellung einer App aber jederzeit wieder ändern.

Anwendungen werden mit dem Befehl „kubectl run“ gestartet. Wenn das Deployment erstellt wurde, kann es mit „kubectl get deployments“ angezeigt werden.

Pods und die darin positionierten Container werden in einem isolierten Netzwerk betrieben. Zunächst sind alle Pods und deren Container für die anderen Pods auf dem Knoten und im Cluster verfügbar. Eine Kommunikation mit dem externen Netzwerk ist zunächst nicht möglich.

Pods und Container

Durch das Erstellen einer Anwendung mit ihren verschiedenen Instanzen und der Verwendung eines Container-Images wird in Kubernetes ein Pod erzeugt. Ein Pod stellt eine Sammlung mehrerer Container dar. Hier kann auf verschiedene Container-Systeme gesetzt werden, zum Beispiel Docker oder rkt.

Zusätzlich enthält ein Pod die Informationen zu den gemeinsamen Volumes, den Netzwerkverbindungen und den verwendeten Container-Images. Bei jedem Deployment wird ein Pod mit dazugehörigen Containern und Ressourcen erstellt. Die Ressourcen werden zwischen den Pods geteilt. Auch die gemeinsamen Volumes im Pod lassen sich von allen Containern und den dazugehörigen Apps nutzen.

Pods, Container und Cluster-Knoten

Pods werden vom Master-Knoten auf einen Worker-Knoten im Cluster positioniert. Fällt ein Knoten aus, erkennt das der Master und verschiebt den entsprechenden Pod auf einen anderen Knoten. Ein Knoten (Node) kann natürlich mehrere Pods bereitstellen. Auf jedem Knoten läuft außerdem der Kubectl-Prozess, der für die Kommunikation zwischen Nodes und Master verantwortlich ist.

Auf jedem Knoten im Kubernetes-Cluster läuft eine eigene Container-Runtime. Dabei kann es sich um Docker, rkt oder ein anderes Container-System handeln. Die Runtime ist schlussendlich für den Betrieb der Container und der dazugehörigen Apps verantwortlich.

Mit kubectl lassen sich die Informationen zu den Pods und Containern auf einem Host anzeigen.
Mit kubectl lassen sich die Informationen zu den Pods und Containern auf einem Host anzeigen. (Bild: Joos / Kubernetes)

Um die Anwendungen und Pods auf einem Knoten zu verwalten, wird ebenfalls „kubectl“ verwendet. Hier sind verschiedene, einfache Befehle verfügbar, um alle notwendigen Daten und Konfigurationen zu verwalten.

Wichtige Befehle sind zum Beispiel:

kubectl get – Zeigt die einzelnen Ressourcen an.

kubectl describe – Zeigt Informationen zu den Ressourcen.

kubectl logs – Zeigt die Protokolle einzelner Container in den Pods an.

kubectl exec – Führt Befehle in einem Container aus, der wiederum in einem Pod auf einem Knoten positioniert ist.

Kommunikation von Pods in die Außenwelt

Kubernetes bietet Services, mit denen sich Apps auch im Netzwerk bereitstellen lassen – in einem Cluster auch hochverfügbar.
Kubernetes bietet Services, mit denen sich Apps auch im Netzwerk bereitstellen lassen – in einem Cluster auch hochverfügbar. (Bild: Joos / Kubernetes)

Innerhalb des Clusters und einzelner Knoten wird die Netzwerkkommunikation zwischen den Pods automatisch hergestellt. Damit Pods und Container sowie die darauf positionierten Anwendungen mit dem Rest des Netzwerks kommunizieren können, ist ein Service notwendig. Über einen Service werden Pods und die darin enthaltenen Ressourcen mit dem Netzwerk verbunden, sodass die einzelnen Apps in den Containern überhaupt erst genutzt werden können.

Über Services lässt sich das Netzwerkverhalten von Anwendungen sehr gut steuern. Hier kann zum Beispiel auch ein Lastenausgleich festgelegt werden; oder man bestimmt, dass eine Anwendung in einem Container nur für bestimmte Knoten innerhalb des Clusters verfügbar ist. Auch NAT kann für Container und die darin positionierten Anwendungen genutzt werden.

Ein Service kann mehrere Pods – und somit alle enthaltenen Container und Apps – miteinander sowie mit der Außenwelt verbinden. Mit Services können Pods also netzwerktechnisch miteinander gruppiert werden. Dadurch lassen sich zum Beispiel auch Backend und Frontend für Applikationen in Containern darstellen und über Pods entsprechend steuern.

*Thomas Joos ist freier Autor und schreibt IT-Fachbücher sowie -artikel. Auf DataCenter-Insider bestückt er seinen eigenen Blog „Toms Admin-Blog“ mit Tipps und Tricks für Administratoren.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45103812 / Anwendungen)