Introducing Helm Operator 1.0
Today, we’re happy to announce the release of Helm Operator 1.0! With the Helm Operator you can now declaratively manage Helm releases with GitOps. Read more on the blog.
We are happy to announce the release of Helm Operator 1.0!
The Helm Operator enables you to declaratively manage your Helm releases with GitOps best practices. Version 1.0 comes with the promise of a stable API, support for Helm 2 and 3, and a rich featureset.
- Supports Helm 2 and 3
- Declaratively installs, upgrades, and deletes Helm releases
- Pull charts from any chart source;
- Public or private Helm repositories over HTTP/S
- Public or private Git repositories over HTTPS or SSH
- Any other public or private chart source using one of the available Helm downloader plugins
- Allows Helm values to be specified;
- In-line in the HelmRelease resource
- In (external) sources, e.g. ConfigMap and Secret resources, or a (local) URL
- Automated purging on release install failures
- Automated (optional) rollback on upgrade failures
- Automated image upgrades using Flux
- Automated (configurable) chart dependency updates for Helm charts from Git sources on install or upgrade
- Detection and recovery from Helm storage mutations (e.g. a manual Helm release that was made but conflicts with the declared configuration for the release)
- Parallel and scalable processing of different HelmRelease resources using workers
A bit of history
The Helm Operator project started in 2018 as a side project of Flux, with the goal of making it easier to migrate from a CI workflow to a GitOps driven one. It works by introducing a custom resource to declaratively describe a Helm release, using the existing Helm charts in your organization. The custom resource is recognized by Flux as a workload with images, enabling updates to image references. This allows for automated image updates.
At the start of the project, the support for Helm features was slim, and the operator was only able to perform installation and upgrade actions on healthy releases, requiring manual interference when a release failed. This changed when support for rollbacks was added, making it possible for the operator to recover from release failures, and re-attempt whenever a new change was made to the `HelmRelease` resource and/or chart.
More recently we added support for: Helm 3, values from ConfigMap and Secret resources, Helm downloader plugins, and HTTPS protocol support for charts from Git sources. These further matured the project, to the state of the 1.0 release brought to you today.
To get started with the Helm Operator:
- Follow the quickstart guide
- Get familiar with the
- Follow the progressive delivery hands-on
- Browse through the documentation
There’s enough work to go around, and we are always looking for new contributors. If you are interested in contributing to the project, issues labeled with ‘help wanted’ are a good starting point. If you have any questions about Flux, the Helm Operator or progressive delivery, invite yourself to the CNCF slack and join the #flux channel.