kubecfg
isopod
Our great sponsors
kubecfg | isopod | |
---|---|---|
6 | 4 | |
191 | 460 | |
3.7% | 0.9% | |
9.2 | 0.0 | |
6 days ago | 4 months ago | |
Go | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
kubecfg
-
Jsonnet – The Data Templating Language
kubecfg does add some features, like https:// imports, oci:// imports (oci bundles in OCI registries, transitively bundling all imported files with jsonnet-deps).
But yes, I strive to keep the "one file, one target, import whatever you need but explicitly" as much as possible.
I'm pouring some more time into the project and trying to implement some ideas I had for a long time but never managed to get them out. For example "Flags From Files" (https://github.com/kubecfg/kubecfg/blob/flagspec/docs/rfcs/r...) or "Caching + optional vendoring of immutable external deps".
-
Your thought on frameworks that uses/relying on ksonnet/ksonnet-lib?
Should kubecfg be used instead (having active development)?
- Falling for Kubernetes
isopod
-
Jsonnet – The Data Templating Language
Tried it[0], worked reasonably well. Be prepared for strong opposition from traditional “devops” folks “who don’t mind yaml” and will drag everyone down.
- Deploying Kubernetes clusters in increasingly absurd languages
- YAML: It's Time to Move On
-
Cue: A new language for data validation
I like Cue and Jsonnet and Starlark and so on. But all of these have very low mindshare (though Starlark has the most momentum thanks to Bazel), and who knows if they will be dead by next year.
Being an early adopter is difficult both in terms of the immaturity of the tooling — Cue, for example, only has a Go implementation at the moment — and in terms of the risk of betting on an evolutionary dead end, which can cause a lot of unnecessary churn when you want to standardize on something across an entire organization.
As a concrete example, I'd love to replace Kubernetes's use of YAML with something like the above. But the tooling is immature, and almost nobody is using any of it. For example, there's Isopod [1], which is a nice-looking tool to use Starlark with Kubernetes. But it might go the same way as Ksonnet.
What are some alternatives?
skycfg - Skycfg is an extension library for the Starlark language that adds support for constructing Protocol Buffer messages.
rules_jsonnet - Jsonnet rules for Bazel
cue - The home of the CUE language! Validate and define text-based and dynamic configuration
grafonnet-lib - Jsonnet library for generating Grafana dashboard files.
c2bf - Compiler from C to brainfuck
hof - Framework that joins data models, schemas, code generation, and a task engine. Language and technology agnostic.
starlark-go - Starlark in Go: the Starlark configuration language, implemented in Go
jk - Configuration as Code with ECMAScript
typescript-json-schema - Generate json-schema from your Typescript sources
kubectl-neat-diff - De-clutter your kubectl diff output using kubectl-neat
sprig - Useful template functions for Go templates.
github-desktop - A version of GitHub Desktop packaged with Conveyor