Releases & Upgrades

A rollback re-applies a stored manifest, so it restores only what that manifest describes. Data a workload already wrote, volume contents, CRDs installed from crds/ and anything outside the cluster stay as they are — and rendered credentials are reverted, which can be worse.

On a first install there is no previous revision to restore, so Helm uninstalls the release instead: the objects and the release record are removed. The cleanup is deliberate, but it also deletes the failed pods you needed to diagnose.

The conflict means another manager already owns the fields Helm is trying to set. --force-conflicts tells the API server to override that and hand ownership to Helm. It is wrong when the other owner is a controller that will immediately write the field back.

Confirm nothing is still running, then take the least invasive rung that works: roll back to the last revision that reached deployed. Only if that is impossible do you delete the stuck revision's release Secret by hand.

Treat release records as derived state: chart and values in version control are the truth. Keep the default in-cluster backend unless size or scale forces otherwise, set retention centrally from your detection window, and govern who can read stored values.

No blanket rule. Automatic rollback fits stateless workloads whose previous revision is still safe to run, and is dangerous for releases with irreversible hook side effects, very slow rollouts, or schema changes the old version cannot read. Decide per chart shape.

Decide at chart-authoring time which resource classes may survive an uninstall, split teardown into deleting the release and a separate owned reclaim step, keep cluster-scoped deletion manual, and verify the namespace afterwards instead of trusting the exit code.

Decide what a green deploy is allowed to mean, then buy that meaning: a wait strategy where the pipeline gates on health, per-chart timeouts sized from measured rollout time, and an explicit answer for what a timed-out release obliges someone to do.

helm install refuses to run with no release name. --generate-name makes Helm derive one from the chart name plus a numeric suffix; --name-template lets you supply a Go template that produces the name. Both suit throwaway installs, not pipelines.

Against a second hard-coded table that is essentially the reverse of the install order: APIService and Ingress first, then Service, then workloads, then config and RBAC, with Namespace and PriorityClass deleted last.

HELM_DRIVER selects where Helm persists release records: secret (the default), configmap, memory, or sql against PostgreSQL. Switching does not migrate anything — records written under one driver are simply invisible under another, so releases disappear from helm list.

Find the object whose deletion never completed and unblock it, then re-run helm uninstall. Removing the release records first only hides the release: whatever is still running is orphaned with no owner on record.

A wait strategy judges whether resources reached a ready state, and a Job created and running counts as arrived - completion is a different condition. Add --wait-for-jobs to make Helm block until the release's Jobs finish, inside the same --timeout.

Treat the values that feed a workload's selector as a frozen part of a chart's contract, keep objects whose spec cannot change out of the ordinary upgrade path, gate chart bumps on a server-side dry run against a real cluster, and decide in advance who may recreate an object in production.

Treat the ownership metadata as the migration primitive: inventory what exists, decide release boundaries, make each chart render what is already live, stamp objects per release, and settle uninstall behaviour before anything is claimed.

Nothing moves on its own: auto inherits each release's existing method, so the estate can stay client-side indefinitely. Migrate release by release with an otherwise unchanged chart, rehearsed against the API server, ordering by blast radius and settling contested fields in the chart rather than forcing them.