Was ist eine Kubernetes-Bereitstellung?

Kubernetes spart Zeit und minimiert Fehler durch Automatisierung der Arbeitsschritte und der sich wiederholenden manuellen Aufgaben, die mit der Bereitstellung, Skalierung und Aktualisierung von Anwendungen in der Produktion verbunden sind. Der Controller für die Kubernetes-Bereitstellung überwacht kontinuierlich den Systemzustand der Pods und Knoten. Dadurch kann er Änderungen in Echtzeit vornehmen und beispielsweise einen ausgefallenen Pod ersetzen oder ausgefallene Knoten umgehen, um die Kontinuität kritischer Anwendungen sicherzustellen.

Bereitstellungen automatisieren den Start von Pod-Instanzen und stellen sicher, dass sie wie definiert auf allen Knoten im Kubernetes-Cluster ausgeführt werden. Ein höherer Grad an Automatisierung führt zu schnelleren Bereitstellungen mit weniger Fehlern.

Kubernetes bietet verschiedene Bereitstellungsstrategien für verschiedenste Anforderungen an Anwendungsentwicklung und -bereitstellung. Sobald Sie den gewünschten Zustand der Anwendung definiert haben, beginnt der Bereitstellungs-Controller mit seiner Arbeit. Er kann Änderungen mit geregelter Geschwindigkeit vornehmen, um die Bereitstellung zu optimieren. 

Was ist eine Kubernetes-Bereitstellung mit Neuerstellung?

Mit der Strategie zur Neuerstellung werden derzeit ausgeführte Pods beendet und mit der neuen Version „neu erstellt“. Dieser Ansatz wird in der Regel in einer Entwicklungsumgebung verwendet, in der Anwenderaktivitäten kein Problem darstellen.

Da bei der Bereitstellung mit Neuerstellung die Pods und der Zustand der Anwendung vollständig aktualisiert werden, müssen Sie mit Ausfallzeiten rechnen, die durch das Herunterfahren der alten Bereitstellung und den Start der neuen Bereitstellungsinstanzen verursacht werden.

Was ist eine Kubernetes-Bereitstellung mit Rolling-Update?

Die Bereitstellung mit Rolling-Update ermöglicht eine geordnete, schrittweise Migration von einer Version einer Anwendung zu einer neueren Version. Ein neues ReplicaSet mit der neuen Version wird gestartet und die Replikate der alten Version werden systematisch beendet, während die Replikate der neuen Version gestartet werden. Letztendlich werden alle Pods der alten Version durch die neue Version ersetzt. 

Die Bereitstellung mit Rolling-Update ist vorteilhaft, da sie einen geordneten Übergang zwischen Versionen ermöglicht. Sie kann jedoch einige Zeit in Anspruch nehmen.

Was ist eine Kubernetes-Blue/Green-Bereitstellung?

Die Blue/Green-Strategie unterstützt einen schnellen Übergang von der alten zur neuen Version, sobald die neue Version in der Produktion getestet wurde. Dabei wird die neue „grüne“ Version zusammen mit der vorhandenen „blauen“ Version bereitgestellt. Sobald Sie davon überzeugt sind, dass die „grüne“ Version wie vorgesehen funktioniert, wird die Versionsbezeichnung im Auswahlfeld des Kubernetes-Service-Objekts, das den Lastausgleich durchführt, ersetzt. Durch diese Aktion wird der Datenverkehr sofort auf die neue Version umgestellt.

Die Blue/Green-Bereitstellungsoption von Kubernetes unterstützt ein schnelles Rollout, bei dem Probleme mit der Versionierung vermieden werden. Durch diese Strategie wird jedoch die Ressourcenauslastung verdoppelt, da beide Versionen bis zur Umstellung ausgeführt werden.

Was ist eine Kubernetes-Canary-Bereitstellung?

Bei einer Canary-Bereitstellung wird eine kleine Gruppe von Anwendern an die neue Version einer Anwendung umgeleitet, die auf einer kleineren Teilmenge von Pods ausgeführt wird. Der Zweck dieses Ansatzes ist es, die Funktionalität in einer Produktionsumgebung zu testen. Sobald Sie sich davon überzeugt haben, dass die Tests fehlerfrei verlaufen sind, werden die Replikate der neuen Version hochskaliert und die alte Version wird ordnungsgemäß ersetzt.

