The Cloud Native Computing Foundation (CNCF) announced today that the open source Helm package manager for Kubernetes has become the 10th project to officially graduate.
Started in 2015, Helm traces its lineage back to an open source Deis project to build an open source platform-as-a-service (PaaS) environment that Microsoft later acquired. In 2016 Helm was merged with a Kubernetes Deployment Management tool and then in 2018 became its own project again within the CNCF.
The current Helm 3 release is already widely employed within Kubernetes environments to install applications using what are known as Helm Charts, which are a set of files that describe a related set of Kubernetes resources.
Over the years there have been more than 13,000 contributions made to Helm, with companies including AT&T, Bitnami, CERN, Conde Nast, Microsoft and VMware all using it in production environments.
Matt Farina, a software engineer for Samsung SDS, a technology services provider who is also a maintainer of Helm, says Helm greatly simplifies what otherwise would be a complex, time-consuming task of installing applications on a Kubernetes cluster. The more complex the application the more important it is to have a package manager to navigate the process.
He notes one of the biggest challenges facing the Helm community at the moment is deprecating the previous version of the package manager, which many organizations still employ to install applications. Much like previous versions of Kubernetes, older versions of Helm Charts created prior to that release of Kubernetes may no longer work, as the application programming interfaces (APIs) for Kubernetes have evolved.
In the meantime, work on Helm continues. In addition to tools that make Helm a more natural extension of a DevOps process, Farina says the community is closely watching the evolution of the Open Container Image (OCI) specification. The teams working on that project have created a prototype of a portal that would allow containers and Helm charts to reside in the same repository.
In general, there is some overlap between Helm Charts and Operators, which also are employed to deploy applications. Developed originally by CoreOS, most Operators are installed using a Helm Chart. However, many Operators also include operations lifecycle management tools that are employed to update that specific application. Operators are specific to a single application, while Helm Charts can be employed to install multiple components of an application.
Farina says there clearly more work needs to be done to make Kubernetes clusters more accessible to the average IT administrator. In some organizations, dedicated DevOps teams have the expertise required to manage Kubernetes clusters. However, there are just as many organizations that are likely to have dedicated Kubernetes administrators who manage the building and updating of Kubernetes clusters.
Regardless of the approach to managing Kubernetes clusters, the one thing that is for certain is that operationalizing Kubernetes at scale within the enterprise will require a bevy of tools to abstract away a lot of inherent complexity.