Helm Chart Tutorial: Eine Schritt-für-Schritt-Anleitung mit Beispielen

Installieren und Konfigurieren von Helm

Wir gehen durch die Installation von Helm CLI auf Windows, Mac und Linux.

Die neueste Version von Helm ist derzeit 3.17.2. Für die Beispiele in diesem Artikel wird die Version 3.17.2 verwendet. Die neueste Binärdatei findest du unter in den offiziellen GitHub-Releases.

Installieren unter Windows

Lade die korrekte Binärdatei, die der Architektur deines Systems entspricht, von dem obigen GitHub-Link herunter.

Helm Binary für Windows

Entpacke die heruntergeladene ZIP-Datei. Du solltest die unten abgebildeten Dateien erhalten.

Steuermann binär

Erstelle einen Ordner namens "helm" unter dem Verzeichnis "C:\Programme\". Verschiebe die drei Dateien oben dorthin.

Verschiebe die Dateien in den neu erstellten Ordner "helm".

Jetzt müssen wir in unseren Umgebungsvariablen einen Pfad hinzufügen, der auf das neu erstellte Verzeichnis "C:\Programmdateien\helm" verweist. Öffne die Einstellung "Bearbeiten der Systemumgebungsvariablen".

Bearbeite die Systemumgebungsvariablen

Das unten stehende Fenster "Systemeigenschaften" wird angezeigt. Wähle unter der Registerkarte "Erweitert" die Option "Umgebungsvariablen...".

System-Eigenschaften

Das folgende Fenster "Umgebungsvariablen" wird angezeigt. Wähle unter "Systemvariablen" die Option "Pfad". Achte darauf, dass er blau markiert ist. Wähle danach "Bearbeiten".

Umgebungsvariablen

Das Fenster "Umgebungsvariable bearbeiten" wird angezeigt. Wähle "Neu", gib den Pfad "C:\Programmdateien\helm" ein und wähle "OK".

Bearbeiten Sie die Umgebungsvariable

Wähle "OK" in den Fenstern "Umgebungsvariablen" und "Systemeigenschaften", um sie zu schließen. Öffne ein neues Terminal und überprüfe, ob der Helm-Befehl funktioniert.

Überprüfe die Helm CLI-Installation

Installieren unter macOS

Wir können das Helm CLI auf macOS über Homebrew oder das Binary installieren. Ich werde beide Installationsmethoden behandeln.

Binäre Installation

Öffne das Terminal (zsh) und führe die folgenden Befehle aus.

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-darwin-arm64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-darwin-arm64.tar.gz

# Move the helm binary to /usr/local/bin
sudo mv darwin-arm64/helm /usr/local/bin/

# Verify Helm CLI
helm version

Helm-Installation über Binary unter macOS

Homebrew

Stelle sicher, dass du Homebrew lokal installiert hast. Um das zu überprüfen, führe brew --version aus. Ansonsten kannst du die Installationsanweisungen auf der offiziellen Homebrew-Seite nachlesen.

Führe die folgenden Befehle aus, um das Helm CLI zu installieren:

# With brew installed, update Homebrew's formulae and cask definitions
brew update

# Install Helm CLI
brew install helm

# Verify the installation
helm version

# Verify the location of the helm binary stored locally
which helm

Helm-Installation über brew auf macOS

Installieren unter Linux

Um die Installation unter Linux zu demonstrieren, habe ich eine Amazon Linux EC2 mit dem AMI ami-065a492fef70f84b1 hochgefahren.

# Switch to superuser
sudo su -

# Download the correct binary corresponding to your system’s architecture.
wget https://get.helm.sh/helm-v3.17.2-linux-amd64.tar.gz

# Extract the binary
tar -zxvf helm-v3.17.2-linux-amd64.tar.gz

# Move the helm binary to /usr/local/bin
mv linux-amd64/helm /usr/local/bin/helm

# Verify Helm CLI
helm version

# Clean-up
rm -rf linux-amd64
rm -f helm-v3.17.2-linux-amd64.tar.gz

Herunterladen, entpacken und verschieben der Binärdatei

Helm mit deinem Cluster einrichten

Genauso wie kubectl so konfiguriert ist, dass es mit einem bestimmten Cluster kommuniziert, verwendet Helm auch die Datei ~/.kube/config, um zu wissen, auf welchem Cluster die Befehle ausgeführt werden sollen.

# To find out which context (and therefore cluster) is currently being used
kubectl config current-context

# To view the entire ~/.kube/config file
kubectl config view

# If you’re running an EKS cluster on AWS, execute this command to update your .kubeconfig file and set it to the current context.
aws eks update-kubeconfig --name <Name of EKS cluster> --region <region>

# View helm charts installed in all namespaces on the cluster
helm list -A

Ausgabe der kubectl config-Befehle

Hinzufügen und Aktualisieren von Helm-Repositories

Öffentliche Helm-Diagramme werden in Helm-Repositories gespeichert. Bevor wir ein öffentliches Helm-Diagramm verwenden, müssen wir einige Metadaten aus diesem Repository zu unserem lokalen hinzufügen.

# Adds a Helm repository locally
helm repo add bitnami https://charts.bitnami.com/bitnami

Wo speichert der Befehl helm repo add die Informationen? Führe helm env aus.

Ausgabe von helm repo add und helm env

Der Pfad, der durch HELM_REPOSITORY_CONFIG angezeigt wird, ist der Ort, an dem die Informationen des Repositorys gespeichert sind.

Um alle lokal hinzugefügten Repositories aufzulisten, führe den Befehl helm repo list aus. Sie bezieht die Informationen aus dem Wert von HELM_REPOSITORY_CONFIG.

Für mich wird es die Datei ~/Library/Preferences/helm/repositories.yaml sein.

Um alle Karten im Repository aufzulisten, führe helm search repo bitnami aus.

Ausgabe von helm repo list und helm search repo

Als öffentliche Repositories erhalten sie regelmäßig Updates von den jeweiligen Mitwirkenden. Um die Diagramme im Projektarchiv zu aktualisieren, aktualisierst du einfach das gesamte Projektarchiv.

# Update a repository
helm repo update bitnami

Ausgabe von helm repo update

Erkundung der Struktur einer Steuerkarte

Um wirklich zu verstehen, wie Helmkarten funktionieren, ist es wichtig, sich mit ihrer Struktur vertraut zu machen. 

