This is something a lot of users have asked about, and it’s worth discussing in detail, especially with the input from more savvy Helm users.
The question is whether or not Helm packages will be supported in the V2 provider. It’s a natural question, since the whole point of the provider is to unlock manifest-driven deployments, and Helm adds a lot of great tooling making deploying Kubernetes manifests easier. However, my initial thoughts on this are:
Helm is best suited for ready-to-deploy style applications that are not being developed by your team. It’s great for dropping in a Redis or Kafka deployment without much worry about how to run it or apply tested updates. This isn’t really what Spinnaker is made for. Generally when you deploy something with Spinnaker, it’s an application that you’re actively developing, where 1-click deployments aren’t guaranteed to succeed. You want that additional safety that Spinnaker adds, whether it’s via an automated canary strategy, traffic guards, artifact promotion across environments, first-class feature-flag support, etc… Helm clearly has a place in your deployment workflow, but it’s really complementary to Spinnaker in what it’s intended for.
As a result, if you want to rely on Helm as a supplement to Spinnaker, at any point in time you’re able to call out to a “Run Job” or “Run Script” stage that invokes
helm applyfor you. The types of things that work best with Helm don’t need integration with all the extra tooling that Spinnaker provides for applications that you’re developing.
And finally, there are some technical challenges/limitations that make this difficult. For example, the new Kubernetes provider relies heavily on the
metadata.annotationsfield, which Helm does not expose to you. Also, artifacts like ConfigMaps that Spinnaker now treats as a first-class citizen are also handled very closely by Helm. A clear division of concerns is important here.
I’d love to hear what current/prospective users think.