To address the earlier comment: I didn’t go down the “implement the OS-level stuff required to get k8s to compile to wasm” path due to bundle size, honestly and truly. My testing indicated it could be over 10Mb, and I didn’t want that if I could avoid it. Turns out, I could avoid it.
Whether it’s a bad idea remains to be seen. It could be! The project will never have full parity with k8s, and as k8s moves forward I probably won’t keep up. But I think the core of k8s is stable enough that that’s okay, and I can make great content about the bits that don’t change.
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.
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.
Doesn't have to be bad news! An abundance of explainers is only good for the world. Different explanations work for different people. Someday somebody will say "I read all the articles people recommended, and I don't know why but it only clicked for me when I read mcapodici's!"
I bet you just meant to share prior art and not be discouraging, Sam. But just saying :-)
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.
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.
