With its November 2019 release, Helm 3 works great as a package manager that creates repeatable builds of Kubernetes applications. However, there’s one exception: Helm no longer creates namespaces for your deployments. This post shows one solution along with alternatives worth exploring.
I created a generic Helm3 namespace chart for use with helmfile or similar Helm gluing toolsets. This is just a carry-over solution for Helm 3’s inability to create namespaces for a release, which likely will change in Helm 3.1.
These are a list of namespaces to create as well as additional labels and annotations you’d like to append. You can also set whether or not Helm is allowed to delete the namespace. Default policy is ‘keep’.
Example – helmfile
Here is a simple example helmfile that creates a namespace as part of a cert-manager deployment. The default helm resource policy of ‘keep’ is used so that the namespace will not be removed in a Helm destroy operation. This means you will have to manually delete the namespace if you want to reinstall the deployment while testing things out. Default tillerless plugin options are also set if this helmfile is created with helm version 2. I only include the namespace generation in this example for brevity.
This helmfile will require that you use the helm-git plugin and that the namespace does not already exist.
There are some alternatives that may be better suited to your particular need. See this thread for more information.
Alternative 1 – helm-namespace (plugin)
I’ve also done some testing with the helm-namespace plugin and it works very well. Unfortunately, this requires changing your Helm commands and may interrupt existing workflows. This is the first alternative and honestly, probably the best one.
Alternative 2 – presync hooks
There are also presync helm hooks that allow you to run kubectl commands to create the namespace if it does not exist. A helmfile would have a presync hook like the following to accomplish this task.
This has the drawback of requiring 100% certainty of your kubectl context and version. It also obscures your end Helm state (imho). Benefits for using this would be that your Helm deployment will not fail if the resource (namespace) already exists.
Alternative 3 – raw charts
The incubator/raw Helm chart is such a wondrous chart that you can do so many cool things with. This includes creating your namespaces if desired. The drawback is that it is pure Kubernetes declarative manifest yaml (for the most part). Plus, I just wanted a small point solution for use in all my existing helm charts, so I opted to not use the raw chart for this particular need.