What is the different between Helm2 and Helm3 ?

Feature	Helm 2	Helm 3
Architecture	Helm client + Tiller server	Client only
Tiller	Required	❌ Removed
RBAC / security	Tiller needed Kubernetes permissions	Uses your Kubernetes user’s permissions
Release storage	Tiller stores releases	Releases stored in Kubernetes
3-way merge	❌	✅
CRDs	Limited handling	Better CRD support
Kubernetes namespaces	Tiller managed releases	Helm client works directly with cluster
helm init	Required	❌ Not needed
Chart dependencies	requirements.yaml	Chart.yaml dependencies
Release names	Some restrictions	More flexible
Secrets	Tiller-related concerns	Can store releases as Kubernetes Secrets
OCI registries	❌	✅ Supported
Security	More complicated	Generally simpler and safer

1. The biggest change: Tiller

Helm 2:

You
 │
 ▼
Helm CLI
 │
 ▼
Tiller
 │
 ▼
Kubernetes API

Tiller was a server running inside the Kubernetes cluster. Helm CLI sent requests to Tiller, and Tiller performed operations against Kubernetes.

This created a significant security concern: if Tiller had broad permissions, anyone able to interact with Tiller could potentially perform operations with those permissions.

Helm 3:

You
 │
 ▼
Helm CLI
 │
 ▼
Kubernetes API

There is no Tiller.

Helm uses your Kubernetes credentials and RBAC permissions directly.

For example:

helm install myapp ./mychart

Helm talks directly to the Kubernetes API server.

---

2. helm init is gone

In Helm 2, you typically did:

helm init

This installed/configured Tiller.

In Helm 3:

helm version

is enough to verify Helm. There is no Tiller to install.

---

3. Permissions are much simpler

Suppose your Kubernetes user has permission to create Deployments but not Services.

With Helm 3, Helm cannot magically get additional permissions. Kubernetes RBAC applies directly to the Helm operation.

So:

Helm
  │
  └── Kubernetes API
          │
          └── RBAC → allowed / denied

This is one of the most important operational differences between Helm 2 and Helm 3.

---

4. Release information

Helm needs to keep information about releases such as:

myapp
  ├── chart
  ├── version
  ├── values
  └── revision history

In Helm 2, Tiller managed this information.

In Helm 3, release information is stored in Kubernetes, typically as Secrets by default.

You can see them with:

kubectl get secrets -n mynamespace

---

5. Helm 3 uses 3-way merge

This is an important upgrade-related difference.

Helm 2 primarily compared the previous Helm state with the desired state.

Helm 3 uses a 3-way strategic merge involving:

Last Helm configuration
        +
Current Kubernetes object
        +
New Helm configuration
        ↓
     New object

This makes upgrades more resilient when someone has manually changed a Kubernetes resource outside Helm.

---

6. Chart dependencies changed

Helm 2 commonly used:

requirements.yaml

For example:

dependencies:
  - name: redis
    version: 1.0.0
    repository: https://example.com/charts

Helm 3 moved dependencies into:

Chart.yaml

For example:

dependencies:
  - name: redis
    version: 1.0.0
    repository: https://example.com/charts

Then:

helm dependency update

---

7. Helm 3 has better OCI support

Helm 3 supports storing and distributing charts through OCI-compatible registries.

For example, modern workflows can use registries such as container registries to store Helm charts alongside container images.

---

8. Migration from Helm 2 → Helm 3

If you’re working with an older Kubernetes environment, you may encounter Helm 2.

There was a migration tool called:

helm-2to3

It helped migrate Helm 2 releases to Helm 3.

For a modern Kubernetes environment, though, Helm 3 is the standard choice. Helm 2 reached end-of-life years ago.

Easy way to remember

Think of it this way:

HELM 2

Developer
   ↓
Helm CLI
   ↓
Tiller
   ↓
Kubernetes


HELM 3

Developer
   ↓
Helm CLI
   ↓
Kubernetes

The key interview answer:

Helm 3 removed Tiller. Helm now communicates directly with the Kubernetes API using the user’s Kubernetes credentials and RBAC permissions. This simplifies the architecture and improves security.

If you’re learning Helm for DevOps/Kubernetes interviews, the next useful topic is understanding helm install → values.yaml → templates → rendered Kubernetes YAML → release → upgrade/rollback.