Ein Helm-Diagramm ist mehr als nur ein Bündel von YAML-Dateien - es ist ein gut organisiertes Verzeichnis, das eine Kubernetes-Anwendung durch die Kombination von Vorlagen, Konfiguration und Metadaten definiert. 

In diesem Abschnitt werde ich die wichtigsten Komponenten aufschlüsseln, darunter das allgemeine Layout des Diagrammverzeichnisses, die Rolle der values.yaml Datei für die Konfiguration und wie Helm Go-Templates verwendet, um dynamisch Kubernetes-Manifeste zu erzeugen.

Verzeichnisstruktur der Karte

Das Standardverzeichnis für Diagramme lautet wie folgt: demo-helm ist der Name des Diagramms, das ich definiert habe. Wir werden sie im nächsten Abschnitt erstellen. 

Gehen wir kurz auf den Zweck der einzelnen Dateien und Ordner ein.

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

• Die Datei .helmignore funktioniert ähnlich wie .gitignore oder .dockerignore. Wenn wir bestimmte Dateien oder Verzeichnisse von unserem Helm-Diagramm ausschließen wollen, können wir ihre Muster in der Datei .helmignore auflisten. Alle Dateien oder Verzeichnisse, die diesen Mustern entsprechen, werden bei der Ausführung von Helm-Befehlen ignoriert.
• Chart.yaml enthält Metadaten über das Helm-Diagramm, wie z. B. den Diagrammnamen, die Beschreibung, die Diagrammversion und die Anwendungsversion.
• values.yaml enthält die Standardkonfigurationswerte, die die Go-Vorlagen des Helm-Charts in Kubernetes-Manifeste umwandeln. Einige gängige Werte, die in dieser Datei definiert sind, sind:
  • Der Bildspeicher und das Tag.
  • Boolesche Flags, um bestimmte Ressourcen zu aktivieren oder zu deaktivieren.
  • Portnummern.
  • Andere anwendungsspezifische Einstellungen.
• Das Verzeichnis charts/ speichert Kartenabhängigkeiten. Wenn unser Helm-Chart von anderen Charts (sogenannten Sub-Charts) abhängt, werden diese hier platziert.
• Zuletzt gibt es noch den Ordner templates/, der die Go-Vorlagendateien enthält, die zur Erstellung von Kubernetes-Manifesten verwendet werden. Diese Vorlagen definieren die Ressourcen, die eingesetzt werden, z.B. Deployment, ServiceAccount, Service, Ingress, und ConfigMap.

values.yaml verstehen

Die values.yaml ist die Standardkonfigurationsdatei, die einen zentralen Ort für die Definition von Eingabewerten bietet, auf die Vorlagen beim Rendern von Kubernetes-Manifesten verweisen.

Wenn du ein Helm-Diagramm installierst, liest Helm die Datei values.yaml und fügt ihren Inhalt über die Template-Engine in die Diagrammvorlagen ein. So können wir das Anwendungssetup parametrisieren, z. B. Container-Image-Versionen, Ressourcenlimits, Anzahl der Replikate, Ingress-Einstellungen und mehr, ohne die Vorlagen direkt zu ändern.

Ein Ausschnitt aus dem Standard values.yaml aus einer neu erstellten Helm-Karte sieht so aus:

# Default values for demo-helm.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

# This will set the replicaset count more information can be found here: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
replicaCount: 1

# This sets the container image more information can be found here: https://kubernetes.io/docs/concepts/containers/images/
image:
  repository: nginx
  # This sets the pull policy for images.
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

# This is for the secrets for pulling an image from a private repository more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
imagePullSecrets: []
# This is to override the chart name.
nameOverride: ""
fullnameOverride: ""

# This section builds out the service account more information can be found here: https://kubernetes.io/docs/concepts/security/service-accounts/
serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Automatically mount a ServiceAccount's API credentials?
  automount: true

Diese Werte werden in den Vorlagendateien mit der Notation . referenziert, zum Beispiel {{ .Values.replicaCount }} oder {{ .Values.image.repository }}. Helm erlaubt es, diese Standardwerte bei der Installation oder beim Upgrade zu überschreiben. Dies geschieht entweder durch eine benutzerdefinierte Wertedatei oder durch die Übergabe einzelner Werte inline.

# Install a helm chart with the default values from values.yaml
helm install demo-helm ./demo-helm

# Values defined in custom-values.yaml will override those in values.yaml.
# Nonetheless, values in values.yaml not found in custom-values.yaml will still be applied.
# “-f” flag is short for the “--values” flag
helm install demo-helm ./demo-helm -f custom-values.yaml

# Overwrite default values using the  “--set” flag
helm install demo-helm ./demo-helm --set replicaCount=3 --set image.tag=latest

Templating mit Go-Vorlagen

Eine der leistungsstärksten Funktionen von Helm ist seine Template-Engine, die eine dynamische und wiederverwendbare Konfiguration von Kubernetes-Manifesten ermöglicht. Go-Templates sind das Herzstück dieser Funktion, und dieselbe Templating-Sprache wird auch in vielen anderen Go-basierten Tools und Frameworks wie Terraform und Docker verwendet.

Anstatt Werte direkt in unsere YAML-Dateien zu kodieren, können wir mit Helm Vorlagen definieren, die auf dynamische Eingaben verweisen - am häufigsten von values.yaml. Zum Beispiel in dem folgenden deployment Template-Snippet:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.name }}
spec:
  replicas: {{ .Values.replicas }}

{{ .Values.name }} und {{ .Values.replicas }} sind Go-Vorlagenausdrücke. Dabei bezieht sich .Values entweder auf den Inhalt der Datei values.yaml, die im Flag --values definierte Datei oder auf inline übergebene Werte. Diese Platzhalter werden durch die tatsächlichen Werte ersetzt, wenn das Diagramm gerendert wird.

Die folgende Vorlage deployment verwendet zum Beispiel Werte wie replicaCount und image.repository.

Mapping zwischen values.yaml und deployment.yaml

Die Vorlage serviceAccount verwendet dagegen serviceAccount.create. Die gesamte Ressource serviceAccount wird weggelassen, wenn der Wert false ist.

Mapping zwischen values.yaml und serviceaccount.yaml

