[smetj]

Came here to feel the temperature of the comments, and unsurprisingly, most folks seem to have plenty of gripes with Helm.

A Helm chart is often a poorly documented abstraction layer which often makes it impossible to relate back the managed application's original documentation to the Helm chart's "interface". The number of times I had to grep through the templates to figure out how to access a specific setting ...

[cryptonector]

I don't understand why having to "grep through the templates" is so bad. Oh, I get it, you just want to know what knobs are available for tweaking, and in a well-designed chart those will all be segregated in values files, with overrides specified on the command-line as needed. And so that's what documentation is for, and if a chart does not surface certain knobs from the product, well, yeah, you'll have to modify the chart if you want it to.

What is the essence of the complaint here? That chart authors do poor jobs? That YAML sucks (it does! it so so does!)? Just that charting provides an abstraction you'd rather not have? (If so, why not just... not use Helm?) Something else?

[smetj]

> What is the essence of the complaint here?

As said, that I often cannot relate the managed application's documentation to the Helm chart's interface?

Reason for it can vary ... poor Helm chart documentation, poor Helm chart design, Helm chart not in sync with application releases, ... The consequence is that I often need to grep through its templates and logic to figure out how to poke the chart's interface to achieve what I want. I don't think that's reasonable to say that's part of the end-user experience.

PS: I have no gripes with YAML

[cryptonector]

None of that seems like a reasonable complaint about Helm itself, unless Helm makes it easy to write poor charts and never document them. When faced with shitty code with shitty docs, maybe the thing to do is to send a PR and make it better. At least a ticket.

[Too]

When 99% of all charts have this problem, maybe the problem isn’t with the individual charts, rather a symptom of a fundamentally dissonant abstraction model. The core problem is that it’s overkill. The solution to that is not to add or fix, the solution is to remove.

Why would I need a chart for a single container app? Making this simple is what Kubernetes is designed for. No, I don’t want your ServiceAccounts or PVs because I anyway need to grant and understand the permissions and select the size and SKU of the underlying disk.

Deploying an app in your own infrastructure has too many knobs that need to be turned so you need to expose all of them. Just spend a few minutes extra to write your own deployment manifest. While it’s a few more lines of code vs ”helm install”, you will not regret it and you’ll get a much better understanding of what’s actually running.

Now there are of course exceptions to this, like Prometheus or Ingress operators where more complex charts are warranted. What I’m talking about is those charts that just wrap what can be translated from docker-compose to k8s in two minutes.

[cryptonector]

But no one is forcing you to use charts. If you have a trivial single-container app, then don't use Helm. I'm still not seeing the complaint.

[Too]

This. Almost every chart try to be helpful and hide the upstream configuration of the application. Inevitably, you will sooner or later need to change a config. Now it’s not enough to read the documentation of the application, you also need to map this parameter into whatever values the helm chart translated it to. I wouldn’t even call it an abstraction, since it’s only read in a single location, it’s just a dumb and pointless translation. Total nonsense.