Helm Cheatsheet OMNI52™ GmbH

Helm
auf einem Blatt.

Dichte Referenz für Senior Platform Engineers und SREs zum Kubernetes-Paketmanager, ausgerichtet auf Helm 4. Chart-Anatomie, Templating-Patterns, Values-Schichtung & Secrets, Release-Lifecycle, Hooks, Dependencies, OCI-Registries, Signing und Anti-Patterns. Keine Einsteiger-Folien.

Vorschau (2 Seiten A4 quer + Brand-Rückseite)

Helm Cheatsheet Seite 1: Helm 4 Stand, Chart-Anatomie, Templating-Patterns, Values und Secrets, Release-Lifecycle

Helm Cheatsheet Seite 2: Hooks und Tests, Dependencies, OCI-Registries, Lint und Diff, Provenance und Signing, Anti-Patterns

PDF herunterladen

Direkter Download, keine Mail-Adresse nötig. CC BY-SA 4.0 , kopieren, drucken, weiterverteilen ist ausdrücklich erlaubt, solange die Quellenangabe sichtbar bleibt.

Helm Cheatsheet (PDF, ~100 KB)

Was drin steht

Helm 4 & Migration

Stand Juli 2026: Helm 4.2.x aktuell, Helm-3-EOL-Timeline, Flag-Renames, Post-Renderer als Plugins, SSA-Latching, kstatus-RBAC.

Chart-Anatomie & Templating

Chart.yaml-Kernfelder, values.schema.json, Named Templates in _helpers.tpl, include/required/tpl, Checksum-Trick für Config-Rollouts.

Values & Secrets

Präzedenz-Schichtung (-f, --set-Familie), Subchart-Scoping, global:, helm-secrets/SOPS, External Secrets, CI-Injection.

Release-Lifecycle

upgrade --install, history/rollback, 3-way strategic merge vs. Server-Side Apply, --rollback-on-failure, --wait mit kstatus.

Hooks, Tests & Dependencies

helm.sh/hook-Annotationen, weights, delete-policies, helm test, dependencies mit condition/tags/alias, Chart.lock.

OCI, Validierung & Signing

registry login/push, Digest-Pinning, lint/template/kubeconform, helm-diff, package --sign, Provenance-Verify. Anti-Patterns aus der Praxis.

Cheatsheet im Volltext

Derselbe Inhalt wie im PDF, zum Mitlesen, Durchsuchen und direkten Kopieren der YAML- und CLI-Snippets. Stand: Helm v4.2 (Edition 2026.07).

Helm 4: Stand Juli 2026

Versionen, Support-Fenster

Helm 4 ist die aktuelle Major-Version (4.0.0 im November 2025, aktuell 4.2.x). Charts mit apiVersion: v2 laufen unverändert; bestehende Helm-3-Releases übernimmt Helm 4 ohne Migrationsschritt.

Helm 3 läuft aus: letzter (limitierter) Feature-Release am 09.09.2026 (nur K8s-Client-Updates), Security-Fixes bis 10.02.2027, danach EOL.

Breaking Changes 3 auf 4

--atomic → --rollback-on-failure, --force → --force-replace (alte Flags funktionieren mit Deprecation-Warnung).

--post-renderer nimmt einen Plugin-Namen, kein Executable mehr. helm registry login akzeptiert nur noch Domains, keine URLs.

--wait nutzt kstatus: RBAC braucht zusätzlich das watch-Verb, sonst schlägt Warten sofort fehl.

Neu in Helm 4

Server-Side Apply als Default für neue Releases (Details unter Release-Lifecycle).

Plugin-System neu: optionale WebAssembly-Runtime, Typen CLI / Getter / Post-Renderer; Subprocess-Plugins laufen weiter (deprecated).

Multi-Dokument-Values, Custom-Template-Funktionen via Plugins, Content-basiertes Chart-Caching, schnellere Dependency-Auflösung.

Chart-Anatomie

Verzeichnis-Layout

