Verwalten eines Helm-Releases

Abgeschlossen

Verwenden von Funktionen in einer Helm-Vorlage

Mit der Vorlagensprache Helm werden Funktionen definiert, die zum Transformieren von Werten in der Datei values.yaml verwendet werden. Die Syntax einer Funktion beruht auf der Struktur {{ functionName arg1 arg2 ... }}. Sehen wir uns die Funktion quote als Beispiel für diese Syntax in der Praxis an.

Bei der Funktion quote wird ein Wert in Anführungszeichen gesetzt, um anzugeben, dass ein string verwendet wird. Angenommen, Sie definieren die folgende Datei values.yaml:

apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
  enabled: true

Sie möchten den Wert ingress.enabled als booleschen Wert verwenden, wenn Sie festlegen, ob ein Eingangsmanifest verwendet werden soll. Wenn Sie den Wert enabled als booleschen Wert verwenden möchten, verweisen Sie mithilfe von {{ .Values.ingress.enabled }} auf den Wert.

Später beschließen Sie, das Feld als Zeichenfolge in der Datei templates/Notes.txt anzuzeigen. Da YAML-Typumwandlungsregeln zu schwer zu findenden Fehlern in Vorlagen führen können, entscheiden Sie sich dafür, den Empfehlungen zu folgen und Zeichenfolgen explizit in Ihre Vorlagen aufzunehmen. So ist beispielsweise enabled: false nicht dasselbe wie enabled: "false".

Wenn Sie den Wert einer Zeichenfolge anzeigen möchten, verwenden Sie {{ quote .Values.ingress.enabled }}, um auf den booleschen Wert als Zeichenfolge zu verweisen.

Verwenden von Pipelines in einer Helm-Vorlage

Pipelines werden verwendet, wenn mehrere Funktionen auf einen Wert reagieren müssen. Mithilfe einer Pipeline können Sie einen Wert oder das Ergebnis einer Funktion an eine andere Funktion senden. So können Sie beispielsweise die obige Funktion quote als {{ .Values.ingress.enabled | quote }} erneut generieren. Mit | wird angegeben, dass der Wert an die Funktion quotegesendet wird.

Hier sehen Sie ein weiteres Beispiel. Angenommen, Sie möchten einen Wert in Großbuchstaben umwandeln und in Anführungszeichen einschließen. Sie können die Anweisung als {{ .Values.ingress.enabled | upper | quote }} schreiben. Wie Sie sehen, wird der Wert von der Funktion upper und anschließend von der Funktion quote verarbeitet.

Die Vorlagensprache enthält mehr als 60 Funktionen, mit denen Sie Werte und Objekte in Vorlagen verfügbar machen, suchen und transformieren können.

Verwenden der bedingten Flusssteuerung in einer Helm-Vorlage

Mit der bedingten Flusssteuerung können Sie festlegen, welche Struktur oder Daten in der generierten Manifestdatei verwendet werden sollen. So können Sie beispielsweise je nach Bereitstellungsziel unterschiedliche Werte verwenden oder festlegen, ob eine Manifestdatei generiert wird.

Bei dem Block if / else handelt es sich um eine Ablaufsteuerungsstruktur dieser Art, die dem folgenden Layout entspricht:

{{ if | pipeline | }}
  # Do something
{{ else if | other pipeline | }}
  # Do something else
{{ else }}
  # Default case
{{ end }}

Angenommen, Sie möchten, dass die Eingangsmanifestdatei für ein Chart nur in bestimmten Fällen erstellt wird. Im folgenden Beispiel wird gezeigt, wie Sie dies mit einer if-Anweisung erreichen:

{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{ end }}

Zur Erinnerung: Zum Auffüllen der Vorlage mit Metadaten können Platzhalter verwendet werden. Vorlagedateien werden mithilfe der Vorlagensprache nacheinander von oben nach unten analysiert und ausgewertet. Im Beispiel oben wird der Inhalt der Manifestdatei durch die Vorlagen-Engine nur dann generiert, wenn der Wert für .Values.ingress.enabled auf true festgelegt ist.