Zur weiteren Veranschaulichung: Angenommen, du hast die folgende Konfiguration in deinem values.yaml.

replicaCount: 2
image:
  repository: nginx
  tag: "1.21.1"

Deine deployment.yaml Vorlage (unter templates/deployment.yaml ) könnte so aussehen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: nginx
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 80

Wenn Helm das Kubernetes-Manifest rendert, entweder während helm template, helm install oder helm upgrade, tut es dies, indem es die Werte von values.yaml injiziert.

# helm template <release name> <chart name OR path to chart folder>
helm template my-nginx <chart name OR path to chart folder>

In diesem Fall erhalten wir das unten stehende Manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
        - name: nginx
          image: "nginx:1.21.1"
          ports:
            - containerPort: 80

Deine erste Steuerkarte erstellen

Der einfachste Weg, Helm zu lernen, ist, selbst eine Karte zu erstellen. Wir werden ein grundlegendes Diagramm erstellen, seine Struktur verstehen und es für den Einsatz unserer Anwendung in Kubernetes anpassen.

Mit helm create

Anstatt öffentliche Helm-Diagramme aus Helm-Repositories zu verwenden, wie wir es oben im Unterabschnitt "Hinzufügen und Aktualisieren von Helm-Repositories" beschrieben haben, erstellen wir ein eigenes.

# Creates a helm chart with the name “demo-helm”
helm create demo-helm

Die Verzeichnisstruktur sieht dann so aus:

#    demo-helm/
#    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
#    ├── Chart.yaml    # Information about your chart
#    ├── values.yaml   # The default values for your templates
#    ├── charts/       # Charts that this chart depends on
#    └── templates/    # The template files
#        └── tests/    # The test files

Ausgabe des Befehls helm create

Vorlagen anpassen

Schauen wir uns den Inhalt des Ordners templates an, um ihn besser zu verstehen, bevor wir ihn verändern.

Inhalte im Vorlagenordner

In der Datei _helpers.tpl werden wiederverwendbare Go-Vorlagenhelfer (ähnlich wie Funktionen) gespeichert, die von anderen Vorlagen innerhalb des Diagramms aufgerufen werden können, was die Wiederverwendbarkeit und Wartbarkeit des Codes fördert .

Die folgende Abbildung zeigt, wie die Abschnitte in der Datei _helpers.tpl der Datei service.yaml zugeordnet sind.

Mapping zwischen _helpers.tpl und service.yaml

Wir können den Befehl helm template ausführen, um die gerenderte service.yaml zu erhalten. Der Befehl prüft, ob die Karte fehlerfrei ist und rendert die Manifestdateien.

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Ausgabe des Befehls helm template

Wir können die Inhalte in der Datei _helpers.tpl oder in den Vorlagenressourcen ergänzen oder ändern, um sie unseren Anforderungen anzupassen. Zum Beispiel, um der Ressource service über die Datei _helpers.tpl ein Selektor-Label hinzuzufügen:

