4 ms·

Helm also hides complexity in the templates. There's a lot of valid complaints floating around YAML but what's worse than dealing with YAML is dealing with tem

Helm also hides complexity in the templates. There's a lot of valid complaints floating around YAML but what's worse than dealing with YAML is dealing with templated YAML. kubectl brings everything to the surface. Helm is an unnecessary abstraction.

tecleandor 4y ago
I think Helm can be nice to template mildly complex stuff you cannot reach simply with Kustomize, but it's true there are lot of things you can't see until you apply them, even when `helm lint` doesn't fail. If you need this templating, a think you can do is use helm for that but not for install/deployment: render the charts with `helm template` and then apply them with `kubectl apply` and/or verify the changes with `kubectl diff`. IIRC Argo CD can show you the differences between the running helm chart and the new version you want to apply if you haven't enabled automated syncing, but I only use Argo CD with Kustomize, so I can't say for sure right now. edit: by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly'. Long term, if there's more than one person working in Kubernetes, that's prone to failure and configuration drift. Doing the templating in whatever language or system that fills your needs and then using something like Argo CD or Octopus to apply them can remove most of those problems.
- pickledish 4y ago
  > by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly' Yep, this is what I meant! Just "if you're using some kind of manager for your resources, which you probably are, then ONLY use that manager, don't just `apply` stuff out of band" is the idea :) I might take a pass later at making that more clear
nijave 4y ago
Helm templates tend to be too complex, in my opinion. On the other hand, having 50 services, deployments, ingresses, etc which have names/labels copy/pasted in 3-5 different places is also extremely complex--especially when you want to make a change to update all of them. Kustomize seems too basic--maybe JSONNet or something fills this gap
- cassianoleal 4y ago
  I think one of the strengths of Kustomize is precisely that it's basic - although it may not be as basic as you think if you haven't used it in anger. I don't want complexity in my manifests. I want them to be to the point. Renaming in multiple places is very easy with find-replace.

tecleandor 4y ago

I think Helm can be nice to template mildly complex stuff you cannot reach simply with Kustomize, but it's true there are lot of things you can't see until you apply them, even when `helm lint` doesn't fail. If you need this templating, a think you can do is use helm for that but not for install/deployment: render the charts with `helm template` and then apply them with `kubectl apply` and/or verify the changes with `kubectl diff`. IIRC Argo CD can show you the differences between the running helm chart and the new version you want to apply if you haven't enabled automated syncing, but I only use Argo CD with Kustomize, so I can't say for sure right now. edit: by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly'. Long term, if there's more than one person working in Kubernetes, that's prone to failure and configuration drift. Doing the templating in whatever language or system that fills your needs and then using something like Argo CD or Octopus to apply them can remove most of those problems.

pickledish 4y ago
> by reading the article again I think the spirit of that point is not 'use just helm' but 'don't apply stuff directly' Yep, this is what I meant! Just "if you're using some kind of manager for your resources, which you probably are, then ONLY use that manager, don't just `apply` stuff out of band" is the idea :) I might take a pass later at making that more clear

nijave 4y ago

Helm templates tend to be too complex, in my opinion. On the other hand, having 50 services, deployments, ingresses, etc which have names/labels copy/pasted in 3-5 different places is also extremely complex--especially when you want to make a change to update all of them. Kustomize seems too basic--maybe JSONNet or something fills this gap

cassianoleal 4y ago
I think one of the strengths of Kustomize is precisely that it's basic - although it may not be as basic as you think if you haven't used it in anger. I don't want complexity in my manifests. I want them to be to the point. Renaming in multiple places is very easy with find-replace.