Wenn die Anweisung durch die Vorlagen-Engine verarbeitet wird, wird der innerhalb der {{ }}-Syntax deklarierte Inhalt entfernt, und es bleiben Leerstellen übrig. Mit dieser Syntax wird dafür gesorgt, dass von der Vorlagen-Engine für die if-Anweisungszeile eine neue Zeile eingefügt wird. Wenn Sie den Inhalt der Datei oben unverändert übernehmen, entstehen in Ihrer YAML-Datei leere Zeilen, und die Eingangsmanifestdatei wird generiert.

Mit YAML erhalten die Leerzeichen einen Bedeutung. Daher sind Tabstopps, Leerzeichen und Zeilenvorschubzeichen wichtig. Um das Problem mit unerwünschten Leerzeichen zu beheben, können Sie die Datei wie folgt erneut generieren:

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{- end }}

Wie Sie sehen, wird das Zeichen - als Teil der Anfangssequenz {{- und der Endsequenz -}} der Anweisung verwendet. Das Zeichen - ist die Anweisung für den Parser, Leerzeichen zu entfernen. Mit {{- werden Leerzeichen sowie Zeilenvorschubzeichen am Zeilenanfang und mit -}} am Zeilenende entfernt.

Durchlaufen einer Auflistung von Werten in einer Helm-Vorlage

Mit YAML können Sie Auflistungen von Elementen definieren und einzelne Elemente als Werte in Ihren Vorlagen verwenden. Auf Elemente in einer Auflistung kann mithilfe eines Indexers zugegriffen werden. Die Vorlagensprache Helm unterstützt jedoch das Durchlaufen einer Auflistung von Werten mithilfe des Operators range.

Angenommen, Sie definieren in Ihrer values.yaml-Datei eine Liste von Werten, um zusätzliche Eingangshosts anzugeben. Dies ist ein Beispiel für die Werte:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

Der Operator „range“ wird verwendet, um zuzulassen, dass die Vorlagen-Engine die .Values.ingress.extraHosts durchläuft. Der folgende Codeschnipsel stellt ein verkürztes Beispiel für die Verwendung des Operators range dar.

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  ...
spec:
  rules:
    ...
    {{- range .Values.ingress.extraHosts }}
    - host: {{ .name }}
      http:
        paths:
          - path: {{ .path }}
            ...
    {{- end }}
  ...
{{- end }}

Festlegen des Wertebereichs in einer Helm-Vorlage

Wenn Werte mehrere Ebenen tief definiert sind, wird die Syntax sehr lang, und es wird mühsam, diese Werte in eine Vorlage einzufügen. Mit der Aktion with können Sie den Geltungsbereich von Variablen in einer Vorlage begrenzen.

Zur Erinnerung: . in einer Helm-Vorlage verweist auf den aktuellen Geltungsbereich. So wird die Vorlagen-Engine beispielsweise mit .Values angewiesen, im aktuellen Geltungsbereich nach dem „Values“-Objekt zu suchen. Angenommen, Sie verwenden die bereits zuvor verwendete Datei values.yaml, um eine Manifestdatei für die Konfigurationszuordnung zu erstellen:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

Statt mithilfe von {{ .Values.ingress.extraHosts.path }} auf den Pfad der einzelnen Elemente zuzugreifen, können Sie die Aktion with verwenden. Der folgende Codeschnipsel stellt ein Beispiel für die Verwendung des Operators range zum Generieren einer Manifestdatei für die Konfigurationszuordnung dar:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  {{ end }}

Mit {{- with .Values.ingress.extraHosts }} wird der Wertebereich auf das .Values.ingress.extraHosts-Array begrenzt.

Mit der Aktion with wird der Geltungsbereich eingeschränkt. Über den übergeordneten Geltungsbereich kann nicht auf andere Objekte zugegriffen werden. Angenommen, Sie möchten auch auf {{ .Release.Name }} des Charts im with-Codeblock zugreifen. Für den Zugriff auf übergeordnete Objekte müssen Sie den Stammbereich angeben, indem Sie das Zeichen $ verwenden oder den Code erneut generieren. Anhand des aktualisierten Codes können Sie erkennen, wie übergeordnete Objekte mit dem $-Zeichen einbezogen werden:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  release: {{ $.Release.Name}}
  {{ end }}

