What's the difference between helm uninstall, helm delete and kubectl delete

Question

I want to remove pod that I deployed to my cluster with helm install.

I used 3 ways to do so:

1. helm uninstall <release name> -> remove the pod from the cluster and from the helm list
2. helm delete <release name> -> remove the pod from the cluster and from the helm list
3. kubectl delete -n <namespace> deploy <deployment name> -> remove the pod from the cluster but not from the helm list

What's the difference between them? Is one better practice then the other?

Answer 1

helm delete is an alias for helm uninstall and you can see this when you check the --help syntax:

$ helm delete --help
...
Usage:
  helm uninstall RELEASE_NAME [...] [flags]

kubectl delete ... just removes the resource in the cluster.

Doing helm uninstall ... won't just remove the pod, but it will remove all the resources created by helm when it installed the chart. For a single pod, this might not be any different to using kubectl delete... but when you have tens or hundreds of different resources and dependent charts, doing all this manually by doing kubectl delete... becomes cumbersome, time-consuming and error-prone.

Generally, if you're deleting something off of the cluster, use the same method you used to install it in the first place. Namely, if you used helm install or helm upgrade --install to install it into the cluster, use helm uninstall to remove it (or helm delete --purge if you're still running Helm v2); and if you used kubectl create or kubectl apply, use kubectl delete to remove it.

Answer 2

I will add a point that we use, quite a lot. helm uninstall/install/upgrade has hooks attached to its lifecycle. This matters a lot, here is a small example.

We have database scripts that are run as part of a job. Say you prepare a release with version 1.2.3 and as part of that release you add a column in a table - you have a script for that (liquibase/flyway whatever) that will run automatically when the chart is installed. In plain english helm install allows you to say in this case : "before installing the code, upgrade the DB schema". This is awesome and allows you to tie the lifecycle of such scripts, to the lifecycle of the chart.

The same works for downgrade, you could say that when you downgrade, revert the schema, or take any needed action. kubectl delete simply does not have such functionality.