This is cool. As someone who has authored Kubernetes educational content in a past role, I can definitely see the appeal of building something like this. iirc we first used Katacoda and then used some other similar platform and they were very useful since they spun up a fresh instance on the fly for each user with a specific setup.
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.
Yeah, in a past role this would have been awesome for diagrams to explain how the control plane works, illustrating the degradation and failure modes, or comparing different architectures/ways to deploy onto k8s/
Sadly Katacoda got paywalled (totally get why they did it, these things have costs). I think some other similar platforms disappeared because they ran out of people willing to fund it. It’s a shame.
I’m hoping this offers an alternative. It has the risk of becoming out of date with reality, but at least even in that case the core should ~always be relevant.
1. It's not really running containers in the browser, right? It seems every service would need a custom connector - and more importantly...
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.
Your points are addressed in the post just not in the title.
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.
I’d guess that about 90% of the webernetes code is ported directly from the Kubernetes codebase. In that sense it is a port of Kubernetes to the browser. But the CRI and CNI are facsimiles created to work in the browser and for the purpose of making educational content.
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.
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
First thing is first, this is really cool.
This feels like the right way to frame LLM-assisted engineering. AI can generate a shocking amount of code, but the actual value is in the review discipline, and tests around it. The browser Kubernetes angle is cool, but what I find more interesting is the workflow, and especially testing behaviour against k8s instead of just trusting “looks right.” I do wonder how many teams are already doing this level of verification for AI-written code. It might be the direction everyone goes in over the next few years.
This is it. If you’re building something novel, and you want to rely on LLMs, you need to invest heavily in making tests. You don’t have the luxury of a reference implementation like I did here.
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!
Web workers were on my mind from the start but I never found myself needing them. They were always
my ace-in-the-hole if this ended up being too CPU hungry on the main thread but it never happened, so I didn’t bother.
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!
I definitely don't think that ordinary things would be too CPU-hungry on the main thread, but given how awkward it _can_ be to use the worker APIs, it would be a lovely abstraction to be able to treat workers as pods. I would love to run a CPU-hungry or WASM service on a worker as a pod and communicate with it over your take on CNI!
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!
I’m 100% confident it would be possible to do a worker-per-pod runtime. If you’re serious about trying to make it then slide into my DMs, would love to talk about it. I also think a CRI that supports WASM would be fairly easy.
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.
Perhaps to anticipate the multiple jokes about kube complexity, I think there's an interesting argument to make that something like kube is the necessary complexity level for the kinds of tasks that kube is intended to accomplish, ala Fred Brooks' rule about essential complexity vs accidental complexity.
Kube rapidly becomes accidental complexity when you use it to accomplish things that could be done more simply, of course.
A meta-trend I find interesting is there's a lot of projects using AI to rewrite existing systems in new programming languages. Most often in Rust.
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]
I think AI changed the economics of these projects even more than it has the economics for software engineering work in general. Though direct AI code translation is usually slop for me.
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
This by itself still let a lot of slop slip through, but also preemptively caught a ton of issues as part of my overall process.
Complicated old "boring" infra software might actually be the most AI-rewriteable code right now
I have been experimenting in this general area myself. I started by doing a port of Lua to Rust, then did Valkey to Rust using my Rust Lua for scripting, and now I've been working nginx in Rust.
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.
So your prior is that token costs are only going to go up. Doesn't stuff like GLM 5.2 and Deepseek change this? I.e. something close to Opus 4.5 that runs 10X + more performantly.
Could you explain your mental model of the situation a bit more?
Let's take something like GML 5.2 that is open source - anyone can run it on NVIDIA or AMD chips. People are currently making money by running GLM 5.2 Nvidia and AMD chips and selling inference on aggregators like openRouter.
So the cost to serve is like cost of Chip or financing for Chip + power and rackspace somewhere. We basically know that each year you will be able to server exponentially more inference per $ on Nvidia and AMD hardware as it gets to newer generations, so why would you expect the cost of inference on open models to also increase?
Like let's say not through a Chinese subsidized provider but like BaseTen https://www.baseten.co/pricing/ why would that get more expensive year over year?
> 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.
Interesting project and (possibly more) interesting explanation of the development process. I agree with the author that the primary difference between vibe slop and real engineering is just reading the lines of code. However it does feel like we are just on the cusp of only needing to read the tests and _not_ all the lines of code. Maybe a few more model generations and we will be there.
For some projects I think only reading the tests is probably fine. In this project I didn’t think it was enough purely because it’s a port of existing code, so there was a need to validate the port was as exact as it could be.
Many projects would be just fine if you created a comprehensive-enough set of tests that you understood to be enough.
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.
I’m hoping this offers an alternative. It has the risk of becoming out of date with reality, but at least even in that case the core should ~always be relevant.
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.
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.
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.
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.
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
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!
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!
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!
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.
It was fun.
Kube rapidly becomes accidental complexity when you use it to accomplish things that could be done more simply, of course.
One of the many things I did to deal with this was an audit skill that would:
This by itself still let a lot of slop slip through, but also preemptively caught a ton of issues as part of my overall process.Complicated old "boring" infra software might actually be the most AI-rewriteable code right now
[0] https://pgrust.com
[1] https://github.com/malisper/pgrust
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!
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.
https://samwho.dev/load-balancing https://encore.dev/blog/queueing
Let's take something like GML 5.2 that is open source - anyone can run it on NVIDIA or AMD chips. People are currently making money by running GLM 5.2 Nvidia and AMD chips and selling inference on aggregators like openRouter.
So the cost to serve is like cost of Chip or financing for Chip + power and rackspace somewhere. We basically know that each year you will be able to server exponentially more inference per $ on Nvidia and AMD hardware as it gets to newer generations, so why would you expect the cost of inference on open models to also increase?
Like let's say not through a Chinese subsidized provider but like BaseTen https://www.baseten.co/pricing/ why would that get more expensive year over year?
Many projects would be just fine if you created a comprehensive-enough set of tests that you understood to be enough.
>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.