Helm is a wannabe package manager, designed for people who really like writing yaml instead of executable code. K8s doesn't really have a fully built out "apps" resource, so that starts the whole process down a gravelly slope of pain... with initial care and if your team need to groom their k8s configs, you can go a long way with helm before the pain starts. A particular problem with helm is that it isn't really a fully fledged programming language, but a glue laid over the golang templating system.
I use helm as little as possible. Usually only enough to template out a single file with the different bits of k8s infra stuck together with `---`.
If I was doing some relatively serious work on custom services with minimal needs to conform to best^H^H^H^Hpopular practices, my service's configuration would be a neatly packaged Java program (its libraries for K8s direct API access are good).
There are different approaches to handling ops tasks; I favor the ones that are rooted in writing executable code over the ones with yaml.
Some bright chappie will probably write a Common Lisp library derivation library and k8s will be obvious and simple with that interface, but I'm not that bright - all I can see is the potential.
I use helm as little as possible. Usually only enough to template out a single file with the different bits of k8s infra stuck together with `---`.
If I was doing some relatively serious work on custom services with minimal needs to conform to best^H^H^H^Hpopular practices, my service's configuration would be a neatly packaged Java program (its libraries for K8s direct API access are good).
There are different approaches to handling ops tasks; I favor the ones that are rooted in writing executable code over the ones with yaml.
Some bright chappie will probably write a Common Lisp library derivation library and k8s will be obvious and simple with that interface, but I'm not that bright - all I can see is the potential.