For example i built this https://kubernetes-made-simple.vercel.app/
Now i can add this
For example i built this https://kubernetes-made-simple.vercel.app/
Now i can add this
Its a cool site btw
What’s one thing most people get wrong about k8s that makes learning unnecessarily difficult?
Particularly storage.
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.
Kube rapidly becomes accidental complexity when you use it to accomplish things that could be done more simply, of course.
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
My understanding is that the interesting part of k8s is how it orchestrates containers, which this port can do a lot of. Your comments imply that a core component of k8s is actually running containers (rather than orchestrating them), but I don't think that's right. That would be the job of containerd or the operating system, depending at what level you're looking at. Happy to be corrected if I'm wrong about any of this!
To call it a port that doesn’t actually work? Idk seems like a baseline requirement.
It’s like saying you ported YouTube to a calculator but it doesn’t play videos because the most interesting part is the search algorithm, and it’s for educational purposes not functionality.
That just isn’t a port.
That would mean I could run an image of an OS like Linux in browser JavaScript. It's a wild thing, but that's what porting literally means! And what I expected with that title.
Think of like a PlayStation emulator... the game itself does not need to be ported - just as if you really made a k8s port you would not really need to reinvent Linux in JS, only be able to run it
A PSX emulator can be said to have been ported (e.g. Tomb Raider has been ported to the browser even though it relies on underlying C++) because it ultimately runs fully 1:1 in a web page. It's a port as far as I'm concerned.
But a k8s port that doesn't do what k8s does isn't a port IMO
K8s sits on top of those and orchestrates them.
also the title is false
But then, I get the idea of the project. If you wanted real kubernetes, it's easy to install on any OS or online in a VM.
There has to be some cutoff of features where "it runs in the browser" makes sense. I think the project has made a good call here.
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.
it's a bad faith dig at ai-driven development, not the part of the comment that was supposed to be taken seriously, sorry.
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.
Recently I also started to port fd.io vpp to rust for my app with help of codex
A clear interface and well defined test case is must to make the rewrite successful
It was fun.
Won't comment on the product because not my cup of tea.
I'm team cli ftw :)
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
I bet you just meant to share prior art and not be discouraging, Sam. But just saying :-)
>Right now, it doesn’t support ConfigMaps, Secrets, pod resources, persistent volumes, and a whole host of other things I haven’t needed yet. As I make more content with this library, I’ll implement more of what I need.
Yea, this is initial start to the madness followed by Ingress Controller and all little weird crazy stuff that Developers do that drive our lives crazy.
Also keeping these plates spinning while 100 devs are launching who knows what.
etcd is not a requirement of k8s, plenty of clusters out there use non-etcd stores. E.g. k3s/k3d can use sqlite, all of the big cloud providers use their own in-house datastores instead of etcd.
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?
I'm talking specifically about US-based AI companies / hardware companies and their circular investments and their customer-facing pricing.
> 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?
Because the cost of training continues to increase while getting increasingly harder and harder to make gains. On top of that, there is the delay between investing in the datacenters, staff, running the training, operational costs of customer use, etc and actually recouping profit via customer sales. Your costs go up because their costs go up. Likely even more so now because of the increased risk the US Gov will shut down sales and use of their newest models. That risk will get bundled in with pricing.
I feel like your conflating some general skepticism around the trillion dollar valuation of the US majors and their business model with the topic at hand - large scale C to Rust conversions and similar.
The topic at hand wasn't rust conversions, it was token cost.
Effectively token cost for most in the US is whatever the companies and US Gov say it is... Until it pops because they have no real moat.
There's a limit to price hikes due to competition, and open weights can't collude so closed weight companies don't have that much wiggle room to raise prices unless they are much better than open weights.
Unless you say you have the best model in the world, and then everybody will fight to use it.
> No, they don't, they can also be defaulted on/written off.
Bye, bye world economy.
> 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.
Many projects would be just fine if you created a comprehensive-enough set of tests that you understood to be enough.
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!
>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.
I ported Kubernetes to the browser
https://ngrok.com/blog/i-ported-kubernetes-to-the-browserhttps://webernetes-demo.ngrok.app/