Helm paketiert eine Kubernetes-Anwendung in ein Chart: ein Verzeichnis mit Manifest-Templates plus einem Satz Standardwerte. Diese Anleitung behandelt die Ordnerstruktur, die jedes Chart teilt, und die drei Konzepte Chart, Values und Release, auf denen alles andere in Helm aufbaut.

Warum nicht einfach reine Manifeste schreiben

Eine nicht triviale Anwendung ist selten ein einzelnes Deployment. Sie besteht aus einem Deployment, einem Service, einer ConfigMap, vielleicht einem Secret und einem Ingress, und du willst denselben Satz in Dev, Staging und Produktion deployen, wobei sich nur eine Handvoll Werte unterscheidet: ein Image-Tag, eine Replikazahl, ein Namespace. Manifeste pro Umgebung zu kopieren bedeutet, dass jedes gemeinsame Feld aus dem Takt geraten kann. Ein Chart hält die Manifeste einmal als Templates und lässt jede Installation ihre eigenen Values liefern.

Die Ordnerstruktur

helm create webapp

Das erzeugt:

webapp/
├── Chart.yaml           # Chart-Metadaten: Name, Version, Beschreibung
├── values.yaml          # Standard-Konfigurationswerte
├── charts/              # Charts, von denen dieses abhängt
├── .helmignore
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── _helpers.tpl      # wiederverwendbare Template-Schnipsel
    ├── NOTES.txt         # wird nach Install/Upgrade ausgegeben
    └── tests/
        └── test-connection.yaml

Chart.yaml enthält Metadaten über das Chart selbst, vor allem Name, Version und apiVersion (v2 für Helm 3 und aktuelles Helm 4). values.yaml enthält die Standardkonfiguration. templates/ enthält Kubernetes-Manifeste mit Helms Template-Syntax. charts/ enthält alle Charts, von denen dieses abhängt, was erst relevant wird, wenn du Charts zusammensetzt. Das erzeugte Beispiel ist ein funktionierendes nginx-Chart mit mehr, als man meist braucht; die meisten Teams löschen das Gerüst und schreiben ihre eigenen drei oder vier Templates oder stutzen, was nicht zutrifft.

Values fließen in Templates

Ein Template sieht aus wie ein normales Manifest mit Platzhaltern:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appName }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Values.appName }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

# values.yaml
appName: webapp
replicaCount: 2
image:
  repository: nginx
  tag: "1.25"

.Values ist ein Objekt, das aus values.yaml aufgebaut und mit allem zusammengeführt wird, was auf der Kommandozeile angegeben wird. helm install oder helm template rendert jede Datei unter templates/ mit diesem Objekt und erzeugt reines Kubernetes-YAML. Die Syntax {{ }} sind Go-Templates, dieselbe Template-Sprache, die auch anderswo im Kubernetes-Ökosystem genutzt wird, es gibt also nichts Proprietäres zu lernen. Values lassen sich auf drei Arten überschreiben, in aufsteigender Priorität: die Standardwerte aus values.yaml, eine zusätzliche mit -f übergebene Datei und einzelne --set key=value-Flags auf der Kommandozeile.

Ein Release ist ein konkretes Deployment eines Charts

Ein Chart zu rendern und das Ergebnis auf einen Cluster anzuwenden erzeugt ein Release: eine benannte, verfolgte Installation mit eigener Historie.

helm install web-dev ./webapp
helm list

web-dev ist der Release-Name. Du kannst dasselbe Chart mehrfach unter verschiedenen Release-Namen installieren, im selben Namespace oder in verschiedenen, zum Beispiel web-dev und web-staging. Jedes helm upgrade an einem Release fügt seiner Historie eine neue Revision hinzu, was genau helm rollback später möglich macht: Helm wendet nicht nur YAML an, es verfolgt, was wann angewendet wurde. Die Anleitung zur Release-Verwaltung in dieser Reihe behandelt diesen Workflow vollständig.

Wofür NOTES.txt da ist

templates/NOTES.txt ist reiner Text, selbst auf dieselbe Weise templatiert, den Helm nach install oder upgrade ausgibt. Nutze ihn, um demjenigen, der installiert hat, zu sagen, was als Nächstes zu tun ist: ein kubectl port-forward-Befehl, die URL, unter der ein Service erreichbar sein wird, oder ein Schritt beim ersten Start. Er hat keine Wirkung auf den Cluster; er ist rein eine Nachricht an die Person, die den Befehl ausführt.

Woher Charts kommen

Du musst nicht jedes Chart selbst schreiben. Öffentliche Charts für gängige Software, Datenbanken, Monitoring-Stacks, Ingress-Controller, werden auf Artifact Hub veröffentlicht und sind mit einem Befehl installierbar. Der Rest dieser Reihe behandelt zuerst das Schreiben eines eigenen Charts, dann das Finden und Installieren veröffentlichter.