[gravypod]

Super cool to see these sorts of tools. They're great for learning the kube API.

For production-y things however, some meta-config language that allows deterministic templateing would be a huge improvement. It allows you to make sweeping/uniform infrastructure changes from a single library or tool change.

Kubecfg is a good example of the basics one could implement [0] although it's examples aren't as fully fledged and organized as they could be.

[0] - https://github.com/bitnami/kubecfg/blob/master/examples/gues...

[clvx]

https://cuelang.org/ is another option.

[q3k]

I can second using jsonnet and kubecfg for this. Not only you start out with some very useful abstraction from kube.libsonnet, but are also able to build your own abstractions easily, ones that are specific to you organization/codebase/release cycle. All from a declarative, lazily evaluated, pure language.

[baq]

heard good things about https://dhall-lang.org/#

[zingplex]

I've used Dhall in production, pushed it fairly hard and can say with utmost certainty it's be an absolute pleasure. We use it as our application configuration format and derive fairly intricate Kubernetes resources from our app config.

Although it is still in it's early days, it still is excellent to use and will only get better with additional tooling.

[k__]

How does it differ from the CDK/CDK8s/terraform-cdk?

[zingplex]

CDK uses existing fully featured programming languages that can preform side effecting actions thus lacking reproducibility and that are may not terminate. Dhall is a total language, meaning it will always terminate and a pure language, meaning that a function given an input will always yield the same output. That makes the output extremely predictable.