{{- define "demo-helm.selectorLabels" -}}
app.kubernetes.io/name: {{ include "demo-helm.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/custom: "testing" # Add this line
{{- end }}

Füge ein Selektor-Label in _helpers.tpl hinzu

Die Anführungszeichen, die um den Wert testing verwendet werden, müssen gerade Anführungszeichen sein ("testing") und nicht geschweifte Anführungszeichen ("testing"). Obwohl helm template keine Fehlermeldung ausgibt, tut helm install das .

• Speichere die Datei _helpers.tpl und führe den Befehl helm template erneut aus. Du solltest sehen, dass der Selektor zur Serviceressource hinzugefügt wird.

Aktualisierte Ausgabe des Befehls helm template

Beachte, dass sie nicht nur zum Selektor, sondern auch zu den Labels aller Ressourcen hinzugefügt wurde. Das liegt daran, dass die {{- define "demo-helm.labels" -}} die {{ include "demo-helm.selectorLabels" . }} enthält. So wird alles, was auf selectorLabels steht, in den Etiketten enthalten sein .

Ein anderes Beispiel ist, dass wir die deployment.yaml ändern können, um einen anderen Port auf dem Container freizugeben. Wenn wir ein Diagramm mit dem Befehl helm create erstellen, gibt die Bereitstellungsvorlage standardmäßig nur einen Port des Containers an.

• Füge die folgende Konfiguration zur deployment.yaml hinzu.

- name: https
  containerPort: 443
  protocol: TCP

Einen Port zum Container in deployment.yaml hinzugefügt

Der Einfachheit halber ist der Wert containerPort fest auf 443 programmiert. Im nächsten Unterabschnitt werden wir untersuchen, wie du die values.yaml nutzen kannst, um sie zu parametrisieren .

• Speichere die Datei deployment.yaml und führe den Befehl helm template erneut aus. Der Port sollte nun dem Container in der Verteilungsressource hinzugefügt werden.

Da die Einrückung bei der YAML-Formatierung wichtig ist, enthält die Vorlage für die Kubernetes-Ressourcen die Funktion nindent, um die erforderlichen Blöcke entsprechend einzurücken.

apiVersion: v1
kind: Service
metadata:
  name: {{ include "demo-helm.fullname" . }}
  labels:
    {{- include "demo-helm.labels" . | nindent 4 }} 
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    {{- include "demo-helm.selectorLabels" . | nindent 4 }}

Festlegen von Standardwerten

Nachdem wir nun den größten Teil des Inhalts des Vorlagenordners abgedeckt haben, sind wir bereit, zum values.yaml überzugehen.

Verzeichnis der Steuerkarten

Im vorigen Unterabschnitt haben wir containerPort als 443 fest programmiert. Lass es uns parametrisieren. 

• In values.yaml fügst du unter dem Schlüssel service den verschachtelten Schlüssel https_port mit dem Wert 443 hinzu.

Verschachtelten Schlüssel hinzufügen

• Ändere die deployment.yaml, um die fest codierte 443 durch {{ .Values.service.port }} zu ersetzen.

Parametriere die Portnummer

• Um die Kubernetes-Ressourcen zu validieren und zu rendern:

# helm template <release name> <chart name OR path to chart folder>
helm template demo-helm ./demo-helm

Du solltest sehen, dass der Wert 443 auf containerPort korrekt eingestellt ist.

Wert von https_port wiedergegeben

Wenn es andere Stellen in der Helmkarte gibt, die den Wert dieser containerPort benötigen, benutze einfach {{ .Values.service.https_port }}.

Bereitstellen und Verwalten von Releases

Nachdem wir nun unser eigenes Helm-Diagramm erstellt haben, wäre der nächste Schritt, es in einem Kubernetes-Cluster einzusetzen. 

Helm verwaltet den Lebenszyklus der bereitgestellten Kubernetes-Ressourcen als Release. In diesem Abschnitt erfahren wir, wie Helm Deployments, Upgrades, Rollbacks und die Nachverfolgung des Versionsverlaufs handhabt und uns damit eine starke Kontrolle und Transparenz über unsere Kubernetes-Workloads gibt.

Was ist eine Befreiung?

In Helm ist ein Release eine bestimmte Instanz einer Helm-Karte, die in einem Kubernetes-Cluster eingesetzt wurde.

Jedes Mal, wenn wir eine Karte mit helm install installieren, erstellt Helm eine neue Version mit eigenem Namen, eigener Konfiguration und eigener Version. Ähnlich verhält es sich, wenn wir eine Version mit helm upgrade aktualisieren. Helm erstellt eine neue Revision dieser Version mit demselben Namen, aber die Konfiguration und Version können sich unterscheiden. Im Grunde genommen ist ein Release eine neue Version desselben Releases mit aktualisierten Einstellungen oder Karteninhalten.

Wenn wir also sagen: "Installiere ein Helm-Diagramm", meinen wir in Wirklichkeit "Erstelle ein Helm-Release".

Visuelle Illustration von Freisetzungen - Bild vom Autor.

Obwohl nur die aktuellste Revision einer Version aktiv im Cluster eingesetzt wird, speichert Helm den gesamten Verlauf der vorherigen Revisionen. Das bedeutet, dass wir mit helm rollback leicht zu einem früheren Zustand zurückkehren können.

Wenn wir ein Rollback durchführen, stellt Helm die alte Release-Revision nicht unverändert wieder her, sondern erstellt eine neue Revision, die die Konfiguration der ausgewählten vorherigen Version repliziert. Jede Revision wird nummeriert, und Rollbacks erhöhen die Revisionsnummer, damit die Versionsgeschichte konsistent und nachvollziehbar bleibt.

Installieren einer Karte mit helm install

Gehen wir nun durch den Einsatz einer Helm-Version in einem Kubernetes-Cluster. Wir werden zwei Helm-Karten installieren: die, die wir im vorherigen Abschnitt erstellt haben, und die Karte bitnami/apache aus dem öffentlichen Bitnami-Repository, die wir bereits zu unserem lokalen Helm-Setup hinzugefügt haben.

bitnami/apache Helm Diagramm

Bei der Installation eines Diagramms müssen wir einen Versionsnamen angeben. Dieser kann frei gewählt werden und muss nicht mit dem Namen des Diagramms übereinstimmen. Es wird jedoch empfohlen, einen Namen zu verwenden, der eng mit dem Diagramm zusammenhängt, damit die Nutzerinnen und Nutzer auf einen Blick erkennen können, was die Veröffentlichung darstellt.

• Zuerst für die Helmkarte, die wir erstellt haben:

# Install the helm chart (in other words, create a helm release) into the default namespace
# helm install <release name> <chart name OR path to chart folder>
helm install datacamp-demo-helm ./demo-helm
# OR
helm upgrade --install datacamp-demo-helm ./demo-helm

# If installing to a specific namespace, add the -n flag
# Install the chart to the “app” namespace
helm install my-amazing-helm-demo ./demo-helm -n app

Einsetzen einer benutzerdefinierten Helm-Karte

# To validate the Kubernetes resources
# Get pods, service, and serviceaccount resources in the default namespace
kubectl get pods,svc,sa

Validierung von Ressourcen, die über das benutzerdefinierte Helm-Diagramm bereitgestellt werden

• Zweitens, für die bitnami/apache Tabelle:

# Install the helm chart into the default namespace
helm install apache bitnami/apache
# OR
helm upgrade --install apache bitnami/apache

Ausgabe von helm install

Ausgabe von helm upgrade --install

So siehst du die Helm-Versionen, die eingesetzt wurden:

# List all helm releases in all namespaces
helm list -A

Alle Helm-Veröffentlichungen auflisten

Aufrüsten mit Steuerruder-Upgrade

Nach dem ersten Einsatz eines Helm-Diagramms sind Aktualisierungen unvermeidlich - ob du nun das Image-Tag änderst, die Anzahl der Replikate anpasst, optionale Ressourcen aktivierst oder deaktivierst oder die Konfigurationswerte modifizierst.

Helm bietet den Befehl helm upgrade, um diese Änderungen auf eine bestehende Version anzuwenden, ohne sie von Grund auf neu zu verteilen. Mit diesem Befehl können wir unsere laufende Anwendung aktualisieren, indem wir die Vorlagen mit der neuen Konfiguration neu rendern und die Änderungen auf den Kubernetes-Cluster anwenden, sodass die Aktualisierungen nahtlos und mit minimalen Unterbrechungen durchgeführt werden.

Die Anwendung, die über unsere benutzerdefinierte Helmkarte bereitgestellt wird, führt ein nginx Image mit dem 1.16.0 Tag aus. Wir können den Tag ermitteln, indem wir den Befehl helm get manifest ausführen.

# Output the rendered Kubernetes manifest that was installed by the helm chart
# helm get manifest <release name>
helm get manifest datacamp-demo-helm

Im Manifest der Ressource deployment solltest du Folgendes sehen:

Bildwert

Woher kommt der 1.16.0 Tag? Unser image.tag in values.yaml Wert ist leer .

Untersuche die Vorlage deployment.yaml: Der Schlüssel image hat den Wert "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}". Wenn image.tag nicht in values.yaml definiert ist, bezieht Helm den Wert aus appVersion, das in Charts.yaml definiert ist.

appVersion in Chart.yaml

• Aktualisieren wir die values.yaml unseres benutzerdefinierten Diagramms, aktualisieren wir die image.tag auf "1.26".

Aktualisiere image.tag von "" auf "1.26".

• Führe danach den Befehl helm upgrade aus.

# helm upgrade <release name> <chart name or path to chart>
helm upgrade datacamp-demo-helm ./demo-helm

# Alternatively, you can update the value via the --set flag
helm upgrade datacamp-demo-helm ./demo-helm --set 

Die Ausgabe des Befehls helm upgrade

Überprüfe die Deployment-Ressource; das Bild-Tag sollte 1.26 sein. Hinter den Kulissen macht Helm während eines Upgrades Folgendes:

1. Template-Rendering: Helm stellt die Vorlagen des Diagramms mit den (aktualisierten) Werten, die mit dem Befehl übergeben wurden, neu dar.
2. Bestimme die Änderungen: Helm vergleicht die neu gerenderten Manifeste mit den aktuellen Manifesten im Cluster. Im letzten Abschnitt des Artikels geht es darum, die Änderungen zu überprüfen, bevor sie angewendet werden.
3. Selektives Update: Nur die Ressourcen, die sich geändert haben (wie deployment, configmaps oder secrets ), werden aktualisiert.
4. Lernpfad zur Versionsgeschichte: Helm zeichnet die neue Version und Konfiguration auf, sodass wir bei Bedarf ein Rollback durchführen können.

# To view the release history. It also shows the revision numbers.
# helm history <release name>
helm history datacamp-demo-helm

Ausgabe des Befehls helm history

Rückgängig machen mit helm rollback

Wir haben gerade ein Helm-Release aktualisiert, aber kurz darauf stellen wir fest, dass sich die Anwendung nicht wie erwartet verhält. Die Fehlersuche ist zwar wichtig, aber in einer Produktionsumgebung ist die unmittelbare Priorität oft die Stabilisierung des Systems. Hier kommt die Rollback-Funktion von Helm ins Spiel. 

Helm macht es einfach, mit einem einzigen Befehl zu einer früheren, als gut bekannten Version zurückzukehren, so dass wir uns schnell von fehlgeschlagenen Einsätzen erholen und Ausfallzeiten minimieren können. 

• Wir werden das oben durchgeführte Upgrade rückgängig machen.

# The first argument of the rollback command is the name of a release, and the second is a revision (version) number. If this argument is omitted or set to 0, it will roll back to the previous release.
# helm rollback <release name> <revision number>
helm rollback datacamp-demo-helm 0

Die Ausgabe des Befehls helm rollback

Überprüfe das datacamp-demo-helm Deployment und du solltest sehen, dass das nginx-Image-Tag wieder auf 1.16.0 steht.

kubectl get deploy datacamp-demo-helm -oyaml

Deinstallation einer Version

Um die Helm-Version zu deinstallieren, d.h. um alle Kubernetes-Ressourcen zu löschen, die von der Version bereitgestellt werden, führe den Befehl helm uninstall aus.

# helm uninstall <release name>
helm uninstall datacamp-demo-helm
helm uninstall apache

Ausgabe des Befehls helm uninstall

Wie Helm skalierbare CI/CD-Pipelines unterstützt, insbesondere für ML-Workflows, erfährst du im Kurs CI/CD für Machine Learning.

Anpassen von Steuerkarten für verschiedene Umgebungen

Eine der größten Stärken von Helm ist seine Flexibilität. Egal, ob wir für die Entwicklung, das Staging oder die Produktion deployen, Helm macht es einfach, das Verhalten unserer Diagramme durch Konfiguration anzupassen. 

In diesem Abschnitt erfahren wir, wie du ein Helm-Diagramm für verschiedene Umgebungen anpassen kannst, indem du Werkzeuge wie values.yaml, umgebungsspezifische Überschreibungen und die Helm-Flags --set und -f verwendest.

Mehrere values.yaml-Dateien verwenden

Helm bietet eine flexible Möglichkeit, umgebungsspezifische Konfigurationen mit mehreren values.yaml Dateien zu verwalten.

Anstatt eine einzige, komplexe values.yaml zu pflegen, die versucht, alle möglichen Einstellungen für Dev, Staging und Production zu berücksichtigen, oder komplexe bedingte Anweisungen in unseren Templates, um die verschiedenen Umgebungen zu berücksichtigen, können wir diese in separate Dateien aufteilen, die jeweils auf eine bestimmte Umgebung zugeschnitten sind.

Unser Kartenverzeichnis könnte zum Beispiel Folgendes enthalten:

my-chart/
├── values.yaml                    # default values
├── values-dev.yaml           # development-specific overrides
├── values-staging.yaml    # staging-specific overrides
└── values-prod.yaml          # production-specific overrides

Werte bei der Installation außer Kraft setzen

Helm ermöglicht es uns, die in values.yaml definierten Standardwerte zu überschreiben, indem wir entweder das --set Flag für Inline-Überschreibungen oder das -f Flag für die Bereitstellung einer externen Wertedatei verwenden. -f ist die Abkürzung für die --values Flagge.

Um unsere Helm-Version zu installieren oder zu aktualisieren, verwenden Sie die -f Flagge:

# For installing on dev
helm install <release name> <chart name or path to chart> -f values-dev.yaml

# For upgrading on dev
helm upgrade <release name> <chart name or path to chart> -f values-dev.yaml

# For installing on staging
helm install <release name> <chart name or path to chart> -f values-staging.yaml

# For upgrading on staging
helm upgrade <release name> <chart name or path to chart> -f values-staging.yaml

Um unsere Helm-Version mit dem --set Flag zu installieren oder zu aktualisieren:

# For installation
helm install <release name> <chart name or path to chart> --set image.tag=1.26

# For upgrading
helm upgrade <release name> <chart name or path to chart> --set image.tag=1.26

Wenn bei der Installation (oder beim Upgrade) sowohl --set als auch -f verwendet werden, wendet Helm die Werte in der folgenden Reihenfolge an:

1. Die Basis values.yaml (falls vorhanden)
2. Werte aus der Datei, die mit -f
3. Inline-Werte, die mit --set

Das bedeutet, wenn derselbe Schlüssel sowohl in der Datei -f als auch in der Flagge --set vorkommt, hat der Wert aus --set Vorrang .

Wenn wir zum Beispiel image.tag als 1.22 in values-dev.yaml definiert haben, aber image.tag über das --set Flag auf 1.26 setzen, wird der image.tag Wert, der zum Rendern des Kubernetes-Manifests verwendet wird, 1.26 sein.

# E.g. we defined image.tag to be 1.22 in values-dev.yaml
helm install <release name> <chart name OR path to chart> --set image.tag=1.26 -f values-dev.yaml

Geheimnisse verwalten

Wenn du mit Helm Anwendungen in Kubernetes bereitstellst, musst du beim Umgang mit sensiblen Daten wie API-Schlüsseln, Datenbankanmeldeinformationen oder TLS-Zertifikaten besonders vorsichtig sein. Helm unterstützt zwar die Kubernetes-Ressource Secret, aber die Werte in der geheimen Ressource sind einfach base64-kodiert, was von jedem entschlüsselt werden kann .

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: default
type: Opaque
data:
  key1: c3VwZXJzZWNyZXQ=  # ← This is base64 encoded
  key2: dG9wc2VjcmV0          # ← This is base64 encoded

# Decode the value of key1
echo "c3VwZXJzZWNyZXQ=" | base64 -d

# Decode the value of key2
echo "dG9wc2VjcmV0" | base64 -d

Geheimnisse direkt in einer values.yaml Datei oder im Klartext in unserer Tabelle zu speichern, ist nicht sicher und sollte vermieden werden, vor allem wenn Dateien in die Versionskontrolle übertragen werden .

Um Geheimnisse in Helm-Diagrammen über verschiedene Umgebungen hinweg sicher zu verwalten, solltest du spezielle Tools für diesen Zweck verwenden. Zwei weit verbreitete Lösungen sind "Sealed Secrets" und "External Secrets".

Versiegelte Geheimnisse

Sealed Secrets ist ein von Bitnami entwickeltes Open-Source-Projekt, das dabei hilft, sensible Daten in Kubernetes auf eine sichere und GitOps-freundliche Weise zu verwalten. Sie führt eine benutzerdefinierte Ressourcendefinition (CRD) namens SealedSecret ein, mit der wir Geheimnisse verschlüsseln können, bevor wir sie in ein Git-Repository übertragen.

Im Gegensatz zu regulären Kubernetes secrets Ressourcen, die Daten in base64-Kodierung speichern und nicht verschlüsselt sind, enthalten SealedSecret Ressourcen verschlüsselte Werte, die nur vom Sealed Secrets Controller entschlüsselt werden können, der im Ziel-Kubernetes-Cluster läuft. Das bedeutet, dass die verschlüsselten Geheimnisse sicher in Versionskontrollsystemen wie Git gespeichert werden können.

Um unseren Cluster und unsere lokale Umgebung für die Nutzung von Sealed Secrets einzurichten:

• Installiere die SealedSecret CRD und den serverseitigen Controller (der als Pod läuft) in den Namespace kube-system

kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/controller.yaml
#OR
helm install sealed-secret bitnami/sealed-secrets -n kube-system

Installiere SealedSecret auf unserem Cluster über kubectl

Installiere SealedSecret auf unserem Cluster über Helm

• Überprüfe die Ressourcen:

Überprüfe Ressourcen bei der Installation von Sealed Secrets

• Installiere die kubeseal CLI auf unserem lokalen System.

# Linux x86_64:
curl -OL "https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.29.0/kubeseal-0.29.0-linux-amd64.tar.gz"
tar -xvzf kubeseal-0.29.0-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

# macOS
brew install kubeseal

Um die Ressource SealedSecret CRD zu erstellen:

# Pass the secret manifest to kubeseal for it to generate the SealedSecret CRD resource containing the encrypted secrets. Saves the SealedSecret CRD manifest in sealed-mysecret.yaml.
kubectl create secret generic mysecret --dry-run=client --from-literal key1=supersecret --from-literal key2=topsecret --output json | kubeseal | tee sealed-mysecret.yaml

# Or if you have the secret manifest saved in a JSON file
kubeseal -f mysecret.yaml -w sealed-mysecret.yaml

Erstelle und speichere die SealedSecret CRD-Ressource

Wende die Datei sealed-mysecret.yaml an. Wenn eine SealedSecret Ressource im Cluster erstellt wird, entschlüsselt der Controller automatisch die versiegelten Daten und erstellt daraus eine standardmäßige Kubernetes secrets Ressource.

Erstelle die CRD-Ressource SealedSecret

Dieser Ansatz gewährleistet, dass sensible Informationen während der gesamten CI/CD-Pipeline sicher bleiben.

External Secrets Operator (ESO)

Der External Secrets Operator (ESO) ist ein Kubernetes-Operator, der es uns ermöglicht, Geheimnisse aus externen Geheimhaltungssystemen wie AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault und anderen sicher in Kubernetes Secrets zu holen und zu injizieren. 

Anstatt Kubernetes Secrets manuell zu erstellen oder zu aktualisieren, ruft ESO die neuesten geheimen Werte von diesen externen Anbietern über ihre APIs ab und stellt sicher, dass unser Kubernetes-Cluster immer über aktuelle Anmeldeinformationen oder sensible Daten verfügt.

ESO führt eine Reihe von benutzerdefinierten Ressourcen ein -ExternalSecret und ClusterSecretStore-, die die Komplexität der Interaktion mit externen geheimen Backends beseitigen. Diese Ressourcen legen fest, welche Secrets von wo geholt werden sollen, und machen es einfacher, die Lebenszyklen von Secrets auf deklarative und Kubernetes-native Weise zu verwalten.

In diesem Beispiel werden wir ein Geheimnis aus dem AWS Secrets Manager abrufen. 

• Als erstes erstellst du eine IAM-Rolle, die vom external-secrets Pod verwendet wird, um das Geheimnis aus dem AWS Secrets Manager zu holen.

IAM-Rolle für den Pod "external-secrets

Die Berechtigungsrichtlinie für die IAM-Rolle sieht folgendermaßen aus:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ESO",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "*"
        }
    ]
}

