28 ms·
I think you are marketing this thing wrong. This has very little to do with helm. For me helm is primarily not a package manager, its a templating language and
by k8sagic 2y ago
I think you are marketing this thing wrong.
This has very little to do with helm. For me helm is primarily not a package manager, its a templating language and a way of configuring and installing it to a k8s cluster happens through kubeapps, helm cli or argocd.
This approach also kills for me the really awesome IaC paradigma: I bootstrap ArgoCD and after that, reference only git repos.
Your demo doesn't talk about HOW someone would use your templating features (like your 'form' support) but shows everything besides that.
I honestly like this as i'm still having the feeling that something is wrong with helm, but the way you are approaching it, i think it will fail. It will not gain enough traktion as bigger companies do not need your tooling. Kubeapps works really well and helm too (you want to replace helm, you probably will keep the helm support in there for a long time).
The problems helm have is: its getting convoluted when helm charts become big. The templating folder is a shit place for basically having everything in there, yaml is not that good for templating and values.yamls become way to big.
- redrove 2y agoI don’t mean for this to sound condescending or dismissive, BUT if you don’t think Helm is primarily a package manager you haven’t worked with infrastructure deployed in k8s much.
- k8sagic 2y agoI'm running a 500 node cluster, 3 private ones and 5 in an opensource context. I see this primarily from a business/ops perspective and i do not install helm charts manually through the cli besides for testing. We provide kubeapps as the packagemanager / interface for providing helm charts and cirumventing package manager features of helm. For smaller use, we use ArgoCD for IaC and the helm charts are only there for having a package to reference. Again no usage of helm as package manager
- redrove 2y agoI’ve been doing this for about 8 years and have seen a few hundred clusters at dozens of orgs, been using GitOps for the last 4ish years. Invariably they all involved using helm as a package manager to deploy off the shelf infrastructure with minor adjustments. I still don’t see your point, we can just agree to disagree.
- k8sagic 2y agoI'm happy to discuss this topic and to clarify it. For me the 'package manager' aspects are more than the templating and having a zip file. For me it is more what apt etc. do So using helm and its remote repositories, using the helm cli etc. But we use kubeapps or ArgoCD to install the helm packages and download all helm charts before we deploy them (due to security requirements). We leverage 100% IaC. Therefore we bootstrap ArgoCD and than install everything through ArgoCD. Only helm charts for our customers/collegues are installed through kubeapps.
- redrove 2y agoI don’t doubt your experience and what you do at your org, yeah that falls into a bit of a different category since you use kubeapps. I guess what I’m saying is: in my experience across many organizations, helm is indeed treated more like a package manager (like I described above). Your workplace seems to be in the minority. Hope that made sense :)
- pmig 2y agoOur demo is more end user focused. You can find more information about our configuration options in our package configuration documentation: https://glasskube.dev/docs/design/package-config/ https://glasskube.dev/docs/design/package-config/