Chart.yaml (Metadaten, Pflicht) · values.yaml (Defaults) · values.schema.json (optionales JSON-Schema) · templates/ (Manifeste + _helpers.tpl) · charts/ (gevendorte Dependencies) · crds/ (CRDs, siehe Anti-Patterns).

charts/, crds/, templates/ sind für Helm reserviert.

Chart.yaml-Kernfelder

apiVersion: v2, Standard für Helm 3 und 4 (v1 = Helm 2; Charts v3 in Entwicklung auf Basis der stabilen Helm-4-SDK).

version: SemVer des Charts, treibt Paketname, Registry-Tag und Range-Auflösung. appVersion: Version der paketierten App, informativ. type: application oder library (Library-Charts rendern selbst nichts, liefern Template-Bausteine).

apiVersion: v2
name: shop-api
version: 1.4.0        # Chart-SemVer
appVersion: "2.8.1"   # App-Version, informativ
type: application
dependencies:
  - name: postgresql
    version: ">=16.0.0 <17.0.0"
    repository: oci://registry.example.com/charts
    condition: postgresql.enabled

Templating-Patterns

include, required, tpl

include rendert ein Named Template zu einem String, der Output lässt sich pipen (| nindent 4), anders als bei der template-Action.

required bricht das Rendering mit eigener Fehlermeldung ab, wenn der Values-Eintrag leer ist.

tpl evaluiert Strings aus values als Template, für konfigurierbare Templates und .Files.Get-Inhalte.

Named Templates (_helpers.tpl)

define-Namen sind global über Chart + Subcharts, immer mit Chart-Namen prefixen: shop.labels statt labels. Ablage konventionell in templates/_helpers.tpl (Underscore-Dateien rendern kein Manifest).

{{- define "shop.labels" -}}
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion }}
{{- end }}
# Verwendung: Output pipen, nicht 'template'
metadata:
  labels: {{- include "shop.labels" . | nindent 4 }}
host: {{ required "host fehlt!" .Values.host }}
conf: {{ tpl (.Files.Get "conf/app.conf") . }}

Checksum-Trick

ConfigMap-Änderung rollt das Deployment nicht automatisch , Checksum-Annotation im Pod-Template erzwingt den Rollout:

annotations:
  checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

Values-Schichtung & Secrets

Präzedenz

Chart-values.yaml < Parent-Chart-Overrides < -f-Dateien (rechts gewinnt) < --set / --set-string / --set-file / --set-json.

Subchart-Values unter dem Subchart-Namen scopen; global: ist in allen Charts sichtbar. --reset-values verwirft beim Upgrade gemerkte Overrides.

Secrets-Strategien

Nie Klartext-Secrets in values.yaml im Git. Gängige Muster:

helm-secrets-Plugin + SOPS/age: values verschlüsselt im Repo, Entschlüsselung beim Deploy.

External Secrets Operator / Sealed Secrets: Secret-Lifecycle ausserhalb des Charts, Chart referenziert nur den Namen.

CI-Injection: --set-file aus dem Secret-Store der Pipeline, nichts landet im Repo.

helm upgrade --install shop ./shop -n shop \
  -f values.yaml -f values-prod.yaml \
  --set image.tag=2.8.1 \
  --set-file tls.cert=./tls.crt \
  --set-json 'resources={"limits":{"cpu":"1"}}'
helm get values shop -n shop   # gemerkte Overrides

Release-Lifecycle

install, upgrade, rollback

helm upgrade --install ist der idempotente Standardpfad (CI-tauglich). helm history zeigt Revisionen, helm rollback <rel> <rev> setzt zurück (erzeugt neue Revision). helm get manifest|values|notes inspiziert den Ist-Stand. --rollback-on-failure rollt fehlgeschlagene Upgrades automatisch zurück.

3-way merge, Server-Side Apply

Helm 3: Three-Way Strategic Merge Patch aus altem Manifest, Live-State und neuem Manifest, out-of-band-Änderungen bleiben erhalten, soweit nicht im Chart überschrieben.

Helm 4: Server-Side Apply (Field-Ownership beim API-Server) als Default für neue Releases. Upgrades/Rollbacks latchen auf die bisherige Apply-Methode des Releases (--server-side=auto); Umstellung explizit per --server-side=true|false.