• Zweitens: Erstelle ein Geheimnis im AWS Secrets Manager.

AWS Secrets Manager Geheimnis

Um unseren Cluster für die Nutzung von ESO einzurichten:

helm repo add external-secrets https://charts.external-secrets.io


# Replace the ARN of the IAM role
helm install external-secrets external-secrets/external-secrets \
    -n external-secrets \
    --create-namespace \
    --version 0.15.1 \
    --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"="<ARN of IAM Role>"

Ergebnis der Installation von externen Geheimnissen

• Überprüfe die Installation:

kubectl get pods,crd -n external-secrets

Überprüfe die Ressourcen bei der Installation von ESO

• Um die Ressource ClusterSecretStore bereitzustellen, speicherst du die folgende Datei unter cluster-secret-store.yaml und erstellst die Ressource.

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: "cluster-secret-store"
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-southeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: "external-secrets"
            namespace: "external-secrets"

kubectl create -f cluster-secret-store.yaml
kubectl get ClusterSecretStore

Die benutzerdefinierte Ressource ClusterSecretStore ist ein clusterweiter SecretStore, der von ExternalSecrets aus jedem Namespace referenziert werden kann. Sie verweist auf die external-secrets serviceAccount, um sich bei AWS Secrets Manager zu authentifizieren.