Hinweis

In der Vorlagensprache Helm sind verschiedene Konstrukte zur Ablaufsteuerung verfügbar. Weitere Informationen finden Sie in der Lerneinheit mit der Zusammenfassung dieses Moduls im Abschnitt mit Links zur Dokumentation zu Helm.

Definieren von Chartabhängigkeiten in Helm

Ein Chart ermöglicht die Deklaration von Abhängigkeiten zur Unterstützung der Hauptanwendung und bildet einen Teil des installierten Releases.

A diagram shows how Helm deploys all subcharts as dependencies of the main chart to a Kubernetes cluster.

Sie können entweder mit dem Befehl helm create ein Subchart erstellen und den Speicherort des neuen Charts im Ordner /charts angeben oder den Befehl helm dependency verwenden. Denken Sie daran, dass der Ordner /charts Subcharts enthalten kann, die als Teil des Releases des Hauptcharts bereitgestellt werden.

Mit dem Befehl helm dependency können Sie über ein Helm-Repository eingefügte Abhängigkeiten verwalten. Für den Befehl werden Metadaten verwendet, die im Abschnitt dependencies der Wertedatei Ihres Charts definiert sind. Sie geben den Namen, die Versionsnummer und das Repository an, über das das Subchart installiert werden soll. Im Folgenden sehen Sie einen Auszug aus einer Datei values.yaml, in der ein MongoDB-Diagramm als Abhängigkeit aufgeführt wird:

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
...
dependencies:
  - name: mongodb
    version: 10.27.2
    repository: https://marketplace.azurecr.io/helm/v1/repo

Führen Sie nach dem Definieren der Metadaten für die Abhängigkeit den Befehl helm dependency build aus, um das gepackte tar-Chart abzurufen. Mit dem Befehl „build“ wird das Chart in den Ordner charts/ heruntergeladen.

helm dependency build ./app-chart

Subcharts werden getrennt vom Hauptchart verwaltet und müssen möglicherweise aktualisiert werden, wenn neue Releases verfügbar werden. Der Befehl zum Aktualisieren von Subcharts lautet helm dependency update. Mit diesem Befehl werden neue Versionen des Subcharts abgerufen und gleichzeitig veraltete Pakete gelöscht.

helm dependency update ./app-chart

Beachten Sie, dass eine Diagrammabhängigkeit nicht auf andere Anwendungen beschränkt ist. So können Sie beispielsweise eine Vorlagenlogik in Ihren Diagrammen wiederverwenden und eine Abhängigkeit speziell zum Verwalten dieser Logik als Diagrammabhängigkeit erstellen. Ein Beispiel für diese Strategie finden Sie in der nächsten Übung.

Aktualisieren eines Helm-Releases

Mit Helm können vorhandene Releases als Delta aller Änderungen am Chart und den entsprechenden Abhängigkeiten aktualisiert werden.

A diagram shows how the Helm upgrade command creates a delta of all changed items in a Helm chart to upgrade a release and create a new release revision on a Kubernetes cluster.

Angenommen, das Entwicklungsteam des Beispiels webapp in dieser Lerneinheit nimmt Codeänderungen vor, die sich nur auf die Funktionalität der Website auswirken. Das Team aktualisiert die Chart.yaml wie folgt, um die neue Version der Anwendung widerzuspiegeln:

  • Es aktualisiert das Containerimage der Web-App und markiert das Image als webapp: linux-v2, wenn das Image per Push an die Containerregistrierung übertragen wird.
  • Es aktualisiert den dockerTag-Wert in der Wertedatei des Charts auf linux-v2 und den Chartversionswert auf 0.2.0.

Das folgende Beispiel zeigt die aktualisierte Datei values.yaml:

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes

type: application

version: 0.2.0
appVersion: 1.0.0