Canary-Bereitstellungen sind von Vorteil, wenn Sie neue Funktionen mit einer kleineren Gruppe von Anwendern testen möchten. Da Sie Canary-Bereitstellungen leicht zurücksetzen können, können Sie mit dieser Strategie ohne großes Risiko abschätzen, wie sich neuer Code auf den gesamten Systembetrieb auswirken wird.

Bereitstellungen sind der einfachste Weg, um die Ausführung von Anwendungen auf einem Kubernetes-Cluster zu verwalten und zu skalieren, und die offene API von Kubernetes vereinfacht die Integration in CI/CD-Pipelines. 

Hier sind einige gängige Anwendungsbeispiele für Bereitstellungen aufgeführt:

• Ausführen zustandsfreier Webserver wie des beliebten Open-Source-Servers Nginx. Die Bereitstellung kann die Instanziierung einer festen Anzahl von Pod-Replikaten anfordern und Kubernetes behält diese Anzahl von Pods während der Bereitstellung bei.
  
• Anwendungen, die persistenten Storage benötigen (etwa eine Datenbankinstanz), würden eine Bereitstellung vom Typ „StatefulSet“ verwenden und ein Persistent Volume mounten, um die Datenintegrität und Langlebigkeit sicherzustellen.
  
• Bei der Bereitstellung kann die Anzahl der Replikate im Cluster automatisch skaliert werden, wenn die Anzahl von Workloads zunimmt. Sie können beispielsweise eingehende Anforderungen automatisch zwischen den Replikaten ausgleichen, neue Replikate erstellen, wenn die Nachfrage steigt, und Replikate beenden, wenn die Nachfrage nachlässt.
  

Wie bei den meisten Kubernetes-Funktionen werden Bereitstellungen in YAML-Dateien (oder JSON-Dateien) beschrieben und dann mithilfe von „kubectl apply“ erstellt.

Die YAML-Datei für eine Nginx-Bereitstellung mit dem Namen „web-deployment“ mit vier Replikaten würde zum Beispiel wie folgt aussehen:

apiVersion: apps/v1;

kind: Deployment

metadata:

name: web-deployment

spec:

selector:

matchLabels:

app: nginx

replicas: 4

template:

metadata:

labels:

app: nginx

spec:

containers:

- name: nginx

image: nginx:1.17.0

ports:- containerPort: 80

In diesem Beispiel geben die Metadaten an, dass „web-deployment“ mit vier replizierten Pods erstellt wurde (Replikate: 4), und der Selektor gibt an, wie die Bereitstellung die Pods anhand der Bezeichnung (app: nginx) findet. Der Container (nginx) führt das Container-Image in Version 1.17.0 aus und bei der Bereitstellung wird Port 80 für die Pods geöffnet.

Sie können auch Umgebungsvariablen für die Container definieren. Verwenden Sie dazu das Feld „env“ oder „envFrom“ in der Konfigurationsdatei. Nach dem Definieren der Bereitstellung wird sie auf der Grundlage der YAML-Datei wie folgt erstellt: kubectl apply -f https://[location/web-deployment.yaml]

Was ist der Unterschied zwischen JSON und YAML in Kubernetes?

Sowohl YAML (YAML Ain't Markup Language) als auch JSON (JavaScript Object Notation) können zur Definition von Kubernetes-Ressourcen verwendet werden. Viele Anwender bevorzugen YAML aufgrund der besseren Lesbarkeit. Da YAML jedoch auf JSON aufbaut, ist jede gültige JSON-Datei auch eine gültige YAML-Datei.

Sie können eine Kubernetes-Bereitstellung aktualisieren, indem Sie die Pod-Vorlagenspezifikation innerhalb der Bereitstellung ändern. Dadurch wird automatisch eine Aktualisierung ausgelöst.

Wenn Sie die Pod-Vorlage ändern, werden ausgeführte Pods daran gehindert, Anforderungen anzunehmen. Dies ermöglicht das Zurückskalieren der Pods, bis alle Pods beendet werden können. Sobald sie beendet wurden, wird die aktualisierte Pod-Vorlage zur Erstellung neuer Pods verwendet.

Wenn eine Bereitstellung als instabil eingestuft wird oder ein Fehler bei der Bereitstellung aufgetreten ist, können Sie mit kubectl ein Rollback und eine Aktualisierung durchführen. Um zur vorherigen Version zurückzukehren, verwenden Sie den folgenden Befehl:

Kubectl rollout undo [Bereitstellungsname]. Durch Hinzufügen des Arguments „to-revision=“ können Sie die gewünschte Zielversion für das Rollback der Bereitstellung angeben.