Validierung der Erstellung der ClusterSecretStore-Ressource

• Um das Geheimnis demo-datacamp-ESO aus dem AWS Secrets Manager zu ziehen, musst du die benutzerdefinierte Ressource ExternalSecret bereitstellen. Wir werden den Wert des Schlüssels password abrufen. Speichere das Folgende unter external-secret.yaml und erstelle die Ressource.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: demo-datacamp-secret
  namespace: default  # Change to your target namespace
spec:
  refreshInterval: 1h # How often to refresh the secret
  secretStoreRef:
    name: cluster-secret-store # This references your ClusterSecretStore
    kind: ClusterSecretStore
  target:
    name: demo-datacamp-k8s-secret # The name of the resulting Kubernetes Secret
    creationPolicy: Owner # ESO manages lifecycle of the K8s secret
  data:
    - secretKey: password # Key name in the Kubernetes Secret
      remoteRef:
        key: demo-datacamp-ESO # AWS Secrets Manager secret name
        property: password # Key in the AWS secret JSON object

kubectl create -f external-secret.yaml
kubectl get externalsecrets
kubectl get secrets

Überprüfe das erfolgreiche Abrufen des Geheimnisses

Aus dem obigen Bild können wir ersehen, dass der Wert top_secret_password des password Schlüssels erfolgreich aus dem AWS Secrets Manager geholt und ein Kubernetes-Geheimnis mit dem Wert erstellt wurde.

