DevOps 8 Min Lesezeit

Kubernetes Helm Charts 2026 – Praxis-Guide für Einsteiger

Was sind Helm Charts – und warum 2026 noch relevant?

Helm ist der Paketmanager für Kubernetes und seit 2020 ein „Graduated Project" der CNCF. Statt für jede Anwendung dutzende einzelne YAML-Manifeste manuell zu pflegen, bündelt ein Chart alle Ressourcen – Deployment, Service, Ingress, ConfigMap, ServiceAccount – in einer versionierten, parametrisierbaren Einheit. 2026 ist das wichtiger denn je: Ein durchschnittliches Production-Deployment einer Web-App umfasst heute 8 bis 15 Kubernetes-Objekte, die alle konsistent aktualisiert, gerollt und zurückgerollt werden müssen.

Der praktische Nutzen zeigt sich sofort: Ein einziger Befehl installiert eine komplette Anwendung inklusive aller Abhängigkeiten. helm install ingress-nginx ingress-nginx/ingress-nginx ersetzt rund 900 Zeilen YAML. Helm merkt sich jedes Release, sodass du mit helm rollback innerhalb von Sekunden auf den vorherigen Stand zurückgehst – ohne manuelles Zusammenkopieren alter Manifeste.

Artifact Hub listet Anfang 2026 über 16.000 öffentliche Charts. Für Standardkomponenten wie cert-manager, Prometheus oder PostgreSQL schreibt kaum noch jemand eigene Manifeste. Die aktuelle Helm-Version ist 3.17 (Long-Term-Support-Zweig), während Helm 4.x seit Ende 2025 als stabile Major-Version verfügbar ist und unter anderem serverseitiges Apply und verbessertes OCI-Handling mitbringt.

Wer heute ein Kubernetes-Cluster betreibt und noch rohe YAML-Dateien mit kubectl apply -f ausrollt, verliert Zeit und Übersicht. Dieser Guide zeigt dir den kompletten Einstieg – von der Installation bis zum GitOps-Workflow mit ArgoCD.

Helm installieren: Setup unter Ubuntu 24.04 und macOS

Die Installation dauert unter zwei Minuten. Auf Debian/Ubuntu 24.04 LTS nutzt du das offizielle APT-Repository, damit du später mit apt upgrade aktualisieren kannst:

curl -fsSL https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt update && sudo apt install helm -y

Alternativ geht das offizielle Skript, das immer die neueste Version zieht:

curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
helm version --short
# v3.17.3+g4b5f4e1

Prüfe danach, dass dein kubectl-Kontext auf das richtige Cluster zeigt. Helm nutzt exakt dieselbe kubeconfig wie kubectl – ein häufiger Anfängerfehler ist das versehentliche Deployen in ein falsches Cluster:

kubectl config current-context
kubectl get nodes
helm env | grep KUBECONFIG

Für produktives Arbeiten lohnt sich die Shell-Autovervollständigung. Bei Bash: helm completion bash | sudo tee /etc/bash_completion.d/helm. Bei Zsh: helm completion zsh > "${fpath[1]}/_helm". Damit sparst du bei langen Release-Namen und Chart-Repositories viel Tipparbeit.

Die Anatomie eines Helm Charts

Ein Chart ist im Kern ein Verzeichnis mit einer festen Struktur. helm create myapp erzeugt dir ein vollständiges Skelett mit Best Practices, das du direkt als Vorlage nutzen kannst:

PfadZweck
Chart.yamlMetadaten: Name, Version, appVersion, Dependencies
values.yamlStandardwerte, die Nutzer überschreiben können
templates/Go-Templates, die zu Kubernetes-Manifesten rendern
templates/NOTES.txtAusgabe nach erfolgreicher Installation
charts/Eingebettete Subcharts (Abhängigkeiten)
.helmignoreDateien, die nicht ins Paket gehören (wie .gitignore)

Die Templates sind Go-Templates mit den zusätzlichen Sprig-Funktionen. Das bedeutet: Bedingungen (if), Schleifen (range), String-Manipulation und Defaults sind möglich. Ein typisches Muster sieht so aus:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

