Summary
Helm, the popular Kubernetes package manager, comes in two versions: version 2 and version 3. While version 3 introduced several changes and improvements over version 2, it’s important to understand the differences between the two versions.
One of the key differences between Helm version 2 and version 3 is in the way release management is handled. In version 2, the Helm installation comes in two parts: the Helm client and the server, also known as Tiller.
Helm Version 2 Architecture
In version 2 of Helm, whenever you deploy a Helm chart using the command helm install my-chart, the Helm client sends the values file to Tiller. Tiller runs in a Kubernetes cluster and creates components from the values file inside the cluster.
The architecture of Helm version 2 offers an additional valuable feature, which is Release Management. Whenever you create or change a deployment, Tiller stores a copy of each configuration client for future reference. This creates a history of chart executions, allowing you to roll back changes in case an upgrade goes wrong.
Helm Upgrade and Helm Rollback
With Release Management in Helm version 2, when you execute the command helm upgrade chart-name, the changes will be applied to the existing deployment instead of removing it and creating a new one. This is possible because of the chart execution history that Tiller keeps whenever you send requests from the Helm client to Tiller.
In case an upgrade goes wrong, for example, if some values files are faulty or if some configurations are incorrect, you can roll back the upgrade using the command helm rollback chart-name. This will revert the deployment to the previous version.
Drawbacks of the Tiller Setup
However, there are some drawbacks to the Tiller setup in Helm version 2. One of the biggest issues is security. Tiller runs as a privileged service account, which means it has full access to the Kubernetes API. This can be a security risk in certain environments.
Additionally, the Tiller service is not supported in Kubernetes clusters with Role-Based Access Control (RBAC) enabled by default, which is an important security feature. In such environments, users have to manually set up RBAC for Tiller, which can be complex and error-prone.
Conclusion
Release Management is a crucial aspect of Helm, and Tiller in Helm version 2 offers a robust solution for managing releases. However, the security concerns associated with Tiller make it less than ideal for certain environments.
In version 3 of Helm, Tiller has been removed, and release management is handled differently, addressing many of the security concerns. However, for those still using Helm version 2, it’s important to understand the architecture of Tiller and how it handles release management.
