A quick note about Helm2 vs Helm3

Helm has evolved significantly since its inception, and understanding the differences between Helm 2 and Helm 3 is crucial when working with Kubernetes charts. This article provides a brief history of Helm and highlights the key improvements introduced in Helm 3, offering insights into its enhanced usability and security.

A Brief History of Helm

Helm's journey began in February 2016 with Helm 1.0, followed by Helm 2.0 in November 2016. The major milestone was achieved with the release of Helm 3.0 in November 2019. As Kubernetes itself advanced, Helm matured to better leverage Kubernetes functionalities, resulting in a more robust and secure package management experience.

Helm 2: The Role of Tiller

In the era of Helm 2, Kubernetes limitations such as the absence of role-based access control (RBAC) and custom resource definitions (CRDs) meant that an additional component, Tiller, was required. Tiller acted as an intermediary between the Helm CLI and the Kubernetes cluster, managing the installation and upgrade of charts. However, this approach introduced several challenges:

• Complexity: The interaction between the CLI and Tiller added an extra layer to the deployment process.
• Security Risks: Tiller operated with broad privileges, often referred to as running in "God mode," increasing the risk of potential security issues.

Helm 3: Simplified and Secure

Helm 3 brings notable improvements by eliminating the need for Tiller. Instead, the Helm client now communicates directly with Kubernetes, leveraging its native RBAC capabilities. This change simplifies the architecture and enhances security, as every Helm action is subject to the same RBAC permissions applied when using kubectl.

Key Differences Between Helm 2 and Helm 3

Improved Rollback and Upgrade Process in Helm 3

One of the significant advancements in Helm 3 is the handling of rollbacks through a three-way strategic merge patch, resembling a snapshot mechanism. Consider the example of deploying a WordPress website using a Helm chart:

1. Installation: When you install the chart, Helm creates revision 1.
2. Upgrade: After changing configurations, such as upgrading the WordPress image, Helm creates revision 2.
3. Rollback: If needed, reverting to revision 1 will restore the previous state.

Below is an example of the process:

$ helm install wordpress
$ helm upgrade wordpress

Revision Changes in YAML

# Revision 1: Using an older WordPress image
containers:
  - image: wordpress:4.8-apache

# Revision 2: After upgrading to a newer WordPress image
containers:
  - image: wordpress:5.8-apache

To roll back to revision 1:

$ helm rollback wordpress

With each significant change invoked via Helm commands, a new revision is created. For instance, installation creates revision 1, an upgrade creates revision 2, and a rollback may create revision 3 representing the restored state.

Handling Manual Changes and Upgrades

In Helm 2, if a user manually modified Kubernetes objects (e.g., using kubectl set image) after deployment, these changes were not recorded in Helm's revision history, meaning Helm might not detect any differences during a rollback. In contrast, Helm 3 compares the live state against both the current and desired revisions. This ensures:

• Manual modifications outside of Helm are preserved during upgrades.
• Overwritten configurations are avoided unless explicitly intended.

Conclusion

The transition from Helm 2 to Helm 3 marks a significant improvement in Kubernetes deployment management. By removing Tiller and implementing a more robust rollback mechanism via a three-way strategic merge patch, Helm 3 ensures enhanced security, simplified architecture, and greater reliability during upgrades.

For more detailed information on Helm and Kubernetes, check out the following resources:

• Kubernetes Basics
• Kubernetes Documentation
• Helm Documentation

This guide should help you understand the evolution of Helm and leverage Helm 3's features for a more secure and streamlined deployment experience.