I can appreciate the effort that went into this, but I don't really understand its appeal, or even the appeal of Helm, when installing anything on Kubernetes is as simple as running `kubectl apply -f <manifest.yml>`.
For my personal cluster, I have a private Git repository filled with various singleton manifests that help me bootstrap various different things. Most "standard" installs (nginx-ingress, cert-manager, istio, etc) provide their own single manifests as well.
I feel that introducing layers of abstraction on top of that is generally unnecessary, but particularly because it doesn't really help you understand how K8s works.
It's just a templating solution. There can be many places you'd need to make edits in a collection of manifests that make up a particular app deployment. I've avoided it for this and security concerns but Helm 3 has resolved my issues with security.
Expect I'll be creating a chart for our fairly complex application stack very soon.
> I can appreciate the effort that went into this, but I don't really understand its appeal, or even the appeal of Helm, when installing anything on Kubernetes is as simple as running `kubectl apply -f <manifest.yml>`.
True at a certain level of abstraction, and like another reply says at heart helm is "just" a templating system. However you'd be doing a lot of kubectl apply-ing to replicate the functionality and configuration options of, say, the stable prometheus or nginx-ingress charts. At its best helm really is the package manager its designers aspired for it to be, and if the work is done to create good charts you can get a lot done with a 'helm upgrade --install'. That said, although we use it extensively for infrastructure-level pieces like the examples above, we find it too complicated and indirect for deploying our own services. For that we use kustomize (which is in kubectl now) to apply yaml patches and kubectl to deploy the manifests.
For my personal cluster, I have a private Git repository filled with various singleton manifests that help me bootstrap various different things. Most "standard" installs (nginx-ingress, cert-manager, istio, etc) provide their own single manifests as well.
I feel that introducing layers of abstraction on top of that is generally unnecessary, but particularly because it doesn't really help you understand how K8s works.