Kube rapidly becomes accidental complexity when you use it to accomplish things that could be done more simply, of course.
For a while I have wanted to make a web page where you can do service load balancing and queuing simulations so this would be a great basis for it.
> Is this just slop?
> Almost all of the webernetes code was authored by LLMs
> ...
> I did two things that I think make this a slop-free project:
> 1. I reviewed every line of code.
> 2. I created hundreds of tests that assert webernetes behaves the same as a real cluster.
Though it seems like right now this is probably better for conceptual/architectural education. The real fun is when you start learning to master kubectl.
1. Bun rewritten in Rust
2. Flow rewritten in Rust
3. The react compiler was rewritten in Rust
4. Grit is a new implementation of Git in Rust
5. I've made my own rust rewrite of postgres that passes 100% of the regression and isolation tests[0][1]
One of the many things I did to deal with this was an audit skill that would:
1. Find a small chunk of code to rewrite
2. Have a list of things that it was looking for in each piece of code that's being rewritten
3. Place that next to the code being translated
4. If that document didn't exist and/or didn't say the code was passing the audit, code wouldn't be merged
5. As I found problems and anti-patterns I would add those to the skill over time
Complicated old "boring" infra software might actually be the most AI-rewriteable code right now
I was thinking for all of these that the end goal is to take some existing technology and add some novel features rather than just X in Rust so what I have so far.
1. The Lua project bundles Lua 5.1 - 5.5 in one binary and one npm package so it's easy to run in the browser or CloudFlare Worker etc.
2. The Valkey (Redis) port builds something called EdgeStash - lets you run Valkey with Lua scripting in a CloudFlare Durable Object programmable with Lua scripting.
https://edgestash-valdr.ianmclaughlin1398.workers.dev/ that's a demo of the Edge Valkey node running.
I've been meaning to take take it and do something like yours that is sweet!
2. ...would need a renderer, right? Otherwise what does it mean to be "ported to the browser"?
To use an analogy - if somebody ported DOOM to the browser, that means I can now play it in the browser. But I can't really run those databases that it shows in the browser tab, can I?
I couldn't say spin up ruby2d and suddenly have client-side Ruby support. It would require all sorts of custom work to get that actually running in a browser tab.
Where presumably with typical backend container services they really can port around and run anywhere.
So I don't see the point, and someone correct me if I'm wrong but it doesn't even seem to be what it asserts.
>I'll often encourage BACKEND JAVASCRIPT DEVS to try to solve computer problems themselves by trial and error.
>However I've learned an important lesson: if they say the've sold their problem, never ask how.
It was fun.
As a minor thought / question – I'm a little surprised that this isn't (yet) wired up for pods to run in Web workers.
I appreciate that there is a Clock mechanism (allowing you to step the cluster), which would be more difficult in that setup, but... I feel like especially with SharedArrayBuffer (which admittedly requires the right COOP/COEP), that could be pulled off with atomics.
Would be very cool to be able to actually thread in earnest with this design!
It’s not running real container images. Maybe a better idea is simulated Kubernetes.
What’s ported is the control plane: scheduler, kube-proxy, deployment controller, etc, transliterated from the actual Go source and tested against k3s for behavioral parity using the same client API. The “rendering” is the demo app visualizing pod-to-pod requests as moving dots.
One of the fun things is it shouldn’t be too difficult to create a new RuntimeService that uses web workers and slots in alongside my existing CRI. I’d love a PR along those lines!
Just a misleading title, I think.
It's not "k8s ported to the browser" so much as a web based monitoring tool.
Looks great, btw.
Similarly, when you move on to doing Volumes support, the browser's OPFS APIs can be synchronous from workers and only async from the main thread, so there are interesting possibilities around buffering/caching/using SharedArrayBuffer to accept-and-write extents that could be nice with workers. :)
If I get a spare moment, I'll absolutely take a look at PR-ing a runtime!
If someone said they "ported git to the browser" but it was just a UI for git workflows it would be equally misleading.
I think because that isn't what "porting" is.
In such a case I would expect git - the version control code and diffing - running in browser JavaScript in the same way DOOM is when someone says they ported DOOM to the browser.
That's what porting means, right?
Since there are k8s bindings written in languages like Node.js (effectively a port) - and even they don't call it "a port" is worth considering for OP with regards to the title! Just my 2c
The thing I think is most misleading about the title is that I haven’t ported _all_ of Kubernetes. It’s just the slice I needed. I’m hoping to gradually port more of it, though.
Volumes are one of those things that I’m quite sure won’t be that difficult to implement but I don’t have a need for them in the near future, so likely won’t support them for a good while.
Sam Rose is a Senior Developer Educator at ngrok, focusing on creating content that helps developers get the most out of ngrok.