[necubi]

Indeed, as someone who maintains a helm package it's mind-boggling. When I've been able to build k8s tooling from scratch, I've been reasonably happy with jsonnet [0], which is a constrained programming language designed for configuration. It has the property that it will always produce valid JSON.

[0] https://jsonnet.org/

[pram]

Seconded on jsonnet. I’ve started using it to generate json (that usually goes to an API) in gitlab ci pipelines. I use it to merge “gold standard” boilerplate configs with user changes.

[mati365]

Why not just plain JS or TypeScript?

[8organicbits]

JS and TS aren't configuration languages. If it wasn't for JS's early dominance and too-big-to-fail status on the web, we probably wouldn't use it for programming much. Platform and operations engineers often don't know JS well, favoring bash, python, and others for programming. Some exceptions exist, like full stack node shops.

Configuration languages like yaml, HCL, etc. are more reasonable alternatives.

[baq]

yaml is not a configuration language!

yaml is a tree serialization format with some human-targeted ergonomic features like comments and multiline strings built in.

it'll work for simple configuration files just as well as format-less .ini files will. for complex configurations, even xml is better, and that's saying a lot.

in practice for object graphs of any sort of complexity, like cloudformation or k8s configs, you want a programming language which can reduce the kolmogorov complexity of your configuration, because that dominates ops in the limit. or, IOW, configuration is code is configuration is code is ...

[pas]

yes https://cdk8s.io/docs/latest/plus/

[lambda_garden]

Turing Complete and non-determinstic languages are a bad fit for configuration.

[pas]

Is YAML with go template hacks that much better? (Without any kind of type safety in a context where true != "true".)

[out-of-ideas]

go and jinja "templates" have always been ever so much fun. It depends on the complexity stored in said "configs"; what reads the configs and what writes to the configs.

as a human i want to be able to both read and write, easiliy, by knowing wtf is going on for the input(s), and to understand clearly within the config-at-hand, what does what ect (without 5x paragraphs per 1 key-value tuple).

then insert more templates to generate more templates, and then it is a fun spiral

k8s reminds me of those 20min long commercials combined with the energizer bunny, "but wait there's more" .. "and there's more" .. "and there's more" - as with orcrastrating infrastructure as microservices, there's always more and more complexity to add to the monster. More layers, secutity, networking, ect, ect..

[pas]

well, there's more, because operating software is exactly like that and k8s tries to API-fy that, in my opinion with considerable success.

yes, the actual descriptors are atrociously hideous, but it's okay, it's low-level, evolving pretty quickly, and there are nice high-level representations -- https://cdk8s.io/docs/latest/plus/

so, yes, of course, compared to FTP copying PHP files into cgi-bin k8s is more complex, but the feature set is also different.

of course, not everyone needs declarative gitops-based blue-green deployment with pristine dev/demo/staging/UAT envs on each new PR. and usually when people think they do it's mostly just FAANG envy :)

but, speaking from experience, setting up a k3s cluster is easy, cheap, and deploying things on it with a "kubectl apply" is also easy. setting up CronJobs to do backups to some S3-compatible thing is also quite doable, and so on. and you end up with a big bag of YAML. is it better than snapshotting a VM? who knows!

[lambda_garden]

No, that would also be a poor choice.