What you should know about Helm 3

By Anushka Arora, The force behind the content that one sees on Devtron loves sharing her knowledge with people.

Helm 3 is a significant release that has been out for some time now. Community maintaining helm has done a great job explaining the differences between helm two and helm 3, and you can read them here. In this article, we will cover the essential 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 more refined 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 a 3-way merge reconciles a modified configuration with an original design while preserving any changes or deletions made to the initial configuration in the interim and not overridden by the current configuration. It will fail if any of the documents are invalid or any preconditions fail against the modified structure. If there is a conflict, that is keys changed differently from original to modified than from initial to current, in other words, if modified changes any access in a way that is different from how it is changed in the current (e.g., deleting it, changing its value) then the current discount 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 the original configuration

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

It was modified directly; therefore, the live format is

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

Now when we apply the 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 critical point to note is that it applies a strategic patch. It means that for map type keys, 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 the original configuration:

kind: Service
spec:
	selector:
    	app: MyApp

Now when we apply the new structure:

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

The 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. It essentially means that we can use the same release name as long as their namespaces are different. Another implication from the security perspective 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 a command-line utility. Helm 3 undertook substantial refactoring to make it easier for DevOps tools to use as a library. Also, helm has switched the import path from k8s.io/helm to the helm.sh/helm/v3. This makes it easier for any DevOps tool to support both helm two 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 to never pass invalid values. E.g., 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 mandatory and expects designation 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 significant 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 HELM_EXPERIMENTAL_OCI=1 can set.

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

Originally published at https://devtron.ai on May 11, 2020.