So, you’re using Kubernetes to manage your cloud’s containers. Good for you for jumping on the Kubernetes bandwagon. But, how do you load programs into those containers in the first place? There are several answers, but the one which has the blessing of the Cloud Native Computing Foundation, the parent organization of Kubernetes, is Helm.

Helm is a command-line interface (CLI) package manager. If you think of it as the Kubernetes take on Linux’s APT or Yum, you wouldn’t be far off. Indeed, the syntax is often nearly identical. For example, to install the web server Nginx on an Ubuntu Linux server, you’d use the command:

$ apt install nginx

To install the program on a Kubernetes cluster, you’d type in:

$helm install nginx

And, ta-da, Nginx is ready to run on your cluster.

It all looks very familiar but, under the hood, there are differences. Apt’s dpkg and Yum RPM packages are rather complex. Helm uses its own simple Helm charts. These are text-based YAML files, which you can manage with your favorite source code management (SCM) tools.

Another key difference between Linux and Helm package management is that, with Linux packages, you’re limited to one version. With Helm you can have multiple Helm charts, or releases, ready for your cluster.

In addition, unlike Linux package managers, you can install multiple programs. So, for example, you could install WordPress, its MySQL database, persistent storage, and a web server on a cluster all in one chart.

So, since a release is a single instance, you can install the same chart multiple times on the same cluster. If you want two DBMSs running on your cluster, you simply install a MariaDB chart twice and, there you have it, a pair of MariaDBs databases are running on your cluster. Each has its own release, with its own release name, so they’re easy to manage.

You can keep your own Helm charts repositories for your private use. Or, you can use public Helm sites such as KubeApps Hub. Be wary of such sites though. You never know when the chart you download will install the software you wanted … and a malware bitminer program along with it.

Helm is more than just a package manager though. With a Helm chart you can also specify the Kubernetes resources and configuration for your program.

You can also use Helm with continuous integration, continuous delivery, and continuous deployment (CI/CD) pipelines. Thus, you can, for instance, make sure your servers are upgraded before Helm installs the software specified in the chart.

Like its Linux package manager relations, you can do more than just install programs. You can also use Helm to upgrade, rollback, and uninstall programs.

What’s new in Helm 3.0?

The latest version, Helm 3.0, while incompatible with earlier editions, has added some very worthwhile features. Topping my list are the changes to Helm’s security model, which now relyies on Kubernetes for security, identity, and authorization rather than trying its all too-simple to be safe model.

It did this by removing Tiller, which had made it possible for multiple different operators to use the same set of releases. Now release names and other release-specific data are kept in the release’s namespace.

The new Helm has also made it easier to do rollbacks. With earlier versions, you could sometimes end up in situations where you’d call back to the earlier working version of a program and not be able to get there.

Another simple — but really useful — addition is that you can now impose a JSON schema on a chart’s values. That way, a developer or admin can’t get away with putting in an insane value into a production chart like, say, having an entry on a chart calling for zero instances of a program to be run–.

Put it all together and with Helm you get an easy way to install and manage programs within Kubernetes orchestrated clusters. Better still, whether you’re an old school shell sysadmin or a DevOps-savvy CI/CD developer, you’ll find Helm comfortable to use.