bootstrap-repo VS helm-operator

So why am I telling you all this? Because this is how I point Kubernetes ingresses at apps which live outside the clusters. It's not entirely clear that is what you wanted, but hope this helps. I have more examples, there's a bit more to what I'm doing, since at the bottom line what I wanted was to use my one public IP address to manage more than one service. So that's where Traefik comes in, https://github.com/kingdonb/bootstrap-repo/blob/main/apps/routers/urbit-ships/socryx-topled-ingressroute.yaml

I save them to git, and restore them using GitOps. https://github.com/kingdonb/bootstrap-repo

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