Open Source Ecosystems

KubeScript is a DRY infrastructure as code solution to Kubernetes DevOps

Beta

Quickstart

Install KubeScript by running the following command.

deno install --unstable -A --root /usr/local -n ks https://deno.land/x/kube_script/main.ts

You can try KubeScript without writing any code.

ks https://deno.land/x/kube_script/example/web/mod.ts

Checkout this project.

git clone https://github.com/in-fun/KubeScript.git

Show diff from current settings.

ks example/nginx --env production | kubectl diff -f -

Apply k8s resources.

ks example/nginx --env production | kubectl apply -f -

Kubernetes resource manifests are declarative, why adding a scripting layer?

I agree declarative style is preferable, if the problem domain is not complex. But when things goes to some level of complexity, all so called declarative solution turns out to be procedural or requires procedural style hacks. I will give an example to illustrate it below.

This is a helm manifest for argocd-server deployment. As we can see, it uses procedural style statements including for loop (range), and if-else branching. The end result is mixing 2 languages in one: yaml and mustache; so it's even more complicated than a scripting language.

Our opinion is that real-world kubernetes manifests are so complex, that a fully declarative style of writing is almost impossible. On the other hand, procedural style is more flexible, easier to maintain, thus better.
Why use deno instead of node.js?

Deno is more developer friendly than node.js. For example, deno resolves dependencies on the fly, so no npm install any more.
How does KubeScript compare to other solutions?

We have summarized that in this doc.