3 ms·
Most people in this thread, it seems, just want a simple way to manage Kubernetes manifests, something that keeps track of different settings for different envi
by solatic 11mo ago
Most people in this thread, it seems, just want a simple way to manage Kubernetes manifests, something that keeps track of different settings for different environments and what's in common for each environment in order to generate the final manifests for an environment. If so, Helm is over-engineered for your use-case. Stick with Kustomize or jsonnet.
Helm's contribution (as horrible as text templating on YAML is) is, yes, to be a package manager. Part of a Helm chart includes jobs ("hooks") that can be run at different stages (pre-install, pre-upgrade, etc.) as well as a job to run when someone runs "helm test", and a way to rollback changes ("helm rollback"), which is more powerful than just rolling back a Deployment, because it will rollback changes to CRDs, give you hooks/jobs that can run pre- and post-rollback, etc.
Helm charts are meant to be written by someone with the relevant skills sitting next to the developers, so that it can be handed off to another team to deploy into production. If that's not your organization or process, or if your developers are giving your ops teams Docker images instead of Helm charts, you're probably over-engineering by adopting it.
- hylaride 11mo agoThe core problem, I think, is that K8s is overly complicated for 95% of deployments out there, but it's become the default standard. People then start creating tooling to mask some of the complexity, but then said tooling grows to support the full K8s feature set and then we're back to square one. Because the rush to K8s was so fast (and arguably before it was ready) the tooling often became necessary. > Helm charts are meant to be written by someone with the relevant skills sitting next to the developers. That makes sense for large organizations, but it still gets complicated depending on how your service plugs into a greater mesh of services. I currently treat helm the same way I treat Cloudformation on AWS (another horrid thing to deal with). If some third party has it so that I can easily take the template and launch it, then great. I don't want to go any further under the hood than that.
- aduwah 11mo agoCRDs in helm are such a freaking nightmare! You want a clean install because you are in a hole? No worries let's remove all the crds and delete/create everything else relying on them. Separating the two (crds and other objects) is a solution but then you have a bastardize thing to maintain that is not latching upstream Also I cannot count how many times I had to double/triple run charts because crds were in a circular dependency. In a perfect world this must not be an issue but if you want to be a user of an upstream chart this is a pain