**elm **(a tiller or wheel & any associated equipment for steering a ship or boat) is a package manager for Kubernetes. It was inspired by the Homebrew project & helps developers to easily package & distribute complex microservices that run on the Kubernetes platform.
Some history…
Fig2: History of the Helm project
- 2015: Helm was first introduced at KubeCon (Kubernetes Developer Conference) by a company called Deis (acquired by Microsoft)
- 2016: During the same time, GCS was trying to solve a similar problem with Kubernetes Deployment Manager, so Helm was merged into the Kubernetes project in early 2016. The merging of these two projects resulted in Helm v2
- **2018: **Seeing a quick raised in its popularity, Helm was later promoted to a fully-fledged CNCF project in 2018
- 2019: Helm v3 was released
Helm v2 introduced a server-side component called Tiller to manage charts. A Helm chart is a packaging format that contains all of the resource definitions necessary to run an application, tool, or service on Kubernetes.
Fig3: Ingredients of a Helm chart
Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.
Although it worked well for a while, the rapid evolution of Kubernetes meant that Helm had a lot of catching up to do. Helm v2 was inefficient in many ways: security, version dependencies & two-way merge strategy, etc., to name a few.
The Helm community took note of these drawbacks & released Helm v3; which primarily focuses on optimization (security & performance).
This article will help you understand the changes that went into Helm v3 & later we will discuss the steps to migrate a chart from Helm v2 to Helm v3.
What has changed in Helm v3?
Here are all the major changes introduced in Helm v3
- DEPRECATION OF TILLER
- Drawback
- Tiller made it easy for multiple users to interact with the same set of releases when using a shared Kubernetes cluster.
- Helm v2 followed a more permissive default security config which grants a user a broad range of permissions. Now, since role-based access controls (RBAC) has been enabled by default in Kubernetes, locking down tiller for use in production environments has become more difficult to manage.
- Secondly, Tiller’s primary goal of storing the state information could be accomplished by directly interacting with the Kubernetes API server.
- Enhancement
- Keeping the above two points in mind, the decision we made in Helm v3 to completely remove Tiller. With Tiller gone, the security model for Helm is radically simplified
2. IMPROVED MERGE STRATEGY
- Drawback
- Helm v2 used a two-way strategic merge patch. During an upgrade, it compared the most recent chart’s manifest against the proposed chart’s manifest. It compared the differences between these two charts to determine what changes needed to be applied. If changes were applied to the cluster out-of-band (such as during a
kubectl edit), those changes were not considered. This resulted in resources being unable to roll back to its previous state. - Enhancement
- In Helm v3, we now use a three-way strategic merge patch. Helm considers the old manifest, its live state, & the new manifest when generating a patch.
#google-cloud-platform #open-source #kubernetes #helm #containers
