Ecosystem complexity increases every time we look around, our dizzying panoply of choices multiplies by the day, and (now, as always) we need a way to find, share, and operate applications reliably, in production, and at scale. What’s a busy Kubernetes user to do?
Helm is the well-known and much-used package manager for Kubernetes. If Helm is new to you, you’re in luck! Join in using Helm, one of the most popular tools in the cloud native toolbox – it’s great for managing the complexity in your applications, sharing configurations, and easily versioning your updates for maintainability.
Helm 3 (now available!) is an evolutionary improvement, bringing enterprise-grade security and increased usability. Enhancements in Helm’s security and stability are in direct response to and in coordination with community needs, as Helm is a widely-used Incubating Cloud Native Computing Foundation (CNCF) project, with an open source community numbering in the hundreds of contributors shaping its decisions.
Being almost as old as Kubernetes itself, Helm originally evolved with some configuration options which were parallel but not entirely congruent with Kubernetes. Rethinking Helm 3 from the ground up let the community bring Helm’s permissions model, command-line switches, RBAC, and more in line with current Kubernetes implementations. The Helm team edited the Helm 3 architecture carefully and removed the server-side component known as Tiller, which was obviated by improvements to Kubernetes in the years since Helm 2’s design. Helm 3 is simultaneously simpler and supports more modern security, identity, and authorization features of Kubernetes.
“Sounds exciting!” you may say. “How do I get started?” You can use Helm 3 immediately whether or not you’ve used Helm before. If you have Helm charts you’ve been using with Helm 2, you will want to read about essential changes, but most charts will work unmodified. A migration guide and Helm 2to3 plugin will help you make the move. And you may find that while you don’t need to rewrite your charts right away, you’ll delight in the new library charts, which will help you de-duplicate configs you use across many charts for consistency and security.
Release information is now stored in the namespace with the release. This enables you to use a release name on a per-namespace basis, instead of being limited by all releases needing to share the same Tiller namespace. (One side effect of the removal of Tiller!) And the re-imagined three-way strategic merge patches allow the old and new state on disk to be examined in the context of the live state in the running cluster. This prevents unexpected incidents caused by uncommitted production updates.
“But wait…” comes the worried exclamation. “I don’t have time to change anything right now!” Good news: Helm 2 will get bug fixes backported for six months and security patches for a year, so you can update at the pace that fits your organization’s needs. And backward compatibility is emphasized – if you want to keep using previous command-line flags, in many cases that option is available. The Helm FAQ covers the breaking changes, and the Helm blog post on this major version release dives into the technical details you’ll want to know.
Of course, any major shift in an open source project comes with changes, and the upstream chart repository of yore will be one of those – we’re looking at pushing charts to Open Container Initiative (OCI) registries to ameliorate limitations of the Chart Repository API. Experimental features like OCI support are a great place to look if you’d like to get involved with the direction of the project – testing and feedback are valuable contributions.
Open source means giving back to the community and the Helm Go SDK has proven so handy for our needs that we’ve refactored it to allow for broader use. If you’ve integrated Helm into other projects, we’d love to hear from you!
Whether in person at KubeCon + CloudNativeCon next week or on our weekly community calls, Slack, mailing lists, GitHub, and more, the Helm maintainers are delighted to hear what’s working, what needs improvement, and how you’re using Helm to make package management in your Kubernetes clusters simpler and more secure.