Helm Operations Manual

Helm tracks releases; Kubernetes runs resources. Record cluster, namespace, release, chart version and values sources before explaining a successful upgrade with unexpected behavior. Examples use a reviewed local ./chart.

Task	Start here
Inspect the installed release	Versions and values
Deploy changed values	Render before deployment
Failed upgrade or rollback	History and recovery scope

Distinguish four configuration views

Fix the version and release scope

# Check the local Helm major version
helm version --short

Below, your-context/default/web mean context/namespace/release, explicitly specified in each command. Check contexts with kubectl config get-contexts. A chart name is not a release name.

# List releases including failed and pending states
helm list --kube-context your-context -n default --all

Read NAME, REVISION, STATUS, CHART, and APP VERSION; chart and application versions differ.

# Read this release’s status and notes
helm status web --kube-context your-context -n default

Deployed is a release status, not proof of Pod or business health. For pending, check ongoing release operations first.

Choose a configuration view for the question

# Read defaults from this chart package
helm show values ./chart

./chart is the candidate local chart, not the release’s effective configuration.

# Read stored user overrides
helm get values web --kube-context your-context -n default

Empty output can mean no user overrides; choose --all below for computed values.

# Read computed values after merging defaults and overrides
helm get values web --all --kube-context your-context -n default

Check final fields. These are release values, not controller memory state; inspect output before sharing sensitive configuration.

# Read the manifest stored with the release
helm get manifest web --kube-context your-context -n default

Compare with the actual API object, for example kubectl get deployment web -o yaml with the same scope. Defaults, controllers, or manual edits can change it. Obtain actual resource names from the manifest.

Source	Question answered
helm show values ./chart	Chart defaults
helm get values RELEASE	Stored overrides; --all shows computed values
helm get manifest RELEASE	Manifest stored for that revision
kubectl get ... -o yaml	Live API object after defaulting/controllers/manual edits

Values precedence and rollout verification

Preparing the visual

Choose the values source for this release

This workflow uses chart defaults plus this values.yaml with explicit --reset-values. If old values are needed, export/review and include them intentionally. Version the chart and non-secret values; use project secret handling for sensitive inputs.

# Lint the chart with the proposed values
helm lint ./chart -f values.yaml

Resolve template/structure errors first. Lint does not prove cluster acceptance or application startup.

# Save the candidate rendered manifest for review
helm template web ./chart -n default -f values.yaml > rendered.yaml

The output file is overwritten; use this change’s working directory. Review images, ports, namespace, storage, and Secrets before sharing output.

# Compare the candidate with current API objects
kubectl --context your-context -n default diff -f rendered.yaml

Exit 1 normally means differences. Use kubectl only to compare here; publish through Helm to avoid mixed resource management.

# Publish reviewed inputs and wait for readiness conditions
helm upgrade --install web ./chart \
  --kube-context your-context -n default \
  -f values.yaml --reset-values --wait --timeout 5m

The namespace must exist. --install permits first installation; --wait/--timeout control waiting, not business tests or automatic rollback. Check release status, Pod events, and real requests afterward.

This explicitly uses chart defaults plus this values file, avoiding accidental inheritance from the old release. Later -f files override earlier ones; --set has higher precedence. Lists are generally replaced, not merged element by element. Pin and review repository or OCI chart versions.

Template is local rendering, not proof of API support, admission acceptance or runtime health; cluster-dependent lookup can differ. Check the installed version’s client/server dry-run support and treat output as potentially secret. Helm 3 --atomic and Helm 4 failure-rollback options differ; inspect helm upgrade --help.

Release rollback is not full application rollback

Inspect history and target inputs before rollback

# Find the target revision’s time, status, and chart version
helm history web --kube-context your-context -n default

Do not assume revision 2 is healthy; find a revision previously verified at the application level.

# Read user values from the candidate revision
helm get values web --revision 2 --kube-context your-context -n default

Also inspect helm get manifest web --revision 2 with the same scope for images/resources. Data recovery needs a separate plan.

# Create a rollback release from the reviewed revision
helm rollback web 2 --kube-context your-context -n default --wait --timeout 5m

Replace 2 with the verified revision. Check the newly added history entry, status, Pods, and requests. On failure inspect events and hook Jobs rather than deleting release storage.

Revision 2 is an example: inspect its image and values first. Rollback creates a new revision; PVC data, external services, hook side effects and database migrations are not automatically reversed. For pending states, inspect active deployment jobs/processes, events and history before attempting recovery.

Find chart versions and release notes

# Inspect configured classic chart repositories and URLs
helm repo list

Run helm repo update separately to refresh indexes; it does not upgrade releases. OCI references do not depend on this repo index.

# Find available chart versions to pin
helm search repo web --versions

For repo/chart installs, specify --version VERSION from this list and inspect that exact version’s values/templates first.

# Read the chart’s usage notes for this release
helm get notes web --kube-context your-context -n default

Verify suggested addresses and credential retrieval against actual resources; notes are not a health check.

Uninstall is a separate resource-deletion task

# Delete the reviewed, retired release resources
helm uninstall web --kube-context your-context -n default --wait --timeout 5m

Review manifests, hooks, PVCs/CRDs, and backups first. Afterward check helm list --all and remaining Kubernetes objects. --keep-history retains history, not data.

For uninstall, pin namespace and context and review PVC, CRD, hook and external-resource behavior first. --keep-history retains release history, not all Kubernetes resources or application data.

helm upgrade · helm rollback · Values files