Ksonnet: Simplify working with Kubernetes configurations(blog.heptio.com) |
Ksonnet: Simplify working with Kubernetes configurations(blog.heptio.com) |
Can I use ksonnet without knowing what the generated YAML looks like? If I still have to fully understand the underlying YAML formats, then using ksonnet just increases the cognitive load.
I think a parallel is say you decide to use TypeScript since it is all the rage;. But when you try to learn it, most docs says if you do this in TypeScript, this really happens in JS. Now, you need to know both TS & JS to do your job. This is why I personally never found coffeescript etc simpler JS exciting.
Previous efforts at "simplifying" k8s make you choose between one or the other use-case. ksonnet is trying to provide something that can be more continuous along this spectrum. .. At least that's the hope.
I wrote something that fills this econiche sometime last year in Ruby (https://github.com/matsuri-rb/matsuri). Same ideas: mixins, generation of Kubernetes resources, etc. For better or worse, it also adds the idea of combining all the deployment environments into a single workflow and command line interface.
The big difference? Ksonnet is better documented and promoted, lighter-weight, and now better supported within the community.
Another goal here is to have something that is easy to embed/repurpose. ruby is pretty heavyweight from that point of view.
While jsonnet is a C program right now (https://github.com/google/jsonnet) we are looking at picking up work on a go port so it is easier to integrate with the kubernetes universe.
A nice thing about jsonnet is that is it's a native data templating language, you don't have to compose a structured data format with a textual template language and deal with things as trailing commas in json or indentation (!!!) in yaml.
It offers a sound model for extending and overriding values.
Another thing: it's a fully featured programming language, but it's purely functional so you are guaranteed that your templates won't have surprising side effects.
In this respect, the most similar alternative is the Nix functional language.
I just created a small example with redis: https://gist.github.com/hosh/89099f6f14ca5101e22c55f8d7f9e65...
That doesn't show off all of the features in there. There is a Rails-like convention so that resource definitions are loaded and can be referenced within each other. There are additional hooks that lets you generate `kubectl` commands, so for example, on our team, I defined hooks that lets me shell into a running container, or go directly to the console. (Redis, MongoDB, PostgreSQL, Rails, Rabbitmq, etc. consoles)
So yeah, Matsuri is very heavy-weight compared to Ksonnet. It isn't just that it is Ruby (already heavy-weight). Feature-wise, it does a lot more. I'm not sure that is a good or a bad thing.
We've been looking into moving towards Kubernetes. I'm looking forward to seeing if ksonnet can fit our needs.
I will be interested in feedback on how such an approach could be helpful in managing complex configurations.
It's not that critical to the project itself, just naming and discoverability.