3 ms·

From this viewpoint, Helm is really kind of broken-by-design. It takes a perfectly good system (Kubernetes Manifests) which allows you to exactly specify the ex

From this viewpoint, Helm is really kind of broken-by-design. It takes a perfectly good system (Kubernetes Manifests) which allows you to exactly specify the exact versions of all the containers you want on your cluster, and it wraps it in an inscrutable "helm install" invocation which can potentially pull containers from anywhere at deploy time. I've used helm template which generates manifests but unfortunately this isn't really the common use case, and it doesn't give you that much compared to your favorite text templating language.

jacques_chester 6y ago
I think that an accounting system which encodes uncertainty ("it could be any one of these two dozen images") will help create pressure on the upstream, as well as downstream visibility into who is affected.
theptip 6y ago
I’d agree with this, particularly Helm v1/2 which installed an agent (Tiller) to inject imperative statefulness back into your deployments, this obviating some of the benefits of the elegant declarative design of k8s. As of Helm 3 Tiller is gone and it’s much better, but you’re also right that the templating is horrible. I think you have clearly gone wrong when you have a template operator to indent your yaml the correct amount when composing reusable chunks into your manifests, white space debugging in yaml is not what we should be spending our time on in 2021. I think the kustomize approach of layering JSON patches is also not generalizable enough, though it’s better than Helm for simple cases. It does come with some good dev tooling in skaffold and so that’s what I’m using for now. I have long thought that simple code objects in your language of choice are likely to be the long-term winner, operator frameworks, etc. - the OpenAPI generated code isn’t that good in Python (I suspect it’s better in Go) but Pulumi or Pykube are examples of this approach done well (though neither are suitable for every use case at this time). Sadly Helm is the current default and it’s where the community has standardized so it will take a lot of work to map all the accumulated wisdom from the Helm charts into some other approach.

jacques_chester 6y ago

I think that an accounting system which encodes uncertainty ("it could be any one of these two dozen images") will help create pressure on the upstream, as well as downstream visibility into who is affected.

theptip 6y ago

I’d agree with this, particularly Helm v1/2 which installed an agent (Tiller) to inject imperative statefulness back into your deployments, this obviating some of the benefits of the elegant declarative design of k8s. As of Helm 3 Tiller is gone and it’s much better, but you’re also right that the templating is horrible. I think you have clearly gone wrong when you have a template operator to indent your yaml the correct amount when composing reusable chunks into your manifests, white space debugging in yaml is not what we should be spending our time on in 2021. I think the kustomize approach of layering JSON patches is also not generalizable enough, though it’s better than Helm for simple cases. It does come with some good dev tooling in skaffold and so that’s what I’m using for now. I have long thought that simple code objects in your language of choice are likely to be the long-term winner, operator frameworks, etc. - the OpenAPI generated code isn’t that good in Python (I suspect it’s better in Go) but Pulumi or Pykube are examples of this approach done well (though neither are suitable for every use case at this time). Sadly Helm is the current default and it’s where the community has standardized so it will take a lot of work to map all the accumulated wisdom from the Helm charts into some other approach.