Wichtig zu verstehen: .Values greift auf values.yaml zu, .Chart auf die Chart.yaml, und .Release enthält Laufzeitinfos wie .Release.Name oder .Release.Namespace. Diese Trennung macht Charts wiederverwendbar – dasselbe Chart läuft in Dev, Staging und Prod mit unterschiedlichen Werten.

Erstes Chart installieren und inspizieren

Bevor du irgendetwas in den Cluster schreibst, renderst du das Ergebnis lokal. Das ist der wichtigste Debug-Befehl überhaupt:

helm create myapp
helm template myapp ./myapp --namespace demo
helm template myapp ./myapp --namespace demo --debug

helm template verbindet sich nicht mit dem Cluster (außer bei lookup-Funktionen) und zeigt dir das fertige YAML. So findest du Template-Fehler, bevor sie im Cluster landen. Anschließend installierst du mit einem Dry-Run, der serverseitig validiert:

helm install myapp ./myapp --namespace demo --create-namespace --dry-run=server

Wenn alles passt, folgt die echte Installation. Nutze --wait, damit Helm auf die Readiness der Pods wartet, und --timeout, damit der Befehl nicht ewig hängt:

helm install myapp ./myapp --namespace demo --create-namespace --wait --timeout 5m
helm list -n demo
helm status myapp -n demo
helm get manifest myapp -n demo

Mit helm get manifest siehst du exakt, was Helm ins Cluster geschrieben hat – inklusive aller gerenderten Werte. Das ist Gold wert, wenn ein Deployment unerwartet aussieht.

Values überschreiben: Dev, Staging und Prod sauber trennen

Das Herzstück der Wiederverwendbarkeit sind Values-Overrides. Helm wendet sie in einer festen Prioritätsreihenfolge an – von niedrig nach hoch:

  1. values.yaml im Chart (Standardwerte)
  2. Values eines Parent-Charts (bei Subcharts)
  3. Dateien via -f myvalues.yaml (mehrere möglich, spätere gewinnen)
  4. Einzelwerte via --set key=value

In der Praxis legst du pro Umgebung eine Datei an:

# values-prod.yaml
replicaCount: 6
image:
  repository: registry.hostazar.com/myapp
  tag: "2.4.1"
resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: "2"
    memory: 2Gi
ingress:
  enabled: true
  hosts:
    - host: app.example.com

Deployment für Prod: helm upgrade --install myapp ./myapp -n prod -f values-prod.yaml --wait --atomic. Das Flag --atomic ist entscheidend: Schlägt das Upgrade fehl, rollt Helm automatisch auf die vorherige Revision zurück. Ohne dieses Flag bleibt ein halbfertiges Deployment stehen.

Für kleine Änderungen eignet sich --set, etwa --set image.tag=2.4.2. Achte aber auf die Fallstricke: Punkte erzeugen verschachtelte Keys, Kommas trennen mehrere Werte. Bei Sonderzeichen nutze --set-string oder besser gleich eine Values-Datei. Für automatisierte Pipelines ist -f immer die robustere Wahl.

Repositories und die wichtigsten Charts 2026

Öffentliche Charts beziehst du über Repositories. Die drei wichtigsten für den Einstieg:

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo add jetstack https://charts.jetstack.io
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
ChartZweckTypische Version 2026
ingress-nginxHTTP/HTTPS-Ingress-Controller4.12.x
cert-managerAutomatische Let's-Encrypt-Zertifikate1.17.x
kube-prometheus-stackMonitoring mit Prometheus + Grafana68.x
external-secretsSecrets aus Vault/AWS SM synchronisieren0.14.x

Ein produktionsreifes cert-manager-Setup sieht so aus:

helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --version v1.17.2 \
  --set crds.enabled=true \
  --wait

Wichtig: Pinne immer die Chart-Version mit --version. Ohne diese Angabe zieht Helm die neueste Version, was in CI/CD-Pipelines zu unerwarteten Breaking Changes führt. Bei kube-prometheus-stack ändern sich zwischen Major-Versionen regelmäßig Label-Schemata – ein ungeplanter Sprung kann deine Alerting-Regeln lahmlegen.

GitOps mit ArgoCD und Flux

