Helm: Kubernetes-Anwendungen als Charts paketieren

Helm ist der Paketmanager für Kubernetes. Es bündelt eine Gruppe zusammengehöriger Manifeste zu einem Chart, das sich mit Parametern installieren, aktualisieren und wieder entfernen lässt. Ohne Helm müsste man für jede Anwendung ein Dutzend YAML-Dateien von Hand pflegen und bei jeder Änderung synchron halten.

Aufbau eines Charts

mein-chart/
├── Chart.yaml          # Name, Version, appVersion, Abhängigkeiten
├── values.yaml         # Standardwerte
├── templates/          # Vorlagen (Go-Template + Sprig-Funktionen)
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── _helpers.tpl    # wiederverwendbare Template-Fragmente
├── charts/             # eingebettete Unter-Charts
└── crds/               # CustomResourceDefinitions

Die Vorlagen sind Go-Templates. Werte aus values.yaml werden über .Values eingesetzt, Objekte des Releases über .Release (Name, Namespace, Revision), das Chart selbst über .Chart:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "mein-chart.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Release, Revision und Rollback

Jede Installation heißt Release und hat einen Namen und eine laufende Revision. Helm speichert den Zustand als Secret im Namespace. Das hat einen angenehmen Nebeneffekt: helm rollback setzt ein Release auf eine frühere Revision zurück, ohne dass man Manifeste von Hand zurückschreiben muss. Auch helm diff und helm history machen Änderungen nachvollziehbar.

Hooks und Reihenfolge

Manche Dinge müssen vor oder nach einem Update passieren: Datenbankmigration, Zertifikatserzeugung, Cache-Leerung. Dafür gibt es Hooks, gesteuert über Annotationen:

  • pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, test
  • helm.sh/hook-delete-policy steuert, ob die erzeugten Objekte danach entfernt werden
  • helm.sh/hook-weight legt die Reihenfolge mehrerer Hooks fest

Ein test-Hook wird mit helm test ausgeführt – ein einfaches Mittel, um nach der Installation zu prüfen, ob ein Dienst antwortet.

Wichtige Befehle

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo nginx

# Installation mit eigenen Werten
helm install web ./mein-chart -f prod-values.yaml --namespace web --create-namespace

# Vorschau, was sich ändern würde (Plugin)
helm diff upgrade web ./mein-chart -f prod-values.yaml

# Vorlagen rendern, ohne zu installieren
helm template web ./mein-chart -f prod-values.yaml

# Status und Verlauf
helm list -A ; helm history web -n web

# Aktualisieren und zurückrollen
helm upgrade --install web ./mein-chart -f prod-values.yaml -n web
helm rollback web 3 -n web

# Entfernen
helm uninstall web -n web

Fallstricke

  • Werte liegen nicht in Git: Wenn prod-values.yaml nur lokal existiert, ist die Installation nicht reproduzierbar. Werte gehören ins Repository – aber ohne Geheimnisse; dafür externe Secret-Speicher oder verschlüsselte Dateien nutzen.
  • Helm-Template-Syntax in Manifesten: Ein {{ in einer Rohdatei (etwa eine Prometheus-Regel) wird als Template ausgewertet und bricht den Build. Lösung: {{ "{{" }} als Escape oder die Datei in files/ ablegen und mit .Files.Get einbinden.
  • Zustandsänderungen sind nicht rückrollbar: helm rollback stellt Manifeste wieder her, aber keine Daten. Eine Datenbankmigration braucht weiterhin eine eigene Vorwärtsstrategie.
  • Unterschied zwischen Upgraden und Ersetzen: Ein helm upgrade verändert bestehende Objekte; nicht jede Änderung erlaubt Kubernetes, etwa unveränderliche Felder in einem StatefulSet. Dann hilft nur Löschen und Neuinstallieren.

Verwandte Grundlagen: Kubernetes, Kustomize, Argo CD, GitOps.