1

I'm using helm 3.4.2 for upgrade my charts to my AKS cluster and I saw that every time I deploy something new, it creates a new secret called sh.helm.v... This is the first time I'm using helm.

I was reading the doc and found that at version 3.x helm is using secrets to store driver as default. Cool, but every time I deploy it creates a new secret and I'm now sure if this is the best to keep it all in my cluster.

Soo, should I keep then all in my cluster? Like, every time I deploy some thing, it creates a secret and live there

or

Can I remove the last before? Like, deploy v5 now and erase v1, v2, v3 and keep the v4 and v5 for some reason. If it's ok to do it, does anyone has a clue for how to do it? Using a bash ou kubectl?

Thanks a lot!

Arthur Ávila
  • 69
  • 2
  • 9

1 Answers1

1

So yes, There are few major changes in Helm3, comparing to Helm2.

  1. Secrets are now used as the default storage driver

In Helm 3, Secrets are now used as the default storage driver. Helm 2 used ConfigMaps by default to store release information. In Helm 2.7.0, a new storage backend that uses Secrets for storing release information was implemented, and it is now the default starting in Helm 3.

Also

  1. Release Names are now scoped to the Namespace

In Helm 3, information about a particular release is now stored in the same namespace as the release itself. With this greater alignment to native cluster namespaces, the helm list command no longer lists all releases by default. Instead, it will list only the releases in the namespace of your current kubernetes context (i.e. the namespace shown when you run kubectl config view --minify). It also means you must supply the --all-namespaces flag to helm list to get behaviour similar to Helm 2.

Soo, should I keep then all in my cluster? Like, every time I deploy some thing, it creates a secret and live there or Can I remove the last before?

I dont thinks its a good practice to remove anything manually. If it is not mandatory necessary - sure better not touch them. However, you can delete unused ones, if you sure you will not need old revisions in the future.

#To check all secretes were created by helm:
kubectl get secret -l "owner=helm" --all-namespaces

#To delete revision you can simply remove appropriate secret..
kubectl delete secret -n <namespace> <secret-name>

Btw(just FYI), taking into an account the fact Helm3 is scoped to namespaces - you can simply delete deployment by deleting its corresponding namespace

And the last remark, maybe it would be useful for: you can pass --history-max to helm upgrade to

limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)

Vit
  • 7,740
  • 15
  • 40
  • 2
    I've tried once the `--history-max` and didn't work. But probably I was doing something wrong 'cause worked just fine =D – Arthur Ávila Apr 12 '21 at 14:37