flux2 VS helm-operator

My go-to stack is Prometheus and Grafana with kube-prometheus-stack chart. I'm sure I'm not configuring it well. There are too many leaps I couldn't follow directly, and there's something about how arrays merge in YAML that makes it harder to write a config like this in Helm... but this one goes so far as making alerts to Slack with Alertmanager that work out of the box

https://github.com/kingdonb/flux2/blob/monitoring/manifests/...

:sunglasses:

Using Helm via GitOps, you can pass in ridiculous collections of values that you would never use on the command line, mixing in secrets from secret sources, here is a complicated example (and here is a simpler one that doesn't do any patching.) Hope this helps. Usually when I show people Helm Controller, the reaction I get is "that's exactly what I wanted."

You can store the values file of the helm in your repository and deploy with CI, but I personally prefer going to GitOps and Helm Operator (https://github.com/fluxcd/helm-operator) Or you can have a mixed approach where you define your HelmRelease to be deployed for HelmOperator and deploy it with CI (instead of having an operator in the cluster to apply every change in the repo)

Nothing prevents you from making an operator that creates Deployment/Services/Ingress for you.

This is even simplified with Helm (to template your resources) and the HelmOperator[1].

[1] - https://github.com/fluxcd/helm-operator

I think you should check out flux and flux helm operator. https://github.com/fluxcd/helm-operator/stargazers

fluxcd/helm-operator (Go): The Flux Helm Operator, for declarative Helming