Helm in Practice

Uninstall Workflow

When it's time to remove a release from the cluster, helm uninstall handles the teardown process. Here's how Helm performs an uninstall:

Pre-Delete Hooks: Before removing any resources, Helm will run any pre-delete hooks that the chart has. This is the last chance for the chart to perform tasks while the release's resources still exist. Common uses include jobs that need to run to gracefully shut down the application or clean up external systems (e.g., inform a load balancer to stop sending traffic or take a backup before deletion). Helm creates the hook resources and waits for them to complete, just like other hooks.

Resource Deletion: Helm then deletes all the Kubernetes objects that were originally installed by the release. It determines this list from the release's manifest record. Deletion is performed in the reverse order of installation to respect dependencies.

So it starts with webhooks, APIService objects, Ingresses, down through Pods/Deployments, and ends with the Namespace (if Helm created a namespace, it would delete it last).

Helm attempts to delete every resource and will continue even if some deletions fail (it will report failures at the end).

Post-Delete Hooks: After the core resources are removed, any post-delete hooks are triggered.

These run when the release's primary resources are gone. A post-delete hook could be used to purge data or notify an external system that the release has been removed. Remember that if the release included CRDs via the crds/ folder, those CRDs are not deleted by Helm.

If complete removal is desired, you must delete the CRDs (and any CR instances) manually or via a hook job.

ℹ️ Chart developers sometimes include a post-delete hook job that tries to delete CRDs or related data, but this is cautious territory because removing CRDs can affect other applications using them.

Release History