Funktionsweise von Kubernetes-Bereitstellungen
Die App für das Drohnentracking besteht aus mehreren Komponenten, die separat voneinander bereitgestellt werden. Es ist Ihre Aufgabe, Bereitstellungen für diese Komponenten im Cluster zu konfigurieren. Hier sehen Sie einige der Optionen, die Ihnen für die Bereitstellung dieser Komponenten zur Verfügung stehen.
Bereitstellungsoptionen für Pods
Mit kubectl gibt es mehrere Optionen für die Verwaltung der Bereitstellung von Pods in einem Kubernetes-Cluster. Folgende Optionen stehen zur Verfügung:
- Podvorlagen
- Replikationscontroller
- Replikatgruppen
- Bereitstellungen
Sie können jede der folgenden vier Kubernetes-Objekttypdefinitionen verwenden, um einen oder mehrere Pods bereitzustellen. Diese Dateien verwenden YAML, um den beabsichtigten Zustand der Pods zu beschreiben, die bereitgestellt werden sollen.
Was ist eine Podvorlage?
Mit einer Podvorlage können Sie die Konfiguration des Pods definieren, den Sie bereitstellen möchten. Die Vorlage enthält Informationen wie den Namen des Containerimages und welche Containerregistrierung zum Abrufen der Images verwendet werden soll. Die Vorlage kann auch Informationen zur Laufzeitkonfiguration enthalten, zum Beispiel, welche Ports verwendet werden sollen. Vorlagen werden auf die gleiche Weise wie beim Erstellen von Docker-Dateien mit YAML definiert.
Sie können Vorlagen verwenden, um Pods manuell bereitzustellen. Beachten Sie jedoch, dass ein manuell bereitgestellter Pod nicht neu gestartet wird, wenn er ausfällt, gelöscht oder beendet wird. Zum Verwalten des Lebenszyklus eines Pods müssen Sie ein höheres Kubernetes-Objekt erstellen.
Was ist ein Replikationscontroller?
Ein Replikationscontroller verwendet Podvorlagen und legt eine bestimmte Anzahl von Pods fest, die ausgeführt werden müssen. Der Controller ermöglicht das Ausführen mehrerer Instanzen desselben Pods und stellt sicher, dass stets Pods auf mindestens einem Knoten im Cluster ausgeführt werden. Der Controller ersetzt ausgeführte Pods auf diese Weise durch neue Pods, wenn Pods ausfallen, gelöscht oder beendet werden.
Nehmen wir beispielsweise an, dass Sie die Front-End-Website für das Drohnentracking bereitstellen und Benutzer dann auf die Website zugreifen. Wenn alle Pods ausfallen, können Benutzer nicht mehr auf die Website zugreifen, solange Sie keine neuen Pods starten. Mithilfe eines Replikationscontrollers können Sie sicherstellen, dass Ihre Website immer verfügbar ist.
Was ist eine Replikatgruppe?
Replikatgruppen ersetzen den Replikationscontroller als bevorzugte Methode zum Bereitstellen von Replikaten. Ein Replikatsatz umfasst dieselbe Funktionalität wie ein Replikationscontroller, verfügt aber über eine zusätzliche Konfigurationsoption, um einen Selektorwert einzuschließen.
Mit einem Selektor kann die Replikatgruppe alle ihr untergeordneten Pods identifizieren. Mit diesem Feature können Sie Pods verwalten, die denselben Wert wie der Selektorwert aufweisen, aber nicht in der Replikatgruppe erstellt wurden.
Was ist eine Bereitstellung?
Eine Bereitstellung erstellt ein Verwaltungsobjekt auf einer Ebene über der Replikatgruppe und ermöglicht Ihnen die Bereitstellung und Verwaltung von Updates für Pods in einem Cluster.
Angenommen, Sie haben fünf Instanzen der App in Ihrem Cluster bereitgestellt. Es gibt fünf Pods, auf denen Version 1.0.0 Ihrer App ausgeführt wird.
Wenn Sie die App manuell aktualisieren möchten, können Sie alle Pods entfernen und dann neue Pods starten, auf denen Version 2.0.0 Ihrer App ausgeführt wird. Mit dieser Strategie erlebt Ihre App Ausfallzeiten.
Stattdessen sollten Sie ein rollierendes Update ausführen. Dabei werden die Pods mit der neuen Version Ihrer App gestartet, bevor die Pods mit der älteren Version entfernt werden. Bei rollierenden Updates werden die einzelnen Pods nacheinander gestartet, anstatt alle älteren Pods gleichzeitig zu beenden. Bereitstellungen berücksichtigen die Anzahl der Replikate, die im Abschnitt zu den Replikatgruppen konfiguriert sind. Die in der Replikatgruppe angegebene Anzahl von Pods wird beibehalten, während die Bereitstellung alte Pods durch neue Pods ersetzt.
Standardmäßig werden Pods in Bereitstellungen mithilfe einer rollierenden Strategie aktualisiert. Alternativ können Sie eine Neuerstellungsstrategie verwenden. Diese Strategie beendet Pods, bevor neue Pods gestartet werden.
Bereitstellungen bieten Ihnen auch die Möglichkeit eines Rollbacks, die Sie mit kubectl ausführen können.
Bereitstellungen verwenden YAML-basierte Definitionsdateien und vereinfachen die Verwaltung. Beachten Sie, dass Sie bei Bereitstellungen Änderungen an Ihrem Cluster vornehmen können. Beispielsweise können Sie neue Versionen einer App bereitstellen, Bezeichnungen aktualisieren oder andere Replikate Ihrer Pods ausführen.
kubectl bietet eine praktische Syntax zum automatischen Erstellen einer Bereitstellung, wenn Sie den Befehl kubectl run zum Bereitstellen eines Pods verwenden. Mit diesem Befehl wird eine Bereitstellung mit der erforderlichen Replikatgruppe und den entsprechenden Pods erstellt. Der Befehl erstellt jedoch keine Definitionsdatei. Eine bewährte Methode besteht darin, alle Bereitstellungen mit Bereitstellungsdefinitionsdateien zu verwalten und Änderungen mithilfe eines Versionskontrollsystems nachzuverfolgen.
Überlegungen zur Bereitstellung
Kubernetes stellt bestimmte Anforderungen an die Netzwerk- und Speicherkonfiguration für einen Cluster. Wie Sie diese beiden Faktoren konfigurieren, wirkt sich darauf aus, wie Sie Ihre Apps im Clusternetzwerk verfügbar machen und Daten speichern können.
Beispielsweise gelten für jeden der Dienste in der App für das Drohnentracking bestimmte Anforderungen an den Benutzerzugriff, den prozessübergreifenden Netzwerkzugriff und die Datenspeicherung. Als Nächstes werden die Aspekte eines Kubernetes-Clusters und ihre Auswirkungen auf die Bereitstellung von Apps erläutert.
Kubernetes-Netzwerke
Angenommen, Sie verfügen über einen Cluster mit einer Steuerungsebene und zwei Knoten. Wenn Sie Knoten zu Kubernetes hinzufügen, wird jedem Knoten automatisch eine IP-Adresse aus einem internen privaten Netzwerkbereich zugewiesen. Der lokale Netzwerkbereich kann beispielsweise 192.168.1.0/24 sein.
Jedem Pod, den Sie bereitstellen, wird eine IP-Adresse aus einem IP-Adresspool zugewiesen. Angenommen, Ihre Konfiguration verwendet beispielsweise den Netzwerkbereich „10.32.0.0/12“, wie in der folgenden Abbildung gezeigt.
Standardmäßig können Pods und Knoten nicht miteinander kommunizieren, wenn sie unterschiedliche IP-Adressbereiche verwenden.
Bedenken Sie zudem, dass Pods kurzlebig sind. Die IP-Adresse des Pods ist temporär und kann nicht dazu verwendet werden, eine neue Verbindung zu einem neu erstellten Pod herzustellen. Diese Konfiguration wirkt sich darauf aus, wie Ihre App mit ihren internen Komponenten kommuniziert und wie Sie und Dienste extern mit der App interagieren.
Kubernetes vereinfacht die Kommunikation, indem erwartet wird, dass Netzwerke so konfiguriert werden, dass Folgendes möglich ist:
- Pods können knotenübergreifend ohne Netzwerkadressenübersetzung (Network Address Translation, NAT) miteinander kommunizieren.
- Knoten und Pods können ohne NAT miteinander kommunizieren.
- Agents auf einem Knoten können mit allen Knoten und Pods kommunizieren.
Kubernetes bietet mehrere Netzwerkoptionen, die Sie installieren können, um das Netzwerk zu konfigurieren. Dazu zählen beispielsweise Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T und Weave Net.
Cloudanbieter stellen auch eigene Netzwerklösungen bereit. Beispielsweise unterstützt Azure Kubernetes Service die Azure Virtual Network-Schnittstelle für Containernetzwerke, Kubenet, Flannel, Cilium und Antrea.
Kubernetes-Dienste
Ein Kubernetes-Dienst ist ein Kubernetes-Objekt, das ein stabiles Netzwerk für Pods bereitstellt. Kubernetes-Dienste ermöglichen die Kommunikation zwischen Knoten, Pods und den Benutzern Ihrer App, sowohl innerhalb als auch außerhalb des Clusters.
Kubernetes weist Diensten bei der Erstellung, genau wie bei Knoten und Pods, eine IP-Adresse zu. Diese Adressen werden aus dem IP-Adressbereich eines Dienstclusters zugewiesen, z. B. 10.96.0.0/12. Diensten wird anhand des Dienstnamens zudem auch ein DNS-Name sowie ein IP-Port zugewiesen.
In der App für das Drohnentracking läuft die Netzwerkkommunikation folgendermaßen ab:
Die Website und die RESTful-API sind für Benutzer außerhalb des Clusters zugänglich.
Der In-Memory-Cachedienst und der Dienst für die Nachrichtenwarteschlange sind für die Front-End- und RESTful-API zugänglich, jedoch nicht für externe Benutzer.
Die Nachrichtenwarteschlange benötigt Zugriff auf den Datenverarbeitungsdienst, jedoch nicht auf externe Benutzer.
Die NoSQL-Datenbank ist für den In-Memory-Cachedienst und den Datenverarbeitungsdienst zugänglich, aber nicht für externe Benutzer.
Zur Unterstützung dieser Szenarios können Sie drei verschiedene Diensttypen konfigurieren, um die Komponenten Ihrer App verfügbar zu machen.
| Service | Beschreibung |
|---|---|
| ClusterIP | Die einem Dienst zugewiesene IP-Adresse, die den Dienst für verschiedene Dienste im Cluster verfügbar macht, beispielsweise für die Kommunikation zwischen den Front-End- und Back-End-Komponenten der App |
| NodePort | Der Knotenport, zwischen 30000 und 32767, den die Kubernetes-Steuerungsebene dem Dienst zuweist, z. B. 192.169.1.11 auf clusters01. Anschließend konfigurieren Sie den Dienst mit einem Zielport auf dem Pod, den Sie verfügbar machen möchten, zum Beispiel Port 80 auf dem Pod, auf dem eines der Front-Ends ausgeführt wird. Sie können jetzt über eine Knoten-IP und eine Portadresse auf das Front-End zugreifen. |
| LoadBalancer | Hierbei handelt es sich um den Lastenausgleich, der die Verteilung der Auslastung auf die Knoten, auf denen Ihre App ausgeführt wird, und das Bereitstellen von Pods für öffentlichen Netzwerkzugriff ermöglicht. In der Regel konfigurieren Sie einen Lastenausgleich, wenn Sie Cloudanbieter verwenden. In diesem Fall wird der Datenverkehr vom externen Lastenausgleich an die Pods geleitet, auf denen Ihre App ausgeführt wird. |
In der App für das Drohnentracking können Sie die Trackingwebsite und die RESTful-API mithilfe eines Lastenausgleichs und den Datenverarbeitungsdienst mit einem ClusterIP-Dienst verfügbar machen.
Gruppieren von Pods
Das Verwalten von Pods nach IP-Adresse ist nicht praxistauglich. Die IP-Adressen von Pods ändern sich, wenn Controller die Pods neu erstellen. Außerdem kann eine beliebige Anzahl von Pods ausgeführt werden.
Ein Dienstobjekt ermöglicht Ihnen das Ansprechen und Verwalten bestimmter Pods in Ihrem Cluster mithilfe von Selektorbezeichnungen. Selektorbezeichnungen werden in einer Dienstdefinition so festgelegt, dass diese mit der Podbezeichnung in der Definitionsdatei übereinstimmt.
Angenommen, es werden viele Pods ausgeführt. Nur wenige dieser Pods sind Front-End-Pods, und Sie möchten einen LoadBalancer-Dienst konfigurieren, der nur die Front-End-Pods berücksichtigt. Mit diesem Dienst können Sie diese Pods verfügbar machen, indem Sie in der Definitionsdatei des Diensts auf die Podbezeichnung als Selektorwert verweisen. Der Dienst gruppiert nur die Pods, die der Bezeichnung entsprechen. Wenn ein Pod entfernt und neu erstellt wird, wird der neue Pod automatisch mithilfe der entsprechenden Bezeichnung zur Dienstgruppe hinzugefügt.
Kubernetes-Speicher
Kubernetes verwendet das gleiche Speichervolumekonzept, das Sie von Docker kennen. Docker-Volumes weisen ein geringeres Maß an Verwaltung auf als Kubernetes-Volumes, da die Lebensdauer von Docker-Volumes nicht verwaltet wird. Die Lebensdauer eines Kubernetes-Volumes ist eine explizite Lebensdauer, die der Lebensdauer des Pods entspricht. Dieser Lebensdauerabgleich hat zur Folge, dass ein Volume die Container überdauert, die im Pod ausgeführt werden. Wenn der Pod jedoch entfernt wird, wird auch das Volume entfernt.
Kubernetes bietet mithilfe von PersistentVolumes Optionen zum Bereitstellen von persistentem Speicher. Sie haben auch die Möglichkeit, mithilfe von PersistentVolumeClaims eine bestimmte Speichermenge für Pods anzufordern.
Sie sollten beide Optionen berücksichtigen, wenn Sie App-Komponenten bereitstellen, für die persistenter Speicher erforderlich ist (z. B. Nachrichtenwarteschlangen und Datenbanken).
Überlegungen zur Cloudintegration
Kubernetes gibt nicht vor, welchen Technologiestapel Sie in Ihrer cloudnativen App verwenden müssen. In einer Cloudumgebung wie Azure können Sie mehrere Dienste außerhalb des Kubernetes-Clusters verwenden.
Wie Sie bereits zuvor gelernt haben, stellt Kubernetes keinen der folgenden Dienste bereit:
- Middleware
- Datenverarbeitungsframeworks
- Datenbanken
- Caches
- Clusterspeichersysteme
In der Lösung für das Drohnentracking gibt es drei Dienste, die Middlewarefunktionen bereitstellen: eine NoSQL-Datenbank, einen In-Memory-Cachedienst und eine Nachrichtenwarteschlange. Sie könnten MongoDB Atlas für die NoSQL-Lösung, Redis zum Verwalten des In-Memory-Caches und je nach den Anforderungen der Nachrichtenwarteschlange RabbitMQ oder Kafka verwenden.
Wenn Sie eine Cloudumgebung wie Azure verwenden, hat es sich bewährt, Dienste außerhalb des Kubernetes-Clusters zu verwenden. Diese Methode kann die Konfiguration und Verwaltung des Clusters vereinfachen. Beispielsweise können Sie Azure Cache for Redis für die In-Memory-Cachedienste verwenden, Azure Service Bus-Messaging für die Nachrichtenwarteschlange und Azure Cosmos DB für die NoSQL-Datenbank.