2026 ist der deklarative GitOps-Ansatz Standard. Statt Helm manuell in der Pipeline auszuführen, speicherst du die Chart-Referenz plus Values im Git-Repository, und ein Controller synchronisiert den Cluster. ArgoCD rendert Helm-Charts serverseitig über eine Application-Ressource:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/hostazar/k8s-manifests
    targetRevision: main
    path: charts/myapp
    helm:
      valueFiles:
        - values-prod.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Der Vorteil: selfHeal: true erkennt manuelle Änderungen im Cluster und macht sie rückgängig. Dein Git-Repository ist damit die einzige Wahrheit. ArgoCD zeigt dir in der UI den Diff zwischen Soll- und Ist-Zustand.

Flux geht einen ähnlichen Weg, arbeitet aber mit HelmRelease-Custom-Resources und ist stärker CLI-orientiert. Beide Systeme unterstützen Helm-Charts nativ, inklusive helm template-Rendering und Drift-Detection. Für Teams, die gerade erst starten, ist ArgoCD wegen der grafischen Oberfläche der schnellere Einstieg.

Secrets sicher verwalten

Ein häufiger Anfängerfehler: Klartext-Passwörter in values.yaml und dann ins Git pushen. Nutze stattdessen einen der drei etablierten Wege:

Für den Einstieg ist SOPS mit age-Keys am einfachsten. Ein Schlüsselpaar erzeugst du in Sekunden: age-keygen -o key.txt. Den öffentlichen Key trägst du in .sops.yaml ein, danach verschlüsselt SOPS automatisch nur die als secret markierten Werte. Wichtig: Den privaten Key niemals ins Repository – der gehört in einen CI-Secret-Store oder in den Cluster als Kubernetes-Secret.

Linting, Testing und CI-Integration

Vor jedem Commit gehört ein Lint-Durchlauf. helm lint ./myapp prüft Chart.yaml, Template-Syntax und Values-Konsistenz. Für tiefere Validierung gegen echte Kubernetes-Schemas nutzt du kubeconform:

helm template myapp ./myapp | kubeconform -strict -summary
helm unittest ./myapp
helm dependency update ./myapp

Das Plugin helm-unittest erlaubt echte Unit-Tests auf gerenderte Manifeste. Du prüfst damit zum Beispiel, dass bei ingress.enabled: false wirklich kein Ingress-Objekt entsteht. In einer GitHub-Actions-Pipeline sieht der Ablauf typischerweise so aus:

- name: Helm Lint
  run: helm lint ./charts/myapp
- name: Render & Validate
  run: helm template myapp ./charts/myapp | kubeconform -strict
- name: Package
  run: helm package ./charts/myapp --destination ./dist

Für Chart-Tests über mehrere Kubernetes-Versionen hinweg ist chart-testing (ct) das Werkzeug der Wahl. Es erstellt temporäre Kind-Cluster und installiert dein Chart real. Das dauert in CI etwa 3 bis 5 Minuten, fängt aber Fehler ab, die reines Template-Rendering nicht sieht – etwa fehlende RBAC-Rechte oder nicht existierende StorageClasses.

Upgrades, Rollbacks und Hooks

Helm speichert jede Revision als Kubernetes-Secret im Namespace. Standardmäßig werden 10 Revisionen aufbewahrt, konfigurierbar über --history-max. Ein Upgrade mit vollem Sicherheitsnetz:

helm upgrade myapp ./myapp -n prod -f values-prod.yaml \
  --atomic --wait --timeout 10m --history-max 20

Bei Problemen hilft die Historie:

helm history myapp -n prod
helm rollback myapp 3 -n prod --wait
helm get values myapp -n prod --revision 3

Hooks erlauben dir, Aktionen an Lebenszyklus-Events zu binden. Ein pre-upgrade-Hook führt beispielsweise eine Datenbankmigration aus, bevor die neuen Pods starten. Wichtig: Hooks brauchen helm.sh/hook-delete-policy, sonst bleiben die Job-Objekte liegen und blockieren spätere Läufe. Typische Policies sind before-hook-creation und hook-succeeded.

Ein Detail, das viele übersehen: helm upgrade führt ein Drei-Wege-Merge durch (altes Manifest, neues Manifest, Live-Zustand). Das verhindert, dass Helm manuell gesetzte Felder wie replicas durch einen HPA überschreibt. Genau deshalb ist Helm bei Rolling Updates deutlich robuster als reines kubectl apply.

Kosten und Hosting-Optionen für Kubernetes 2026

