Skip to content

10.3 A Quick Note on Helm 2 vs Helm 3

Abstract

Helm 3 introduced major improvements over Helm 2, especially in security, architecture, and rollback behavior.

The biggest changes are:

  • Helm 3 removed Tiller
  • Helm 3 uses Kubernetes RBAC directly
  • Helm 3 supports 3-way strategic merge patch
  • Helm 3 handles upgrades and rollbacks more safely

Why This Matters

You may still find old Helm 2 examples in blogs, GitHub repositories, or older training material.

In production, you should understand the difference so you do not accidentally follow outdated Helm 2 practices.

Warning

Most modern Kubernetes environments use Helm 3.
Avoid Helm 2 unless you are maintaining a legacy cluster.

Quick History

Version Release Time Notes
Helm 1 2016 Early Helm release
Helm 2 2016 Introduced Tiller server-side component
Helm 3 2019 Removed Tiller and improved security

Note

Helm 3 is simpler because it talks directly to the Kubernetes API server using the user's kubeconfig and RBAC permissions.

Helm 2 Architecture

In Helm 2, the Helm CLI did not directly manage Kubernetes objects.

It communicated with a server-side component called Tiller.

helm CLI
   |
   v
Tiller inside Kubernetes cluster
   |
   v
Kubernetes API Server

Tiller was responsible for:

  • installing charts
  • upgrading releases
  • rolling back releases
  • modifying Kubernetes resources

Warning

Tiller added extra operational and security complexity because it ran inside the cluster with powerful permissions.

Helm 2 Security Problem

In many Helm 2 setups, Tiller had very broad permissions.

This meant:

  • users with access to Tiller could indirectly modify cluster resources
  • permissions were harder to control
  • Tiller could become a security risk
  • RBAC enforcement was less clean

Danger

A poorly secured Tiller installation could allow users to perform actions beyond their intended permissions.

Helm 3 Architecture

Helm 3 removed Tiller completely.

helm CLI
   |
   v
Kubernetes API Server

Helm 3 uses:

  • kubeconfig
  • Kubernetes API server
  • Kubernetes RBAC
  • Kubernetes secrets/configmaps for release metadata

Success

Helm 3 is more secure because it uses the same Kubernetes RBAC model as kubectl.

Helm 2 vs Helm 3 Comparison

Feature Helm 2 Helm 3
Tiller Required Removed
Security model Tiller permissions Kubernetes RBAC
Cluster component Yes No
CRD support Limited Improved
Rollback behavior 2-way comparison 3-way strategic merge patch
Operational complexity Higher Lower
Recommended today No Yes

Role-Based Access Control

In Helm 3, permissions are controlled directly through Kubernetes RBAC.

If a user cannot create a deployment using kubectl, they also cannot create it using Helm.

Example check:

kubectl auth can-i create deployments
kubectl auth can-i create services
kubectl auth can-i create secrets

Tip

Helm 3 does not bypass Kubernetes security. It respects the permissions of the user or service account running the command.

CRD Handling

Helm 3 has better support for Custom Resource Definitions.

Charts can include CRDs under:

crds/

Example chart structure:

my-chart/
├── Chart.yaml
├── values.yaml
├── crds/
│   └── my-crd.yaml
└── templates/
    └── deployment.yaml

Note

CRDs should be handled carefully in production because deleting or changing CRDs can affect all custom resources using them.

Helm Revisions

Helm tracks changes using release revisions.

Example workflow:

helm install wordpress bitnami/wordpress
helm upgrade wordpress bitnami/wordpress
helm rollback wordpress 1

Each important Helm action creates a revision.

Action Revision
Install Revision 1
Upgrade Revision 2
Rollback Revision 3

Example

A rollback also creates a new revision because Helm records the rollback action as part of release history.

View Helm Release History

helm history wordpress

Example output:

REVISION    UPDATED                     STATUS      CHART
1           2026-01-01 10:00:00         superseded  wordpress
2           2026-01-02 10:00:00         deployed    wordpress

Rollback:

helm rollback wordpress 1

Helm 2 Rollback Limitation

Helm 2 compared only:

previous chart
current chart

This means Helm 2 did not fully understand manual changes made directly in Kubernetes.

Example:

helm install wordpress
kubectl set image deployment/wordpress wordpress=wordpress:5.8-apache
helm rollback wordpress

