Helm upgrade with --reuse-values ignores updated chart defaults

The direct answer

Stop using --reuse-values for routine upgrades. Keep your intentional overrides in a version-controlled values file (for example prod-overrides.yaml) and upgrade with helm upgrade -f prod-overrides.yaml instead. With that pattern, new chart defaults from the updated values.yaml apply automatically, while every value you deliberately chose stays pinned because it is explicitly supplied at upgrade time.

Why --reuse-values behaves this way

Confirmed behavior in Helm 3: --reuse-values takes the last release's stored values and merges only the new --set/-f overrides on top. The new chart's values.yaml is not re-evaluated, so any default the maintainer changed between chart versions is silently skipped — the old default is baked into the release and persists indefinitely. This is documented, stable behavior, but verify flag semantics against your installed version with helm upgrade --help.

Diffing before you upgrade

Helm has no single built-in command that diffs previous computed values against new chart defaults. The practical mechanism is a short script combining three commands:

# What is actually in effect now (user values + old chart defaults)
helm get values myrelease -n myns --all > current-effective.yaml

# Defaults in the old and new chart versions
helm show values repo/mychart --version 1.4.0 > defaults-old.yaml
helm show values repo/mychart --version 1.5.0 > defaults-new.yaml

diff defaults-old.yaml defaults-new.yaml

Any key that changed in the chart defaults but does not appear in your committed override file is a default you will silently adopt (good) or silently keep stale (if you used --reuse-values). Note that helm get values without --all shows only user-supplied values, which is misleading when auditing effective state.

To preview the rendered result before applying:

helm upgrade myrelease repo/mychart --version 1.5.0 \
  -n myns -f prod-overrides.yaml --dry-run --debug

Drift detection in a pipeline

A practical CI check on every chart version bump:

1. Diff helm show values between the deployed chart version and the target version.
2. For each changed key, check whether it exists in your committed override file.
3. If a changed default is unpinned, fail the pipeline or post an annotation requiring a human decision: adopt the new default, or pin the old one explicitly in the override file.

Storing helm get values --all output per release alongside the override file gives you an audit trail of what was actually computed at each deploy.

Caveats

Diffing values.yaml shows default changes but not template logic changes — a value may be overridden conditionally in templates, so a --dry-run render diff is the stronger verification. --reset-values is the opposite extreme: it discards all prior release values and uses only new chart defaults plus current flags. It is safe only when your overrides are fully captured in files passed at upgrade time — which is exactly the pattern recommended above.