[sklarsa]

Why not use helm? I'm looking into spinning up (and eventually productionizing) a k8s cluster at my job and I was leaning towards using helm since some pieces that I was thinking about using are installed via helm charts (https://github.com/kubernetes/ingress-nginx for example)

[solatic]

If you use third-party Helm charts, you eventually need to add onto the generated objects in a way which the chart doesn't support, and then you're up a creek without a paddle. This is precisely the use case which Kustomize tries to fix and it was the only real strength which Helm had to begin with (i.e. the ease of installing third-party software on your cluster).

In the meantime, because you must install Helm into every namespace in your cluster into which you desire to install charts, it's a massive resource hog and security risk. Charts themselves also need to be hosted somewhere, so you end up needing to install Chartmuseum, Harbor, or Artifactory (if you didn't have Artifactory already), and they have their own operational costs.

[navd]

I thought it would be useful to add that you can also generate k8s manifests from a helm chart using the `helm template` command.

I'm in the same boat where I avoid helm if at all possible.

[alexandre_m]

That only works for local checked out copy and not remote repo URL, unfortunately.

[alexandre_m]

Something not pretty, but that works well for me, is using yarn to manage dependencies on upstream Helm chart repositories, then use kustomize to override certain things if required.

That checkouts a local copy locked at a specific version, which you can bump easily, and allows overriding the template definitions on your side.

No need for additional infrastructure.