Der schnellste Weg, Helm-Templating zu lernen, ist, Manifeste, die du schon verstehst, Feld für Feld zu templatisieren. Diese Anleitung beginnt mit einem einfachen Deployment, Service und einer ConfigMap, erzeugt ein Chart-Gerüst und ersetzt die Felder, die variieren sollen, durch Values.

Ein Chart-Gerüst erzeugen und das Beispiel ausräumen

helm create webapp
cd webapp
rm -rf templates/tests templates/hpa.yaml templates/ingress.yaml \
       templates/serviceaccount.yaml templates/_helpers.tpl

Die erzeugten templates/deployment.yaml und templates/service.yaml sind ein funktionierendes Beispiel, aber zum Lernen ist es klarer, deine eigenen von Grund auf zu schreiben. Entferne ihre Inhalte (lass die Dateien) und leere values.yaml:

: > values.yaml

Deine eigenen Manifeste hinzufügen

Schreibe zuerst reines Kubernetes-YAML, genau so, wie du es ohne Helm tun würdest:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
  labels:
    app: my-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-webapp
  template:
    metadata:
      labels:
        app: my-webapp
    spec:
      containers:
        - name: my-webapp
          image: myorg/webapp:1.0
          envFrom:
            - configMapRef:
                name: my-webapp-config
          ports:
            - containerPort: 8080

# templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-webapp
spec:
  selector:
    app: my-webapp
  ports:
    - port: 80
      targetPort: 8080

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-webapp-config
data:
  CUSTOM_HEADER: "this app was deployed with Helm"

Beachte, dass derselbe String, my-webapp, über Name, Label, Selector und ConfigMap-Referenz hinweg wiederholt wird. Genau diese Wiederholung macht von Hand gepflegte Multi-Umgebungs-Manifeste fehleranfällig: Benennst du die App einmal um, hast du vier Stellen zu erwischen.

Die wiederholten Werte durch einen Template-Wert ersetzen

Führe einen Wert ein und referenziere ihn überall dort, wo der Name vorkommt:

# values.yaml
appName: my-webapp

# templates/deployment.yaml (Auszug)
metadata:
  name: {{ .Values.appName }}
  labels:
    app: {{ .Values.appName }}
spec:
  selector:
    matchLabels:
      app: {{ .Values.appName }}
  template:
    metadata:
      labels:
        app: {{ .Values.appName }}
    spec:
      containers:
        - name: {{ .Values.appName }}
          envFrom:
            - configMapRef:
                name: {{ .Values.appName }}-config

Mache dasselbe in service.yaml und configmap.yaml überall dort, wo my-webapp vorkommt. .Values wird aus values.yaml befüllt, sodass eine einzige Änderung dort nun jede Ressource konsistent umbenennt.

Das Image und die Daten der ConfigMap templatisieren

Teile das Image in eigene Values, damit sich der Tag unabhängig vom Repository ändern kann:

# values.yaml (hinzufügen)
image:
  repository: myorg/webapp
  tag: "1.0"

        - name: {{ .Values.appName }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Und den Inhalt der ConfigMap:

# values.yaml (hinzufügen)
config:
  customHeader: "this app was deployed with Helm"

# templates/configmap.yaml
data:
  CUSTOM_HEADER: {{ .Values.config.customHeader | quote }}

Der Filter | quote umschließt den Wert mit doppelten Anführungszeichen, was wichtig wird, sobald umgebungsspezifische Werte Leerzeichen oder Sonderzeichen enthalten. Eine gute Regel für die Benennung deiner Values: Spiegle die eigene Struktur des Manifests (config.customHeader entspricht data.CUSTOM_HEADER einer ConfigMap), damit jeder, der das Template liest, erraten kann, woher ein Wert kommt.

Vor der Installation eine Vorschau

Zwei Befehle rendern das Chart, ohne einen Cluster anzufassen:

helm template ./webapp
helm install my-webapp ./webapp --dry-run --debug

helm template rendert lokal und braucht überhaupt keinen Cluster. --dry-run --debug bei install validiert zusätzlich gegen die API des Clusters, ohne etwas zu persistieren. Führe nach jeder Template-Änderung einen davon aus; ein Tippfehler in {{ .Values.appname }} (falsche Groß-/Kleinschreibung) rendert stillschweigend als leer statt mit Fehler, und das ist der schnellste Weg, ihn zu fangen.

Installieren und bestätigen

helm install my-webapp ./webapp
kubectl get all -l app=my-webapp

my-webapp ist hier der Release-Name, und ./webapp ist das Chart-Verzeichnis. Nichts daran, ein handgeschriebenes Chart zu installieren, unterscheidet sich vom Installieren eines veröffentlichten.

Einen Wert ändern und upgraden

Bearbeite values.yaml (erhöhe image.tag, ändere config.customHeader, was auch immer du testest) und wende die Änderung an:

helm upgrade my-webapp ./webapp
helm list

helm list zeigt nun Revision 2. Jedes upgrade wendet das gesamte Chart mit den aktuellen Values erneut an, so deployst du also auch täglich eine neue Version.

Eine NOTES.txt hinzufügen

# templates/NOTES.txt
Your release "{{ .Release.Name }}" has been deployed.

To access {{ .Values.appName }}, run:
  kubectl port-forward svc/{{ .Values.appName }} 8080:80

.Release.Name ist ein eingebauter Wert, den Helm immer bereitstellt, neben .Chart und .Release.Namespace; du setzt ihn nicht selbst. Führe helm upgrade my-webapp ./webapp erneut aus, und dieser Text wird im Terminal ausgegeben, mit dem bereits ausgefüllten Port-Forward-Befehl für jeden, der zusieht.