What You Should Know About the Helm 3 Release

Helm 3 is a major release that has been out for some time now. Community maintaining helm has done a great job of explaining differences between helm 2 and helm 3 and you can read them here. In this article, we are going to cover the most important changes according to us and their benefits.

1.) Tiller is gone!

Tiller was by far the most controversial component. With cluster admin privileges it gave security nightmares to the cluster operators. In this release it has been completely removed. Now you can have much finer access controls driven by the kubeconfig.

Multiple clients can still see the same releases through the in-cluster storage driver like secrets and configmaps.

2.) Introduced 3-way Strategic Merge Patches

Implementation of 3-way merge reconciles a modified configuration with an original configuration, while preserving any changes or deletions made to the original configuration in the interim, and not overridden by the current configuration. It will fail if any of the documents is invalid, or if there are any preconditions that fail against the modified configuration. If there is a conflict, that is keys changed differently from original to modified than from original to current, in other words, if modified changes any key in a way that is different from how it is changed in current (e.g., deleting it, changing its value) then the current value is applied. Values fields that do not exist in original but are explicitly defined in modified are also propagated.

To understand how will it work assume we have original configuration

kind: Deployment
spec:
  containers:
  - resources:
       requests:
       memory: "64Mi"
       cpu: "250m"

It was modified directly therefore live configuration is

kind: Deployment
spec:
  containers:
  - resources:
      requests:
      memory: "128Mi"
      cpu: "500m"

Now  when we apply new configuration

kind: Deployment
spec:
   containers:
    - resources:
          requests:
          memory: "256Mi"
          cpu: "250m"

Then final live configuration ll be

kind: Deployment
spec:
	containers:
	- resources:
    	requests:
        memory: "256Mi"               -- taken from new configuration
        cpu: "500m"                   -- taken from live configuration

Another important point to note is that it applies a strategic patch. What it means is that for keys of map type, patch operation will result in merge operation and not replace. For more details on strategic merge please check here.

To understand how will it work assume we have original configuration:

kind: Service
spec:
	selector:
    	app: MyApp

Now  when we apply new configuration:

kind: Service
spec:
	selector:
    	pod-hash: my-hash

Then final live configuration ll be:

kind: Service
spec:
	selector:
    	pod-hash: my-hash
        app: MyApp

As you can see this is a merge operation and not replace

3.) Helm 3 Lists Releases by Namespace

Helm releases are now namespace scoped. What it essentially means is that we can use the same release name as long as their namespaces are different. Another implication from the security point of view is that now release information is stored in the respective namespaces and not in the kube-system namespace.

4.) Change in Go import

This is only relevant if you are using helm as a library instead of command line utility. Helm 3 undertook substantial refactoring to make it easier for devops tools to use it as a library. Also helm has switched the Go import path over from  k8s.io/helm to helm.sh/helm/v3. This makes it easier for any devops tool to support both helm 2 and helm 3. If you intend to upgrade to the Helm 3 Go client libraries, make sure to change your import paths.

5.) JSON Schema Chart Validation

If you are a chart maintainer you can define and enforce schema for the users so that they never pass invalid values. For eg: you can define keys as mandatory or define bounds for numerical values. For more information please read here.

The following example shows how to make repo and tag as mandatory and expects tag to conform to a particular pattern.

{
    "$schema": "https://json-schema.org/draft-07/schema#",
    "properties": {
            "image": {
            "description": "Container Image",
            "properties": {
            "repo": {
            "type": "string"
            },
            "tag": {
            "type": "string",
            "pattern": "^Tag-\\.[0-9]{3}\\.[0-9]{3}\\.[0-9]{3}$"
            }
            },
              "required": [
            "repo","tag"],
            "type": "object"
            }
        },
    "required": [
        "image"
        ],
    "type": "object"
}

Validation occurs when any of the following commands are invoked:

• helm install
• helm upgrade
• helm template
• helm lint

6.) Library Chart Support

Helm 3 has taken a major step forward in chart reusability with library charts. It is possible to re-use some snippets of code across multiple charts without creating a release artifact of its own.

Library charts are declared in the ‘dependencies’ section in Chart.yaml and you can install and manage them like any other chart.

7.) Pushing Charts to OCI Registries

Helm 3 has introduced this as an experimental feature which can be set by HELM_EXPERIMENTAL_OCI=1

This is based on the Docker distribution project, one of the main motivators behind this move was to inherit years of hardening, security best practices of the Docker distribution project for helm charts.

Check out our post on the top 3 challenges when using Helm charts.