What You Should Know About the Helm 3 Release

Introduction to Helm 3

Helm is the package manager for Kubernetes, simplifying application deployments through charts. Helm 3 is a major release that replaces Helm 2, addressing long-standing security and usability issues while adding powerful new features.

The community has documented the official Helm 2 to Helm 3 differences here, but in this article, we’ll summarize the most important changes and explain how they improve the Kubernetes developer and operator experience.

1. Tiller Is Gone! (Security Improvements)

One of the biggest changes in Helm 3 is the removal of Tiller.

• In Helm 2, Tiller ran inside the cluster with cluster admin privileges, which created security concerns.
• Helm 3 no longer requires Tiller. Instead, it leverages Kubernetes RBAC directly through the kubeconfig file.
• This gives administrators finer-grained access control over who can install or manage Helm releases.

Multiple clients can still view the same releases using in-cluster storage drivers like Secrets and ConfigMaps.

Why this matters: Helm 3’s removal of Tiller aligns better with Kubernetes security practices and reduces attack surfaces.

2. 3-Way Strategic Merge Patches (Smarter Upgrades)

Helm 3 introduced 3-way strategic merge patches to handle upgrades more effectively.

This means when you apply a new configuration:

• Helm compares it against the original manifest and the live configuration.
• Conflicting changes are resolved intelligently — preserving user modifications unless explicitly overridden.
• Map-type keys are merged instead of replaced, preventing accidental overwrites.

This ensures safer upgrades without unintentionally breaking live workloads.

To understand how it will work, assume we havethe 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 the new configuration

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

The final live configuration will 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 a merge operation and not a replace. For more details on the strategic merger, please check here.

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

kind: Service
spec:
	selector:
    	app: MyApp

Now, when we apply the new configuration:

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

The final live configuration will be:

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

As you can see, this is a merge operation and not a replacement

3. Namespace-Scoped Releases

In Helm 2, release metadata was stored in the kube-system namespace.

In Helm 3:

• Releases are namespace-scoped.
• The same release name can exist in different namespaces.
• Release information is stored in the respective namespace, reducing risks in multi-tenant clusters.

This makes Helm 3 more secure and flexible for organizations managing multiple teams or environments.

4. Helm 3 as a Go Library (Developer-Friendly)

For developers building DevOps tools on top of Helm, Helm 3 brings:

• Cleaner Go APIs and libraries.
• A new import path: helm.sh/helm/v3 (instead of k8s.io/helm).

This makes it easier to integrate Helm into custom automation pipelines.

5. JSON Schema Chart Validation

Helm 3 lets chart maintainers enforce schema validation with JSON schemas.

• You can define mandatory fields, value types, and patterns.
• Validation is enforced during:
  • helm install
  • helm upgrade
  • helm template
  • helm lint

This prevents users from passing invalid values into Helm charts.

{
    "$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"
}

6. Library Chart Support (Code Reuse)

Helm 3 introduces library charts that:

• Contain reusable snippets of code.
• Can be shared across multiple charts without being deployed as standalone releases.

This promotes chart standardization and reuse in large organizations.

7. Pushing Charts to OCI Registries

Helm 3 adds OCI registry support (initially experimental).

• Charts can be stored and distributed via OCI-compliant registries.
• Based on the Docker distribution project.
• Leverages hardened container registry security practices.

This makes Helm chart distribution more consistent with container image management.

8. Helm 3 and CRDs (Custom Resource Definitions)

Helm 3 improves the way it handles CRDs:

• CRDs are no longer upgraded automatically, avoiding disruptions.
• CRD installation is handled separately, ensuring compatibility and stability.

This change prevents accidental overwrites of critical CRDs during upgrades.

Helm 2 vs Helm 3: Key Differences

Helm 3 focuses on security, flexibility, and extensibility, addressing the limitations of Helm 2.

How to Install Helm 3

You can install Helm 3 by following the official installation guide.

Basic steps:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Once installed, verify with:

helm version

Conclusion

Helm 3 is a game-changer for Kubernetes package management. By removing Tiller, introducing namespace-scoped releases, schema validation, OCI support, and more, Helm 3 is more secure, reliable, and flexible than its predecessor.

If you’re still using Helm 2, now is the time to migrate to Helm 3 for long-term support and modern Kubernetes compatibility.

FAQ

Anushka Arora

Anushka is the youngest member of team Devtron. She is the force behind the content that one sees on Devtron and loves to share her knowledge with people. She is an avid book reader and loves traveli