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: Bei
SSA-Releases bricht danach jedes Upgrade mit Field-Conflict ab,
solange der Chart für das editierte Feld einen anderen Wert
setzt; --force-conflicts holt die Felder
zurück. Änderungen über values fahren.
CRDs in templates/: helm uninstall
löscht die CRD und mit ihr alle Custom Resources dieses Typs,
Schutz: helm.sh/resource-policy: keep.
CRDs in crds/ werden nur bei der Installation
angelegt, nie geupgradet
oder gelöscht, CRD-Lifecycle separat managen. Ohne
--wait (Default hookOnly) wartet Helm 4
erst ab 4.3.1, bis diese CRDs etabliert sind; vorher scheitern
Custom Resources im selben Release sporadisch an no matches
for kind.
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.
Fehlende watch-RBAC (Helm 4): Auch ohne
--wait (Default hookOnly) beobachtet Helm
Hook-Ressourcen per kstatus-Informer im Namespace der
Hook-Ressourcen. Fehlen
list und watch für deren Typen,
scheitern Hooks und jede Wait-Operation, auch die implizite von
--rollback-on-failure.