kube-libsonnet

I've been using kubecfg [1] with kube.libsonnet [2]. I don't like Tanka as it imposes a given directory structure on me via scaffolding - which is a big no-no for the way I organize projects (I value very unopinionated tools in this regard). I also couldn't get into the ksonnet style of mixins/arguments, as it takes away the ease of overriding underlying Kubernetes structures. [1] - https://github.com/bitnami/kubecfg [2] - https://github.com/bitnami-labs/kube-libsonnet

Highly recommend trying Jsonnet (via https://github.com/bitnami/kubecfg and https://github.com/bitnami-labs/kube-libsonnet) as an alternative. It makes writing Kubernetes manifests much more expressive and integrates better with Git/VCS based workflows. Another language like Dhall or CUE might also work, but I'm not aware of a kubecfg equivalent for them. Jsonnet in general is a pretty damn good configuration language, not only for Kubernetes. And much more powerful than HCL.

The way I've saved myself from YAML insanity in k8s is by using kubecfg [1] and kube.libsonnet [2]. I can now build abstractions that work for my particular deployments and never have to worry about extraneous verbosity in day-to-day operations. [1] - https://github.com/bitnami/kubecfg [2] https://github.com/bitnami-labs/kube-libsonnet/blob/master/k...

(EDIT: the nick rang a bell: thanks for ktail!) kubecfg has the --gc-tag flag, which you explicitly pass so that it can know which of the existing resources in the k8s API server used to be created by this set of kubecfg maintained config (this "system", this "application", it's up to you to decide the grain of your modelling) and thus be able to delete the resources are are no longer output by the evaluation of the current configs. This catches the cases where you delete resources but also when you rename resources, or when you "move" them between namespaces. It's implemented without any in-cluster component (no "tiller") by simply setting the GC tag as a label on the resource. Kubecfg also implements diff between local config a d deployed state. As for the amount of files: it's up to you. Kubecfg is not opinionated on how you lay out yo

The fork is my fault. I agree it's confusing. I wrote (and still maintain) kubecfg. Heptio joined the project and started adding lots of great stuff. Eventually it was clear they wanted to take it in a direction that was different to the original borgcfg-like vision. I suggested we split that new functionality into a different tool so we could keep exploring both directions without trying to mash both into the same cli flags. Hence ksonnet/kubecfg and ksonnet/ksonnet. They both use jsonnet internally, generate the same k8s resources in the end, and have that common code heritage, so have many similarities. ksonnet/ksonnet has a bunch of extra ("rails-like") tooling to hold your hand while you generate jsonnet, and assumes it uses the k.libsonnet library (https://github.com/ksonnet/ksonnet-lib). ksonnet/kubecfg is much dumber and real