helm upgrade --install shop ./shop -n shop \
  --rollback-on-failure --wait --timeout 5m
helm history shop -n shop
helm rollback shop 3 -n shop
helm get manifest shop -n shop --revision 3
helm uninstall shop -n shop --keep-history

Hooks & Tests

Hook-Mechanik

Annotation helm.sh/hook macht ein Template zum Hook: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback, test.

Reihenfolge via helm.sh/hook-weight (String!, aufsteigend). Job/Pod-Hooks blockieren bis Completion, Fehler = Release fehlgeschlagen.

Delete-Policies, Ownership

Hook-Ressourcen gehören nicht zum Release , helm uninstall räumt sie nicht ab. helm.sh/hook-delete-policy: before-hook-creation (Default), hook-succeeded, hook-failed.

apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ .Release.Name }}-db-migrate"
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrate
          image: registry.example.com/shop/migrate:2.8.1

Chart-Tests

Tests sind Hooks mit helm.sh/hook: test, konventionell unter templates/tests/. Nach Deploy ausführen: helm test <release>, der Test-Pod muss erfolgreich terminieren (Smoke-Test gegen den Service).

Dependencies

dependencies-Feld

Subcharts deklarativ in Chart.yaml; helm dependency update löst Ranges auf, lädt .tgz nach charts/ und schreibt Chart.lock (dependency build baut reproduzierbar aus dem Lock).

condition (z.B. redis.enabled) schaltet Subcharts, tags bündeln mehrere, alias instanziiert dasselbe Chart mehrfach.

dependencies:
  - name: redis
    version: "21.x.x"
    repository: oci://registry.example.com/charts
    condition: redis.enabled
  - name: postgresql
    version: ">=16.0.0 <17.0.0"
    repository: "@internal"   # Alias aus 'helm repo add'
    tags: [datastores]

helm repo add internal https://charts.example.com
helm dependency update ./shop   # Ranges -> Chart.lock
helm dependency build ./shop    # exakt aus Chart.lock

OCI-Registries

Chart als OCI-Artefakt

helm push lädt das gepackte Chart in eine OCI-Registry, Referenz mit oci://-Prefix, ohne Chart-Namen und Tag (kommen aus Chart.yaml). pull, install, upgrade, show, template akzeptieren oci:// + --version; Pinning per Digest @sha256:.... Login in Helm 4 nur mit Domain.

helm registry login registry.example.com
helm package ./shop   # -> shop-1.4.0.tgz
helm push shop-1.4.0.tgz oci://registry.example.com/charts
helm install shop \
  oci://registry.example.com/charts/shop --version 1.4.0
# immutable per Digest:
helm install shop \
  oci://registry.example.com/charts/shop@sha256:<digest>

Lint, Template & Diff

Validierungs-Pipeline

helm lint --strict: statische Chart-Prüfung. helm template: Offline-Rendering, in CI gegen Schema-Validatoren wie kubeconform pipen.

helm install --dry-run=server: rendert mit Cluster-Zugriff (lookup funktioniert), ohne zu installieren. helm diff upgrade (Plugin): zeigt den Manifest-Diff gegen den Live-Stand vor dem Upgrade.

helm lint ./shop --strict
helm template shop ./shop -f values-prod.yaml \
  | kubeconform -strict -summary
helm install shop ./shop --dry-run=server
helm plugin install \
  https://github.com/databus23/helm-diff
helm diff upgrade shop ./shop -f values-prod.yaml

Provenance & Signing

Signieren, Verifizieren

helm package --sign erzeugt neben dem .tgz eine Provenance-Datei .tgz.prov (PGP-signiert; Keyring im binären GnuPG-Format, kein kbx).

Prüfung: helm verify chart.tgz bzw. Installation mit --verify, die .prov muss neben dem Chart abrufbar sein.

helm package --sign --key 'release@example.com' \
  --keyring ~/.gnupg/secring.gpg ./shop
