Helm is becoming the de facto standard for managing Kubernetes deployments.
Although not the only tool in the landscape, it’s by far more popular than the alternatives.
The reason for using Helm is quite obvious: managing your K8S deployments by hand requires a lot of YAML manipulation which usually leads to high maintenance and duplication.

Recently, Helm v3 was released and I wanted to describe the changes and new features in detail.

Removal of Tiller

If you have worked with previous versions of Helm, one of the mandatory installation components was the Tiller Helm server that needed to be installed in your K8s cluster.
You might have asked, why is it needed? Can’t all the operations be performed from the client side?
Well, when Helm v2 was released in 2016, some of the K8s features that we are now used to (e.g., Custom Resource Definitions (CRDs)) weren’t available yet.
These days, there is really no need for Tiller.
In version 3, Tiller is no more ☺

With the removal of Tiller, there is no centralized namespace where all Releases’ information is stored (the namespace where the Tiller was installed). Now this information is stored in the namespace of the chart itself.
Your releases are now under their own namespace (yes you have to create the namespace).

Security is also now handled where it should, i.e., by K8s RBAC.

XDG-based Directory Structure

Starting with Helm v3, directory structure and its configuration are based on the XDG Base Directory Specification.
For those not familiar, the XDG specification defines standard environment variables for locating the home directory and various subfolders.

In version 3, $HELM_HOME is no more ☺

Also, the “helm init” and “helm home” commands no longer exist.

Library Charts

Starting with v3, a chart can have the type (meta-data chart property) of either “application” or “library” (“application” by default).
Library charts are common charts that are reusable and intended for use in a containing application.

Regarding chart dependencies, requirements and dependencies have been moved into the chart.yaml itself.
A Smooth Migration?

While experimenting with Helm v3, I ran into some issues where I had a chart deployed with v2 and tried to delete and replace it using a v3 client.
I got some weird errors when trying to reinstall the chart (e.g., already exists). Although looking at “helm ls” didn’t display anything about my chart.
This error occurred because the different versions of Helm store their catalog in different locations.
I had to revert to Helm v2 client to purge my chart.
So, keep that in mind and follow proper migration guides.

ChartCenter

Combined with the release of Helm v3, I was also excited to hear the announcement of ChartCenter.
ChartCenter (https://chartcenter.io/) provides you with all the information you need about the charts you depend on, including security vulnerabilities scanning information powered by JFrog Xray.
On the site’s UI you can dig deep into the subcomponents of the included containers and see the vulnerable components down to the application’s dependencies.
Not only do I now have a “go-to” place for fetching my infrastructure chart, I can also assure myself that my dependencies have no critical security vulnerabilities.