Best Practices für die Entwicklung von Helm-Charts

Da unsere Nutzung von Helm über die einfache Karteninstallation hinausgeht, ist es wichtig, Best Practices zu befolgen, die die Wartbarkeit, Wiederverwendbarkeit und Zuverlässigkeit fördern. 

In diesem Abschnitt geht es um wichtige Entwicklungspraktiken wie die Verwendung von Helm-Plugins zur Erweiterung der Funktionalität, die Strukturierung von Diagrammen zur Wiederverwendung, die Validierung unserer Diagramme mit Linting-Tools und die effektive Verwaltung von Versionen und Abhängigkeiten.

Helm-Plugins

Helm-Plugins sind eine leistungsstarke Möglichkeit, die Kernfunktionen von Helm zu erweitern und an deinen Arbeitsablauf anzupassen. Sie ermöglichen es uns, benutzerdefinierte Befehle hinzuzufügen und mit externen Tools zu integrieren, ohne Helm selbst zu verändern.

Plugins können aus Git-Repositories, Tarballs oder lokalen Verzeichnissen installiert werden. Sobald sie installiert sind, verhalten sie sich wie native Helm-Befehle. Helm-Plugins werden lokal auf unserem Rechner installiert, nicht auf dem Kubernetes-Cluster. Das bedeutet, dass sie unsere lokalen Helm CLI-Funktionen erweitern und keine Änderungen oder Einsätze im Kubernetes-Cluster erfordern. Jeder Benutzer oder jedes System, auf dem Helm läuft, muss die gewünschten Plugins unabhängig voneinander installieren.

Ein weit verbreitetes Plugin, das vor allem in CI/CD-Pipelines eingesetzt wird, ist helm-diff. Sie vergleicht ein Helm-Release mit einem Helm-Chart und zeigt, welche Änderungen vorgenommen werden würden. Dies ist besonders nützlich für die Vorschau von Upgrades.

# Install the plugin
helm plugin install https://github.com/databus23/helm-diff

# List installed plugins
helm plugin list

# View the changes for an upgrade
helm diff upgrade datacamp-demo-helm ./demo-helm --set image.tag="1.26"

Ausgabe von helm plugin Befehlen

Ausgabe des Befehls helm diff

Strukturierung wiederverwendbarer Diagramme

Mit zunehmender Nutzung von Helm wird die Strukturierung unserer Diagramme für die Wiederverwendbarkeit immer wichtiger. Ein gut strukturiertes Helm-Diagramm fördert die Konsistenz, vereinfacht die Wartung und ermöglicht modulare Einsatzmuster für verschiedene Projekte. Hier sind zwei Tipps:

Vorlagen und Hilfsmittel verwenden

Wie im Unterabschnitt "Anpassen von Vorlagen" im Abschnitt "Erstellen deines ersten Helm-Diagramms" gezeigt, haben wir die Datei _helpers.tpl genutzt, um einen zusätzlichen Selektor zur Ressource deployment und Beschriftungen zu allen Ressourcen hinzuzufügen. Durch die Verwendung von Hilfsvorlagen wird Doppelarbeit vermieden und eine einzige Quelle der Wahrheit für häufig wiederverwendete Snippets geschaffen. Das verbessert die Konsistenz deines Diagramms und macht die Wartung einfacher - alle zukünftigen Änderungen müssen nur an einer Stelle vorgenommen werden.

Große Diagramme in Unterdiagramme aufteilen

Wenn unsere Anwendung aus mehreren lose gekoppelten Komponenten besteht (z. B. einer Web-App, einer Datenbank und Redis), solltest du das Diagramm in Unterdiagramme aufteilen. Platziere sie im Ordner charts/ und verwalte sie als Abhängigkeiten über Chart.yaml.

dependencies:
  - name: redis
    version: 17.1.2
    repository: https://charts.bitnami.com/bitnami

Führe helm dependency update aus, um diese Unterdiagramme einzulesen. Das macht jede Komponente unabhängig verwaltbar und fördert die Wiederverwendung in verschiedenen Projekten.

Linting und Validierung von Karten