In Helm 2, the manual kubectl set image change may not be handled correctly because Helm only compared chart revisions.

Bug

Helm 2 could miss live cluster changes if those changes were not made through Helm.

Helm 3: 3-Way Strategic Merge Patch

Helm 3 compares three things:

1. Previous chart
2. Current chart
3. Live Kubernetes state

This is called 3-way strategic merge patch.

It helps Helm understand:

  • what Helm previously installed
  • what Helm wants to apply now
  • what currently exists in the cluster

Success

Helm 3 can better preserve manual changes and perform safer upgrades or rollbacks.

Why 3-Way Merge Helps

Suppose you installed WordPress using Helm:

helm install wordpress bitnami/wordpress

Then someone manually changed the image:

kubectl set image deployment/wordpress wordpress=wordpress:5.8-apache

In Helm 3, rollback can compare the live cluster state with the stored Helm revision and apply the correct correction.

helm rollback wordpress 1

Tip

Helm 3 is smarter because it checks what is actually running in the cluster, not only what Helm previously recorded.

Upgrade Behavior

In Helm 2, upgrades could overwrite manual live changes because Helm mainly compared old and new chart manifests.

In Helm 3, upgrades are safer because Helm considers live state.

Example:

helm upgrade wordpress bitnami/wordpress

Helm 3 checks:

  • old manifest
  • new manifest
  • live manifest

This reduces unexpected overwrites.

Warning

Even with Helm 3, avoid making manual changes to Helm-managed resources unless absolutely necessary.

Production Best Practices

Recommended

  • Use Helm 3 for all modern Kubernetes environments
  • Avoid Tiller-based Helm 2 setups
  • Manage Helm access through Kubernetes RBAC
  • Use least-privilege service accounts for CI/CD
  • Store values.yaml files in Git
  • Use helm diff or helm template before production upgrades
  • Avoid manual changes to Helm-managed resources
  • Track release history before rollback

Helm 3 Commands to Know

Task Command
Install release helm install <release> <chart>
Upgrade release helm upgrade <release> <chart>
Upgrade or install helm upgrade --install <release> <chart>
Rollback release helm rollback <release> <revision>
View history helm history <release>
View status helm status <release>
Uninstall release helm uninstall <release>

Do's

  • Use Helm 3 for new deployments
  • Verify current Kubernetes context before running Helm
  • Use RBAC to control Helm permissions
  • Use namespaces for release isolation
  • Review generated manifests before applying
  • Use version-pinned charts in production
  • Keep Helm releases under GitOps or CI/CD control

Don'ts

  • Don't install or use Tiller in modern clusters
  • Don't give Helm users cluster-admin by default
  • Don't manually edit Helm-managed resources without tracking the change
  • Don't rely on outdated Helm 2 blog commands
  • Don't skip release history checks before rollback
  • Don't store sensitive values directly in plain text

Helm 2 to Helm 3 Migration Notes

If you are maintaining legacy Helm 2 releases:

  1. Identify Helm 2 releases.
  2. Back up release values and manifests.
  3. Plan migration to Helm 3.
  4. Remove Tiller after migration.
  5. Revalidate RBAC permissions.

Danger

Do not remove Tiller before confirming whether legacy Helm 2 releases still depend on it.

Security Considerations

Helm 3 improves security, but it does not automatically make deployments secure.

Still review:

  • chart source
  • chart templates
  • RBAC permissions
  • secrets handling
  • container images
  • generated Kubernetes manifests

Failure

A malicious or poorly written chart can still create risky Kubernetes objects if the user has permission to create them.

Troubleshooting

Helm command works, but resource creation fails

Check RBAC:

kubectl auth can-i create deployments
kubectl auth can-i create services
kubectl auth can-i create secrets

Rollback does not behave as expected

Check revision history:

helm history <release-name>

Check live state:

kubectl get all -n <namespace>

Manual changes keep disappearing

This usually happens when Helm upgrades reapply chart state.

Better approach:

  • update values.yaml
  • run helm upgrade
  • avoid direct manual changes

Tip

Treat Helm-managed resources as declarative. Change them through Helm values, not manual kubectl edit.

Summary

Quote

  • Helm 2 used Tiller
  • Helm 3 removed Tiller
  • Helm 3 uses Kubernetes RBAC directly
  • Helm 3 supports 3-way strategic merge patch
  • Helm 3 is safer, simpler, and recommended for production