Beta
- No yaml files.
- No boilerplate or hack.
- Type based code completion with Typescript.
- Safe sandbox with Deno.
screencast.mov
-
Install deno by following the official guide.
-
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
-
Generate k8s yaml files.
ks example/nginx
-
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 comopare to other solutions?
We have summarized that in this doc.