registry: "my-acr-registry.azurecr.io"
dockerTag: "linux-v2"
pullPolicy: "Always"

Statt das aktuelle Release zu deinstallieren, verwenden Sie den Befehl helm upgrade, um das vorhandene Helm-Release zu aktualisieren.

helm upgrade my-app ./app-chart

Zur Erinnerung: Helm generiert ein Delta der Änderungen, die beim Aktualisieren eines Releases am Helm-Chart vorgenommenen werden. Daher werden bei einem Helm-Upgrade nur die im Delta angegebenen Komponenten aktualisiert. Im Beispiel wird nur die Website erneut bereitgestellt.

Nach dem Aktualisieren können Sie den Bereitstellungsverlauf des Releases mit dem Befehl helm history und dem Releasenamen aufrufen.

helm history my-app

Mit dem Befehl „history“ werden verschiedene Felder zurückgegeben, mit denen das Release beschrieben wird. Dies ist in der folgenden Beispielausgabe dargestellt:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        deployed        aspnet-core-1.3.18      3.1.19          Install complete

Beachten Sie das Feld revision im Ergebnis. Mit Helm werden die Releaseinformationen aller für ein Helm-Chart erstellten Releases nachverfolgt. Wenn Sie eine neue Version eines Helm-Charts installieren, wird die Revisionsanzahl um eins erhöht und die Informationen des neuen Releases werden an diese Revision angepasst.

Im folgenden Beispiel wird der Befehl „history“ ausgeführt und anschließend eine neue Version der Web-App installiert:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

Zurücksetzen eines Helm-Releases

Mit Helm kann ein vorhandenes Helm-Release auf ein zuvor installiertes Release zurückgesetzt werden. Zur Erinnerung: Mit Helm werden Releaseinformationen aller Releases eines Helm-Diagramms nachverfolgt.

Zum Zurücksetzen einer bestimmten Helm-Releaserevision wird der Befehl helm rollback verwendet. Für diesen Befehl werden zwei Parameter verwendet. Mit dem ersten Parameter wird der Name des Releases, mit dem zweiten die Revisionsnummer des Releases angegeben.

helm rollback my-app 2

Mit dem Befehl helm rollback wird die Releaseversion der Apps auf die angegebene Revision zurückgesetzt und der Releaseverlauf der Anwendung aktualisiert. Wenn anschließend der Befehl helm history ausgeführt wird, wird die letzte aktive Revisionsnummer als letzter Releaseeintrag angezeigt.

Beispiel: Angenommen, das Entwicklungsteam des Beispiels webapp in dieser Lerneinheit entdeckt einen Fehler in der Webanwendung für das Drohnentracking und muss die Anwendung auf ein früheres Release zurücksetzen. Statt das aktuelle Release zu deinstallieren und eine frühere Version zu installieren, führt das Team ein Rollback auf das funktionierende Release aus.

helm rollback my-app 1

Nach dem Rollback können Sie den Bereitstellungsverlauf mit dem Befehl helm history aufrufen.

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        superseded      aspnet-core-1.3.18      3.1.19          Rolled back to 1
3               Mon Oct 11 17:38:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

Im Feld „description“ wird die Revisionsnummer der Zurücksetzung angezeigt, damit Sie Änderungen leichter nachverfolgen können.

Überprüfen Sie Ihr Wissen

1.

Angenommen, Sie haben eine Softwarelösung mit zwei kritischen Komponenten: eine Webanwendung und einen Dienst, der Onlinebestellungen verarbeitet. Die beiden Komponenten sind Teil einer Pipeline für die Verarbeitung von Onlinebestellungen, jedoch nicht voneinander abhängig. Welche Strategie wäre für die Bereitstellung dieser beiden Anwendungen am besten geeignet, wenn Helm verwendet wird?

2.

Angenommen, Sie haben eine Softwarelösung mit einer Website als eine der kritischen Komponenten. Die Website ist die einzige Komponente, die von einem Cachedienst abhängt. Welche Strategie wäre für die Bereitstellung dieser beiden Anwendungen am besten geeignet, wenn Helm verwendet wird?