What we learned at the first Helm Summit

What a great inaugural Helm Summit! This was a momentous occasion for the community. What started as a hackathon project just under three years ago now is having its own community-driven summit.
We had close to 200 people gather in an uncharacteristically snowy and cold Portland, Oregon talking about all things Helm. Over the 2 days we were together, we learned about how members of the community are using Helm in a CI/CD pipeline and using it to manage their environments. We heard some valuable lessons learned, pain points, tips and tricks, and solutions, as well as successful discussions of the future of Helm.
Let’s review what we learned and the next steps for Helm 3.0. If you are looking for the recordings of the talks, you can find them here.

Where we came from and the current focus of the Helm community

We kicked off Helm Summit with a history of the Helm project and how it got to where it is today. The rest of the morning was spent seeing how community members push Helm to its limits with CI/CD using Helm and managing thousands of releases with an operator like Lostrómos. Several speakers also showed their work with the popular new tool  ChartMuseum and how they used it in testing and deployment.
The second half of the day contained some deep dives on deploying multiple environments with Helm and how to test large chart repositories. Bitnami and Microsoft detailed the latest iteration of KubeApps with its support for Open Service Brokers and one-click installs of applications. Finally, we heard about the hot topic of how to secure Tiller, what parts of Kubernetes Helm interacts with, and how to secure those endpoints.
We closed out the day with lightning talks from across the entire community spectrum. Rajashree Mandaogane showed us a handy trick for rolling deployments when a ConfigMap changes, while Jimmy Zelinskie and Nikhil Manchanda both proposed ideas for a public App Registry or Chart Repository for Helm users, much like how DockerHub and Quay is for users of Docker.
What stood out most to us was the diverse set of companies and use cases presented. All of these talks were enlightening for the community as we learned about the different ways in which people used Helm. These were a perfect way to set the stage for the needs of the community as we went into Day 2 talking about the future of Helm.

The Future of Helm

The second day was all about the future of Helm, and it was exciting to see so many people invested and looking forward to participating in the discussions. Matt Butcher and Matt Fisher (2 of the 3 core maintainer Matts) set the guidelines for the day on how to approach planning Helm 3 as a community.
Throughout the morning, several people from the community presented well thought out proposals for Helm 3. Others gave 1-2 pitches for topics they wanted to discuss on the future of Helm. These included:

• Unified aliases, dependency, and value mapping functionality
• Tiller implementation using CRDs and a custom controller
• Better chart searching
• Measuring Helm usage
• Improvements for managing charts

Brian Grant presented an interesting idea to separate Helm and Tiller into composable tools for the Kubernetes ecosystem. This is an idea that many people expressed interest in implementing.
We finished off the morning with a Q&A panel with the Helm and Charts core maintainers. What struck us as most interesting was the number of questions related to the management of charts and how to handle the growing number of them in the repository.
The rest of the conference was spent in unconference-style working groups, where we discussed the various proposals and ideas pitched by others in attendance. We used this time to gather requirements and debate different ideas and needs.

Requirements

So then, what are the requirements we found? The full notes from the working groups can be found on GitHub, but we have broken up these requirements into 3 categories below for Helm, Tiller, and Charts. These are what we have identified as suggestions for requirements from the Helm community .

Helm

• Users should be able to push/upload a chart to a chart repository using the Helm CLI
• There should be a way to specify release dependencies (e.g. a release named “my-release” must exist in order to deploy the release they are installing)
• Users should be able to dynamically override non-templated values in an object
• Template engine plugging should be easier
• Templating should use an overlay to add on additional data
• Helm linter should allow for flexibility and customization
• Helm should have full YAML support (for things like anchors)
• There should be a curated list of plugins
• Plugins should have a starter or library to use so people don’t have to write it all from scratch
• Re-work the existing `helm test` framework so releases can be more thoroughly tested (this is a very large requirement, see the notes for more details)

Tiller

• Tiller will become a custom controller that leverages some sort of CRD
• Remove Tiller entirely in favour of a pure client-side implementation
• Tiller should have a way to interface with application lifecycle management (the current idea being to have a way for Operators to report back to Tiller on the status of the application lifecycle)
• Tiller must be able to enforce RBAC rules for a user making the request
• Support external storage engines for Tiller

Charts

• Backwards compatibility must be maintained with Charts (all changes will need to be a new chart API version)
• Better measurement of chart usage metrics
• More performant chart index (whether through a new v2 spec or a distributed index)
• Create a chart adoption process for bringing charts into the main charts repository

We will be discussing these requirements in upcoming dev calls to solidify the actual requirement and then we will move them to the Helm repository.

Open Questions

Based on the discussion, there are several open discussion points that need to be resolved.

• How much of Brian Grant’s proposal to separate the parts of Tiller should be implemented? There is a good case from the Helm developer side of things that would make things more modular. However, from the user perspective, this may not be desired as it has the possibility to make things harder to use (more assembly required)
• Should template rendering be moved client-side again?

Thanks

From all of the Charts and Core maintainers, thank you so much for all of the support to hel(m) make this summit a success. The talks and energy at the conference were nothing short of spectacular, and we are truly proud to be a part of this community. We are looking forward to scheduling other Helm Summits in the future in Europe and in North America again so we can reach as much of the community as possible. The support from the Helm community is what made this event great and we look forward to continuing to work with all of you.
Any questions for feedback? Please let us know in the comments.
 

Taylor Thomas

Taylor is a software engineer at Nike and a core contributor to the Helm project. He is a Gopher by way of Node.js and is an regular open source contributor. He enjoys building scalable and maintainable systems using containers and (currently) Kubernetes.

See more articles from this author