Update to Kubernetes’ Helm Package Manager Could Simplify App Deployment
The Helm package manager for the Kubernetes orchestration engine has been updated, simplifying commands and reducing external dependencies in order to make it easier than ever to deploy applications on K8s clusters.
Helm is a project begun last year by Deis, whose principal architects — Matt Butcher and Jason Hansen — envisioned a kind of crowdsourced model for configuring the deployment of different workloads under various circumstances.
Helm uses packages, called “charts,” that contain templated Kubernetes resources for deploying apps onto a Kubernetes cluster. Helm also manages these releases once deployed.
In a Kubernetes community video released last June, Butcher introduced an alpha build for the first release candidate of Helm 2.0. “Basically, what we’re doing now is, we’ve got three big parts,” Butcher said. “We’ve got the command-line Helm utility, which communicates with the server over gRPC; we’ve got the server-side component, whose job is basically to take packages, deploy them into Kubernetes, and manage them; and then we’ve got this third concept, which is the repository.”
He explained how Helm acts as a kind of configuration client, whose counterpart — naturally called Tiller — manages interactions from a server-side pod. When Helm presents Tiller with the manifest for an application to be launched, Tiller effectively plots the course, evaluating the manifest charts (referred to earlier) and applying them against the current system configuration. The product is an up-to-the-second set of deployment instructions which may then be fed upstream to Kubernetes.
“A chart is like a bundle of pre-fabbed Kubernetes resource files and manifests, with template support and things like that,” Butcher told the community. “We wanted to build something that made it as easy to install new stuff into Kubernetes as it is to say, like apt-get install nginx or yum install wordpress, or something like that.”
The first version of the package manager, now retro-dubbed “Helm Classic,” was strongly modeled after Homebrew, the package manager made for MacOS (yes, Mac users do use the Terminal prompt). Helm 2.0’s commands, as Butcher demonstrated, were somewhat simplified from “Classic,” allowing a single command for creating a chart from an existing file, and a single command for building a tarball package around that chart for distribution.
The new package manager removes some of its predecessor’s dependency upon GitHub as a repository for sharing charts, moving instead to a much more generic acceptance of any file system navigable through HTTP. Helm’s new repository system, said Butcher, enables the sharing of charts to be scoped, so that some may be designated as applying to an entire organization, while others may be restricted to use only by named individuals.
According to its company blog, Deis manages two official Helm repositories: stable, which contains tried-and-proven configurations for widely used applications such as Jenkins and MariaDB; and incubator, which features charts that the Helm team would like to promote, but whose results cannot be guaranteed in all circumstances.
At the time of his demo five months ago, Butcher noted that one major feature had yet to be implemented — a way of rolling back the deletion of a pod. As planned, Tiller would retain the state information for a pod removed from a cluster. This way, a pod has a narrow window of time in which it could be resurrected, especially in the event of an accidental removal. But to specify which pod needs to be undeleted, some record of its state had to exist, which wouldn’t necessarily be the case if the pod was deleted — which leads to the reverse chicken-and-egg conundrum Butcher and his colleagues were facing at the time. Thursday’s release indicates they’d come across a solution.
In a blog post Thursday, Butcher credits Google, apps deployment platform Bitnami, and Kubernetes-oriented consultancy Skippbox with collaborating on the Helm 2.0 project. “The result,” he wrote, “is a tool that not only makes teamwork a central value, but also one designed to meet the needs of a burgeoning community of Kubernetes users who are installing sophisticated applications.”
Bitnami is a sponsor of The New Stack.