helm verify shop-1.4.0.tgz
helm install shop shop-1.4.0.tgz --verify \
  --keyring pubring.gpg

Anti-Patterns

Was du nicht tun solltest

Chart-Version wiederverwenden: gleiche version neu pushen bricht Caches und SemVer-basierte GitOps-Ranges, pro Änderung bumpen.

Klartext-Secrets in values.yaml im Git: SOPS/helm-secrets, External Secrets oder CI-Injection nutzen.

kubectl edit am Release vorbei: 3-way merge/SSA begrenzen den Schaden, Ownership-Konflikte bleiben , Änderungen über values fahren.

CRDs als Templates: crds/ wird nur bei der Installation angelegt, nie geupgradet oder gelöscht, CRD-Lifecycle separat managen.

App-Logik in Hooks: Hook-Ressourcen gehören nicht zum Release, kein Cleanup bei uninstall, delete-policy setzen, Jobs idempotent bauen.

Upgrade ohne Diff/Dry-Run in Prod: helm diff bzw. --dry-run=server gehören vor jedes produktive Upgrade.

--wait ohne watch-RBAC (Helm 4): kstatus braucht watch, sonst bricht jede Wait-Operation ab.

Aus der OMNI52 Cheatsheet-Fabrik

Verwandte Sheets in dichter Senior-Qualität:
kubernetes-cheatsheet.de, Kubernetes Core
flux-cheatsheet.de, GitOps mit Flux
argocd-cheatsheet.de, GitOps mit Argo CD
kubectl-cheatsheet.de, kubectl Power-Usage

Lizenz & Weiterverteilung

CC BY-SA 4.0. Du darfst dieses Cheatsheet kopieren, weiterverteilen, ausdrucken und in eigenen Materialien zitieren. Bedingung: Quellenangabe „Helm Cheatsheet, OMNI52 GmbH, helm-cheatsheet.de“ bleibt sichtbar, und abgeleitete Werke stehen unter der gleichen Lizenz (Share-Alike).

Nicht erlaubt: Logo, Marken oder den Eindruck zu vermitteln, dass der Inhalt von dir/euch stammt oder dass OMNI52 GmbH die Weiterverwendung sponsort.

Volltext der Lizenz: creativecommons.org/licenses/by-sa/4.0/deed.de.

Helm and Kubernetes are registered trademarks of The Linux Foundation in the United States and other countries. Helm is a Cloud Native Computing Foundation (CNCF) graduated project. OMNI52™ is a trademark of OMNI52 GmbH (filed, not yet registered). This website is operated by OMNI52 GmbH and is not affiliated with, endorsed by, or sponsored by The Linux Foundation or the CNCF. “Helm” is used in a nominative / descriptive sense to indicate the technology this cheatsheet documents.

Helmauf einem Blatt.

Vorschau (2 Seiten A4 quer + Brand-Rückseite)

PDF herunterladen

Was drin steht

Helm 4 & Migration

Chart-Anatomie & Templating

Values & Secrets

Release-Lifecycle

Hooks, Tests & Dependencies

OCI, Validierung & Signing

Cheatsheet im Volltext

Helm 4: Stand Juli 2026

Versionen, Support-Fenster

Breaking Changes 3 auf 4

Neu in Helm 4

Chart-Anatomie

Verzeichnis-Layout

Chart.yaml-Kernfelder

Templating-Patterns

include, required, tpl

Named Templates (_helpers.tpl)

Checksum-Trick

Values-Schichtung & Secrets

Präzedenz

Secrets-Strategien

Release-Lifecycle

install, upgrade, rollback

3-way merge, Server-Side Apply

Hooks & Tests

Hook-Mechanik

Delete-Policies, Ownership

Chart-Tests

Dependencies

dependencies-Feld

OCI-Registries

Chart als OCI-Artefakt

Lint, Template & Diff

Validierungs-Pipeline

Provenance & Signing

Signieren, Verifizieren

Anti-Patterns

Was du nicht tun solltest

Aus der OMNI52 Cheatsheet-Fabrik

Lizenz & Weiterverteilung

Helm
auf einem Blatt.