[littlekosh]

Helm is great right up until you run into a chart that doesn’t support what you need, i.e. if you want to run on tainted nodes, it needs to support tolerations. Want to add a sidecar to a pod? No.

It also lies about the actual status of the installation. A deployment that applies successfully but has issues with the new pods coming up can still show successful.

The larger charts are a nightmare which isn’t helm’s fault but it doesn’t make things appreciably easier either.

Kustomize has a lot of warts too. If the type definition in k8s source doesn’t have a merge key defined, it’s going to overwrite the entire section of the resource. You can use JsonPatches to get around that problem but that is super gross too.

The entire ecosystem is trying to solve the same problem and no one has come up with the definitive way of doing it (because it’s a HARD problem) It seems like Helm templating and then passing to kustomize to add in the one-off changes is the direction a lot of people are heading but it’s more of a least-bad solution than a good one.

I will say, if you’re using helm templates for your own stuff, you very likely going to be happy with it.

[jaxxstorm]

This is a problem we got sick and tired of at $work, so we made kr8: https://github.com/apptio/kr8

You can define a component which you install into many clusters and then slightly differentiate them based on cluster parameters, kind of like Puppet or Chef (without the application stage)

Alongside this, you can actually patch helm charts. An example component can be found here https://github.com/jaxxstorm/kr8-cfgmgmt-example/blob/master...

The patches.jsonnet allows you to add a commandline flag that wasn't in the helm chart at one time.

[littlekosh]

Oh no, jsonnet!

Seriously though, gonna look closer at this tomorrow at the office. Thanks for the heads up!

[jjeaff]

You're just running helm charts directly from the public repo? I assume so since you say customization is a nightmare.

I use helm fetch and pull the charts with dependencies into my repo. Running direct from the public repo is a little bit too much like piping the contents of a url to bash without checking first.

You can then customize however you like.

When I want to update the charts, helm fetch it again and merge the changes.

[alexellisuk]

So you are forking and maintaining the helm templates.. :-/

[jjeaff]

Not really. I'm essentially just pinning the version and then checking the updates before upgrading.

[grantlmiller]

The pattern of Helm template + Kustomize is operationalized with Ship: https://github.com/replicatedhq/ship plus some other functionality to automate pull requests from upstream updates.

[captn3m0]

Isn't it a native usecase as well? This is linked from the kustomize website as a valid usecase: https://testingclouds.wordpress.com/2018/07/20/844/

(Title = Customizing Upstream Helm Charts with Kustomize)