But really any kind of reconciler, e.g. flux or argo with helm works very well. Helm is only used as a templating tool, i.e. helm template is the only thing allowed. It works very well and I've ran production systems for years without major issues.
I dont really understand how people have so much trouble with Helm, granted yaml whitespace + go templating is sometimes awful, it is the least bad tool out there that I have tried and once you learn the arcane ways of {{- its mostly a non-issue.
I would recommend writing your own charts for the most part and using external charts when they are simple, or well proven. Most applications you want to run arent that complicated, they are mostly a collection of environment variables, config files, and arguments.
If I could wish for a replacement of helm, it would be helm template with the chart implemented in a typed language, e.g. TypeScript, instead of go template but backwards compatible with go template.
I wrote Go and Python programs that constructed the manifests using the native Kubernetes types and piped them into kubectl apply. Had to write my own libraries for doing migrations too. But after that bootstrapping it worked great.
Kubernetes API uses JSON. JSON is JavaScript Object Notation. So naturally the best approach to work with JSON is to write JavaScript or TypeScript code. You can just output JSON and consume it with kubectl. You can read data from whatever format you want, process it and output JSON. You can write your little functions to reduce boilerplate. There are many options that are obvious once you just embrace JavaScript.
Of course most other programming languages will work just as well, it's just JavaScript being the most natural fit for JSON.
> Kubernetes API uses JSON. JSON is JavaScript Object Notation. So naturally the best approach to work with JSON is to write JavaScript or TypeScript code.
I don't really like this superficial reasoning. You can specify, generate, parse, and validate JSON in many common languages with similar levels of effort.
Saying you should use JavaScript to work with JSON because it has JavaScript in the acronym is about as relevant as comparing Java to JavaScript because both have Java in the name.
There are some features of Kubernetes that are only available in the Go client like Informers. So Go is a much more natural fit (you can move between JSON and Go structs with one function call + error check)
Im quite happy with FluxCD+Helm. Helm also supports creating library charts (basically component libraries) that can improve the experience of creating and maintaining helm charts by a lot.
terraform with helm/kubernetes/kubectl providers is hit or miss. But I love it for simple things. For hairy things I will want full TypeScript with Pulumi.
Terraform. It’s declarative, type safe and just expressive enough to create basic conditionals, loops and reusable modules. Providers exists for all clouds and k8s.
Now it’s not perfect either. It does have some issues with slow querying of the current state during planning, even when it has the tfstate as a cache, which is another source of errors.
badLiveware|3 months ago
But really any kind of reconciler, e.g. flux or argo with helm works very well. Helm is only used as a templating tool, i.e. helm template is the only thing allowed. It works very well and I've ran production systems for years without major issues.
I dont really understand how people have so much trouble with Helm, granted yaml whitespace + go templating is sometimes awful, it is the least bad tool out there that I have tried and once you learn the arcane ways of {{- its mostly a non-issue.
I would recommend writing your own charts for the most part and using external charts when they are simple, or well proven. Most applications you want to run arent that complicated, they are mostly a collection of environment variables, config files, and arguments.
If I could wish for a replacement of helm, it would be helm template with the chart implemented in a typed language, e.g. TypeScript, instead of go template but backwards compatible with go template.
trenchpilgrim|3 months ago
anttiharju|3 months ago
cdk8s.io
vbezhenar|3 months ago
Of course most other programming languages will work just as well, it's just JavaScript being the most natural fit for JSON.
HumanOstrich|3 months ago
I don't really like this superficial reasoning. You can specify, generate, parse, and validate JSON in many common languages with similar levels of effort.
Saying you should use JavaScript to work with JSON because it has JavaScript in the acronym is about as relevant as comparing Java to JavaScript because both have Java in the name.
trenchpilgrim|3 months ago
unknown|3 months ago
[deleted]
preisschild|3 months ago
fjsdkfjwjd|3 months ago
terraform with helm/kubernetes/kubectl providers is hit or miss. But I love it for simple things. For hairy things I will want full TypeScript with Pulumi.
awoimbee|3 months ago
E.g. these are the libs I use, generated from CRDs: https://github.com/Extrality/pulumi-crds
tribaal|3 months ago
There’s packages. You can write functions. You can write tests trivially (the output is basically a giant map that you just write out as yaml)…
I’m applying this to other areas too with great success, for example our snowflake IaC is “just python” that generates SQL. It’s great.
Too|3 months ago
Now it’s not perfect either. It does have some issues with slow querying of the current state during planning, even when it has the tfstate as a cache, which is another source of errors.
mattcanhack|3 months ago