OpenShift 4.3: Deploy Applications with Helm 3

Helm is a package manager for Kubernetes which helps users create templated packages called Helm Charts to include all Kubernetes resources that are required to deploy a particular application. Helm then assists with installing the Helm Chart on Kubernetes, and afterwards it can upgrade or rollback the installed package when new versions are available. Helm Charts are particularly useful for installation and upgrade of stateless applications given that the Kubernetes resources and the application image can simply be updated to newer versions. 

Helm 2 was based on a server-side component named Tiller which was responsible for performing Helm operations on Kubernetes clusters. Tiller was designed prior to Kubernetes role-based access control (RBAC) and although useful for single-tenant clusters, its permissive configuration could grant users a wide array of unintended permissions. Therefore it was recognised as a major security concern on multi-tenant clusters, which prevented many enterprise users from using Helm in production environments. OpenShift is an enterprise Kubernetes platform, and therefore we didn’t recommend the use of Helm 2 in production, even though it was possible to disable OpenShift security features in order for Helm 2 to be used on OpenShift.

Helm 3 was recently released as GA in the Helm community, and a major update has been removing Tiller and pivoting to a client-side architecture to address the aforementioned security concerns, removing the barrier tor using Helm in enterprise environments. OpenShift welcomes this change with open arms, and we are thrilled to announce that OpenShift 4.3 supports Helm 3 as a Tech Preview feature. It is planned for full support in upcoming releases of the platform.

Helm binaries are distributed alongside oc, odo and other OpenShift tools. 

Try out Helm 3 on OpenShift by following the instructions in OpenShift documentation.

New in Helm 3

Helm 3 introduces many large and small enhancements, a few of which are detailed below:
Tiller is gone: Helm 3 removes Tiller as the server-side component that managed Helm Charts and moves to a client-side model where all operations are performed via the Helm 3 CLI while relying on Kubernetes RBAC for authorization and security features. When a user instructs the Helm CLI to install a Helm Chart, the information about the Helm Chart is fetched from the repository, rendered on the client and then applied to Kubernetes while a record of this installation is created within the namespace (which is known as a Release). 

Releases in namespaces: Release information in Helm 3 is stored in the same namespace with a secret as the storage mechanism for the Release information

Three-way strategic merge patch: Upgrades have moved to a 3-way merge, compared to 2-way merge in Helm 2. In other words, Helm 3 takes the live state of the application resources into account in addition to the manifests in the old and new Helm Charts, and therefore preserves any manual or automatic (e.g. Horizontal Pod AutoScaler) changes that might have been applied to those resources. 

OCI Registries for charts: As an experimental feature, Helm 3 is exploring use of OCI Registries for storing and distributing charts. This would allow user to take advantage of security and provenance features that are available in these registries.

Chart validation: JSONSchema support is added to Charts in order to define a structure for the values supported by the Chart. The Helm CLI then uses this schema for validation of the values that the user provides to the Chart. 

Improved CRD support: Kubernetes Custom Resource Definition (CRD) installations are improved by treating them as special resources. Helm 3 installs the CRDs included in a Chart first, waits until they are made available on the Kubernetes API and then continues the installation of the remaining resources from the Chart.

Library charts: a class of charts called “library charts” are introduced in Helm 3 in order facilitate sharing snippets of code between charts and to encourage re-use. A library chart does not install anything and can only be defined as a dependency in other charts. 

For a more exhaustive list of updates in Helm 3, refer to the Helm 3 documentation.

Migration to Helm 3

Most existing charts are compatible with Helm 3. However, given that Helm 3 takes advantage of the Kubernetes security model while Helm 2 did not, there may be adjustments needed in order for your existing charts to be able to deploy properly without Tiller. You can read more on how to migrate from Helm 2 to Helm 3 in the Helm 3 documentation.

Next on OpenShift

For future releases of OpenShift, we are working on a tighter integration of Helm 3 into the OpenShift tools and web consoles. OpenShift embedded developer catalog, which is the central hub for all developer content, will add support for Helm Charts in addition to Operator-backed services, Templates, etc. Furthermore, integration with Helm releases is planned next in order for developers to be able to manage Helm releases directly from the OpenShift developer console.

We are very excited for the Helm 3 roadmap on OpenShift. Stay tuned...