Guidance - Using one helmrelease to generate multiple helmreleases

[sssd-dev]

We have a use case to use the same helm chart to generate multiple clusters of a stateful application. Using a unique server.id we plan to have multiple such clusters which are going to be using same helm chart in the background. Currently we are using flux v2 to deploy single cluster and would like to have at least 3 such clusters in future. We would like to avoid have multiple helm releases and overlays and instead would like to explore to have single helm release being templated to generate multiple clusters. Is that a possibility?

[kingdonb]

This is the Flux v1 repo, for legacy Flux – (you might try opening a discussion on fluxcd/flux2 where there is more activity.)

I don't think that templating in Flux outside of what you have identified with Helm and Kustomize is a thing. The way to do templating is with a Kustomize overlay per environment.

If they can be identical, you can check out this approach:

Identical Environments

But if you wanted these releases to each have their own configuration and be deployed separately, there is no configuration that I can think of which would achieve that. If you want three different templated versions of a HelmRelease, you can either write three HelmReleases and repeat the repeated parts, or you can template using Kustomize overlays and/or patches for one HelmRelease. For three separate clusters to have different configurations, they would generally target different paths. The Kustomize Overlay is there to help keep things DRY.

I hope that one of these options is appealing, but I'd note that it may help more to include information about the reasoning why you have ruled out an option. You have identified one possible solution that you don't want to use, but it is not clear why that one is ruled out.

I could also suggest the Flux Kustomization patches directive as another potential alternative to investigate – that could avoid writing additonal overlays, but without understanding the reason why you ruled out multiple Kustomize overlays I can't say whether this meets your purpose well or not.

[kingdonb]

(Closing, as the Flux v1 repo is not the right place for this discussion.)

[kingdonb]

One other possibility is envsubst from a configmap. In the flux manual, this is called variable substitution – it can be done from any configmap.

So if you have a separate way of placing the relevant information on each cluster, say in a configmap, then you can deploy identical Flux kustomizations and/or HelmReleases to three different clusters, and get a different result on each. Maybe we should have a "styles of templating" entrypoint as the way you've phrased this question, there really are quite a few different answers, depending on what suits your requirements or subjective tastes.

(One might even say too many ways.)

[sssd-dev]

@kingdonb Thank you so much for your responses. I will open an issue in v2. I am seeking a way to avoid creating multiple helmreleases. So if there can be a way to create a helmrelease - name: helmrelease-{{ var }} and then substitute var to generate multiple helmreleases. After generating multiple helmreleases (on the fly) and then refer to them while applying via overlays.