Bevor du ein Helm-Diagramm in einem Kubernetes-Cluster einsetzt, musst du sicherstellen, dass das Diagramm gut strukturiert, syntaktisch korrekt und logisch fundiert ist. Helm bietet integrierte Werkzeuge, die uns helfen, Probleme durch Linting und Testen frühzeitig zu erkennen.

Der Befehl helm lint analysiert unser Diagramm auf häufige Fehler und Verstöße gegen die Best Practice. Sie prüft die Syntax der Vorlagen, die Struktur der Diagrammdateien und das Vorhandensein der erforderlichen Felder in Chart.yaml.

helm lint ./demo-helm

Ausgabe des Befehls helm lint

Wenn wir den Wert von name in Chart.yaml von "demo-helm" in "demo_helm" ändern würden, gäbe es ein Problem, bei dem helm lint hängen bleiben würde.

Ändere das "-" in "_"

helm lint gibt Warnmeldungen aus

Durch das Linting und Testen unserer Charts vor dem Einsatz reduzieren wir das Risiko von Fehlversuchen und Fehlkonfigurationen in der Produktion. Diese Praktiken sind wichtig, um hochwertige Helm-Diagramme zu erhalten, die sich in verschiedenen Umgebungen vorhersehbar verhalten.

Versionierung und Abhängigkeitsmanagement

Da sich unsere Lernpfade weiterentwickeln und von anderen Lernpfaden abhängen, ist es wichtig, die Versionen konsistent zu verwalten und die Abhängigkeiten genau zu verfolgen. Helm bietet integrierte Mechanismen, um dies durch semantische Versionierung, die Chart.lock Datei und Chart.yaml Abhängigkeiten zu unterstützen.

Helm verwendet Semantic Versioning für Kartenversionen. Die Version einer Karte wird in Chart.yaml unter dem Schlüssel version definiert:

Chart Version

Die semantische Versionierung folgt dem Format: MAJOR.MINOR.PATCH

• MAJOR - entscheidende Änderungen
• MINOR - rückwärtskompatible Funktionserweiterungen
• PATCH - Abwärtskompatible Fehlerbehebungen

Die Diagrammversion sollte immer dann erhöht werden, wenn es Änderungen am Diagramm selbst gibt, einschließlich seiner Vorlagen, Werte oder sogar der Anwendungsversion. Gleichzeitig spiegelt die Anwendungsversion die Version der tatsächlichen Anwendung wider, die das Diagramm einsetzt, und ist in der Regel auf das im Diagramm verwendete Image-Tag abgestimmt. Sie sollte aktualisiert werden, wenn sich das Anwendungsimage ändert.

Eine korrekte Versionskontrolle hilft den Teams zu erkennen, ob ein Upgrade sicher ist oder zusätzliche Vorsicht erfordert. Außerdem kann Helm so Upgrade-Pfade und Abhängigkeiten zuverlässiger verwalten.

In Helm 3, das wir für diesen Artikel verwendet haben, werden die Abhängigkeiten direkt in der Datei Chart.yaml unter dem Abschnitt dependencies definiert. Sie ist nicht standardmäßig enthalten, wenn wir das Diagramm erstellen. Dies ersetzt die Datei requirements.yaml aus Helm 2.

In Chart.yaml definierte Abhängigkeiten

Die Datei Chart.lock wird automatisch erstellt, wenn du helm dependency update ausführst. Sie funktioniert wie ein Lockfile in vielen Paketmanagern, indem sie die genauen Versionen der einzelnen Abhängigkeiten aufzeichnet, wie sie im Abschnitt dependencies von Chart.yaml definiert sind. So werden reproduzierbare Builds und ein einheitliches Verhalten in verschiedenen Umgebungen und Teams sichergestellt.

Inhalt in Chart.lock

Wenn du mit Terraform vertraut bist, ähnelt das Konzept der .terraform.lock.hcl Datei, die Provider-Versionen sperrt. Die zugrunde liegenden Formate und Ökosysteme unterscheiden sich zwar, aber beide sperren Abhängigkeitsversionen, um Stabilität und Wiederholbarkeit zu gewährleisten.

Fazit

Helm-Diagramme bieten eine leistungsstarke, standardisierte Möglichkeit, Anwendungen in Kubernetes zu verpacken, zu konfigurieren und bereitzustellen. In diesem Artikel haben wir uns angesehen, was ein Helm-Diagramm ist, wie es aufgebaut ist und wie es den Bereitstellungsprozess in verschiedenen Umgebungen vereinfacht.

Wir sind die wichtigsten Schritte durchgegangen:

• Erstelle deine erste Helm-Karte mit helm create.
• Konfigurationen anpassen durch values.yaml und umgebungsspezifische Overrides.
• Einsetzen und Verwalten von Releases mit Befehlen wie helm install, helm upgrade und helm rollback.
• Befolgung von Best Practices wie Linting-Diagramme, Strukturierung wiederverwendbarer Komponenten, sicherer Umgang mit Geheimnissen und effektive Verwaltung von Versionen und Abhängigkeiten.

Wenn du dich mit Helm vertraut gemacht hast, nimm dir die Zeit, das riesige Ökosystemder öffentlichen Helm-Diagrammezu erkunden, die vony Gemeinschaften und Anbietern gleichermaßen bereitgestellt werden. Diese Diagramme können deine Einsätze beschleunigen und als wertvolle Referenz für deine eigene Entwicklung dienen.

Und schließlich solltest du in Erwägung ziehen, deine Diagramme der Community zur Verfügung zu stellen. Ganz gleich, ob es sich um ein benutzerdefiniertes internes Tool oder eine gut verpackte Version eines Open-Source-Projekts handelt, deine Diagramme können anderen helfen, effizienter und konsistenter in der Kubernetes-Welt zu deployen.

Helm macht Kubernetes einfacher - ein Diagramm nach dem anderen.

• Wenn du vorhast, eine Kubernetes-Zertifizierung zu machen, schau dir diesenBlog an: Kubernetes Certification Guide: Prüfungen, Tipps und Lernressourcen. 
• Wenn du einen strukturierten Lernpfad suchst, der die Grundlagen von Docker und Kubernetes kombiniert, schau dir unseren Lernpfad zu Containerisierung und Virtualisierung an.
• Frische deine Git-Kenntnisse auf, um Helm-Werte und Konfigurationsdateien besser zu verwalten, indem du unsere Kurse Einführung in Git und Git für Fortgeschrittene nutzt.