Helm selbst ist kostenlos (Apache-2.0). Die Kosten entstehen durch das Cluster. Ein Vergleich typischer Optionen:

AnbieterModellKosten/Monat
Hetzner Cloud + k3sSelf-managed, 3× CX22ca. 12 €
DigitalOcean DOKSManaged, 3 Nodes (2 vCPU/4 GB)ca. 72 $
Hetzner + Managed k8sControl Plane gratis, Worker ab 4 €ab 12 €
AWS EKSControl Plane 0,10 $/h + Nodesab 73 $ + Compute
Google GKE AutopilotPay-per-Podab 30 $

Für Einsteiger und kleine Teams ist ein selbstgebautes k3s-Cluster auf drei Hetzner-CX22-Instanzen die günstigste Variante. k3s bringt einen funktionierenden Ingress-Controller (Traefik) und Local-Path-Provisioner mit, sodass Helm-Charts sofort laufen. Für Produktion mit SLA ist ein Managed-Angebot wie DOKS oder GKE sinnvoller – dort kümmert sich der Anbieter um Control-Plane-Upgrades und etcd-Backups.

Rechne zusätzlich mit Kosten für Container-Registry (GitHub Container Registry ist für öffentliche Images gratis, privat ab 0,25 $/GB), Load-Balancer (bei Hetzner ca. 6 €/Monat) und Backups. Ein realistisches Produktions-Setup mit Monitoring, Ingress, cert-manager und 3 Nodes liegt 2026 bei etwa 40 bis 90 € monatlich.

Best Practices für Helm im Jahr 2026

Nach einigen Jahren Helm-Erfahrung haben sich klare Regeln etabliert, die dir viel Schmerz ersparen:

Ein weiterer Tipp: Halte Charts klein und fokussiert. Ein „Monster-Chart", das Datenbank, App und Monitoring in einem installiert, wird schnell unwartbar. Besser ist die Komposition über Subcharts oder – in GitOps-Setups – mehrere unabhängige Releases, die du getrennt versionieren kannst.

Und schließlich: Dokumentiere deine Values. Eine kommentierte values.yaml mit Beispielwerten ist für Nutzer wertvoller als jede externe Doku. Tools wie helm-docs generieren daraus automatisch eine Markdown-Referenz für dein Repository.

FAQ

Was ist der Unterschied zwischen Helm und kubectl?

kubectl wendet einzelne Manifeste an und kennt keinen Revisionsverlauf. Helm bündelt mehrere Ressourcen zu einem Release, speichert jede Revision und ermöglicht Rollbacks mit einem Befehl. Für einzelne Debug-Objekte bleibt kubectl sinnvoll, für Anwendungs-Deployments ist Helm die bessere Wahl.

Kann ich Helm Charts ohne Internetzugang nutzen?

Ja. Lade die Charts mit helm pull herunter und hoste sie in einer eigenen OCI-Registry oder einem internen ChartMuseum. In Air-Gapped-Umgebungen ist das der Standardweg. Denke daran, auch die Container-Images in eine interne Registry zu spiegeln.

Wie gehe ich mit Breaking Changes bei fremden Charts um?

Lies vor jedem Major-Upgrade die Release Notes und teste in einer Staging-Umgebung. Nutze helm diff upgrade (Plugin), um vorab zu sehen, welche Ressourcen sich ändern. So erkennst du kritische Änderungen wie gelöschte CRDs oder umbenannte Labels.

Helm 3 oder Helm 4 – was soll ich 2026 verwenden?

Für neue Projekte ist Helm 4 die richtige Wahl: serverseitiges Apply, bessere OCI-Unterstützung und schnellere Installationen. Bestehende Setups auf Helm 3.17 laufen weiterhin stabil und können schrittweise migrieren, da die Chart-Syntax kompatibel bleibt.

Wie viele Revisionen sollte ich aufbewahren?

Für Produktion sind 20 bis 30 Revisionen ein guter Wert – das deckt mehrere Wochen Deployment-Historie ab. Jede Revision liegt als Secret im Namespace und belegt nur wenige Kilobyte. Bei sehr häufigen Deployments (mehr als 20 pro Tag) reduziere auf 10, um die etcd-Last gering zu halten.

📖 Ähnliche Artikel