Skip to main content
Helm evolved as Kubernetes matured. Helm 1 and 2 launched when Kubernetes lacked some of today’s core features (for example, mature RBAC and CRDs). As Kubernetes added those primitives, Helm could rely on the platform instead of running privileged server components. A brief Helm history:
  • Helm 1.0 — Feb 2016
  • Helm 2.0 — Nov 2016
  • Helm 3.0 — Nov 2019
A dark-themed vertical timeline titled "Helm History" with circular markers for versions 1.0, 2.0, and 3.0. Each marker is paired with dates (Feb 2016, Nov 2016, Nov 2019) and a KodeKloud logo appears in the top corner.
Helm runs as a CLI client that interacts with a Kubernetes cluster. The most notable architectural change between Helm 2 and Helm 3 is the removal of Tiller — the server-side component that Helm 2 used to perform cluster operations.
  • Helm 2: included a server-side component named Tiller. The Helm client communicated with Tiller, and Tiller acted against the Kubernetes API with broad cluster privileges.
  • Helm 3: removed Tiller. The Helm client now talks directly to the Kubernetes API using the caller’s credentials. Kubernetes RBAC applies to the user or service account running the Helm commands.
This change simplified security and operational behavior: from Kubernetes’ standpoint, actions initiated by helm are governed by the same RBAC rules as kubectl.
In Helm 3 there is no Tiller. Helm runs as a client that talks directly to the Kubernetes API using the caller’s credentials, so RBAC policies apply consistently.
Key differences at a glance:
A dark-themed slide titled "Helm 2 vs Helm 3" comparing features: it shows Tiller present in Helm 2 but not in Helm 3, and the 3-way strategic merge patch present in Helm 3 but not in Helm 2.
Another major improvement in Helm 3 is smarter handling of upgrades and rollbacks using a three-way strategic merge patch. Understanding how Helm stores and computes release state is important for predictable upgrades and rollbacks. Revisions and snapshots
  • Each helm install creates a revision (a snapshot of the release state).
  • helm upgrade creates a new revision.
  • helm rollback creates another revision that reverts the release to a previous state.
How Helm 2 handled state and why it could be surprising
  • Helm 2 stored release manifests as the historical source of truth inside Tiller.
  • During upgrades or rollbacks, Helm 2 compared the stored release manifest (previous revision) with the newly rendered manifest (chart + values) to compute the diff.
  • If an operator made manual changes directly in the cluster (for example kubectl set image), those live changes were not recorded in Tiller’s stored manifests. Helm 2’s rollback could therefore miss reverting manual changes because they weren’t represented in the stored release history.
Example (Helm 2-style expectations):
Commands:
Manual live change:
Because that manual change was not captured in Tiller’s stored manifests, Helm 2 rollback behavior could be surprising or incomplete. Helm 3: three-way merge (chart, target revision, and live state)
  • Helm 3 improves correctness by computing a three-way strategic merge using:
    1. The chart/resource definitions in the target revision you want to revert to.
    2. The chart/resource definitions in the currently deployed revision (the last stored release manifest).
    3. The live state of the resources in the cluster.
By including the live cluster state as an input, Helm 3 can:
  • Preserve manual, intentional live changes where appropriate.
  • Correctly compute patches to revert fields back to the target revision when needed.
  • Make upgrades and rollbacks more resilient and predictable in environments where operators sometimes make direct edits.
Example sequence demonstrating Helm 3 behavior:
Commands:
Helm 3 will compare revision 1, the current revision, and the live cluster state. It will detect that the live image is wordpress:5.8-apache while revision 1 expects wordpress:4.8-apache, and will generate the necessary strategic patch to restore the desired revision state. Upgrades with local changes
  • Helm 2: manual changes on live objects were often overwritten or lost during upgrades because Helm only considered stored manifests and the chart diff.
  • Helm 3: because the live state is an explicit input, Helm can avoid unintentionally discarding manual changes and can make more nuanced merge decisions during upgrades.
Comparison table Further reading and references That’s all for this lesson.

Watch Video