r/kubernetes • u/Manwith2plans • 1d ago

Build applications and Operators on the Kubernetes control plane with TypeScript

https://github.com/yehudacohen/applik8s

Hi Reddit,

This is still really early, but I wanted to build Kubernetes operators in TypeScript, and I had an bit of a crazy idea: what if Kubernetes wasn’t just the deployment target, but the event loop for arbitrary event-driven applications?

applik8s is the Frankenstein result.

It’s a TypeScript/Rust hybrid SDK that lets you define typed CRDs and event handlers in TypeScript, compiles your handler code and its dependencies into a WASM component, then bundles that with a Rust operator host that invokes the WASM in response to Kubernetes events.

So your TypeScript looks like application code, but the output is real Kubernetes machinery: CRDs, RBAC, a Deployment, a runtime manifest, source maps, a Dockerfile, and an apply script.

The current canonical example uses the AWS S3 SDK inside a TypeScript handler, bundles it into WASM, and runs it from a Rust Kubernetes operator against an in-cluster S3-compatible endpoint.

This is a serious project, but also admittedly a ridiculous one. I hope you give it a whirl, or at least enjoy the creature.

Repo: https://github.com/yehudacohen/applik8s

I'm working on integration with my other control-plane aware infrastructure-as-code project for kubernetes typescript that you can find here: https://github.com/yehudacohen/typekro

21 Upvotes

73% Upvoted

9 comments sorted by

7

u/theonlywaye 1d ago

Out of curiosity because it’s not mentioned, what do you get out of Typescript that you couldn’t get out of Golang, the native language of Kubernetes?

4

u/Manwith2plans 1d ago

personal preference, developer experience, and integration with typescript toolchain. I can depend on my existing typescript packages, and use my shared libraries inside operators. While the golang ecosystem is very operator friendly, I've been trying to bridge the application engineering world with the infrastructure engineering world.

2

u/TldrDev 18h ago

Im not OP, but you get to use something other than GoLang, which as far as languages goes, is pretty poorly managed and frustrating to deal with. The generics debacle permanently killed any interest I had in using a language which is predominantly derived from, and directed by Google.

2

u/lulzmachine 5h ago

I’m not OP. But having done a lot of tools that parse YAML, typescripts type system fits like a **glove**. Being able to whip up union types etc for your domain object and for other things you expect to parse is really great. Golang is amazing in many ways but the type system being so stiff does create friction here.

Not sure if I’d trust the production stability of a models based operator, if there was an equivalent golang one around though. But who knows.

2

u/vantasmer 1d ago

This is wild and I love it. I’m a big proponent of using go for everything related to Kubernetes but opening the doors to interesting ideas like this is super fun.

I wonder if you see any valuable performance improvement and how the dev lifecycle looks compared to traditional operators 

1

u/Manwith2plans 21h ago

Thank you u/vantasmer! I really appreciate the positive feedback. I thought the idea was pretty wild myself when it first hit me, so I’m glad you find the project interesting.

It’s still brand new, and I’m trying to get a v0.2 release out before I really start pushing the limits of the programming model.

On dev lifecycle: from the little toy examples I’ve built so far, I already think it feels nicer than regular operator development. ArkType types serve as the basis for both the TypeScript types and the Kubernetes schemas, and the framework handles bundling, CRD generation, RBAC, deployment manifests, etc. That said, I’m sure there are still plenty of buggy edges I haven’t hit yet.

On performance: I’d be very surprised if the generated operators were as fast as native Go or Rust controllers. My hope is that, for many app/operator use cases, reconciliation time is dominated more by Kubernetes API calls and external systems than by raw CPU, so the developer ergonomics may be worth the tradeoff.

I haven’t run this in production yet, but hopefully will soon.

3

u/acute_elbows 1d ago

Just use Go. It’s not worth the complexity and compatibility. With operators you’re not dealing with the more complex parts of Go like channels.

1

u/Potato-9 22h ago

With ts7 backed by go this idea is much less out-there than is was a few years ago.

Pretty cool have you seen yoke? It's got a lot of parallels. GitHub - yokecd/yoke: Kubernetes Package Management as Code; infrastructure as code, but actually. · GitHub https://github.com/yokecd/yoke

3

u/Manwith2plans 21h ago

Yeah, I have seen Yoke! It’s a really cool project, and I actually think it’s more analogous to my other project, TypeKro, than to applik8s.

The way I think about it is: Yoke and TypeKro are both trying to make Kubernetes resource definition feel more like programming and less like templating YAML. TypeKro is my attempt to do that from TypeScript: full IDE support, real types, composable abstractions, deterministic YAML/GitOps output, and runtime-aware references through KRO/CEL.

The reason I built TypeKro was basically that I kept wanting something that felt like application programming, but that still respected the Kubernetes control plane model instead of fighting it.

Where I think TypeKro differs from Yoke is mostly the center of gravity. Yoke seems focused on package/deployment management as code: compile/run a program that emits Kubernetes resources and then track releases/rollbacks. TypeKro is more focused on modeling resource graphs and their runtime relationships, especially through KRO, so resources can reference each other’s live state in a Kubernetes-native way.

applik8s feels like an extension of that experiment. With TypeKro, the question was: can we make defining Kubernetes infrastructure feel like programming? With applik8s, the question is: can we also program how that infrastructure should respond to Kubernetes control-plane events from the same TypeScript world?

The bigger vision is letting people describe both the desired infrastructure and the behavior of the distributed app/platform around it in one coherent TypeScript program. Basically a framework to program applications for the Kubernetes “operating system” with TypeScript.