It sure is a leaky abstraction [0]. I would argue that the benefit of it is when spinning up your first Kubernetes cluster, the many community charts created by default can be installed easily with a > helm install stable/mysql.

However, it fails when the reality of running a service in production hits and you need to dive into changing a Chart template, requiring knowledge of not just the Kube API but also more often than not ugly template-fu to get the changes that you want reflected.

I really just recommend using raw K8s resource files for almost everything unless you are managing hundreds of similar releases.

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

Agree. We built a management layer to take a DSL that was essentially kube yaml without the boilerplate required for common stuff and piped it on through.

If you’re using Kube you need to understand Kube. Conveniences are great to accelerate common tasks but as you say at some point ya gotta get into the guts of it and tweak things.

Using basic K8S resource files requires a lot of duplication, when using Kustomize or Helm isn't supposed to be that difficult to create an abstraction so that you can adopt you templates for multiple environments/purposes and inputs. With library charts in Helm 3, this should help even more to create a list of standard services or dependencies within your template files that can be quickly adopted throughout the organization. Once you have a few templates, then they can be quickly adopted.

Helm is a package manager in the same line as apt, yum, homebrew, and others.

A package manager lets someone who has knowledge of how to run an application on a platform (e.g., postgresql on debian) package it up in a way that others who don't have this knowledge can run an application without needing to learn it.

That's why I can use `apt install` regularly without needing to know the business logic of running all those apps on my system.

Package managers let you compartmentalize and automate expertise.

That might have been the intent of helm, but it does not at all reflect the reality of using it in the experience of most people I've spoken with, especially pre-3.0.

I've lost track of how many times helm has misrepresented the result of upgrade operations, even returning success when it actually failed, and what should be routine upgrades often break in ways that require detailed knowledge of both kubernetes and helm to recover from.

Yes, conflicts and failures do sometimes happen with package managers, but with helm we've seen it happen with nearly every Chart at some point or another, from the simplest single-resource pipelines to widely used community projects.

Helm 3 will help, but it's still built around the same messy string-templating system that ensures Charts are fragile and difficult to understand.