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.
katacoda got bought by o'reilly and went to shit from there. We tried to give them money in 2020 and they just sent us a templated email to "go self qualify with this form" and it was clear they only cared about enterprise sized customers. which is a real shame because it was a great platform.
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.
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
I don't think this analogy holds. Version control and diffing are some core capabilities of git. Sam lists core capabilities of k8s that his port can handle: pod lifecycles, container garbage collection, IP allocation, etc.
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.
I get your point. I will disagree that it "doesn't work". It does! You just can't use it for real production workloads since it runs in your browser. If you ported kubernetes to your toaster would it be a port? I think so, but you probably couldn't deploy prod on it. That's just a fun semantics conversation though. Is a taco a sandwich? :-)
Considering what kubernetes actually is - there's a fantastic use case if you really did port it to the browser. So when someone says they did it, I kinda expect that they literally ported that containerization logic to JavaScript.
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
Separately from any details of this post, I think you misunderstand what kubernetes is. To me, that's something worth reading and thinking about.
You seem to think it's like a virtual machine, and it lets you run containers anywhere regardless of operating system or host machine. This is not correct. You can't run containers using k8s directly on a Mac, for example, because there is no Linux kernel to run the container. You need a VM first, then you can run k8s inside of that VM. Kubernetes does not let you magically run a container with ARM binaries on an x86 machine either. You would need additional tools to run binaries for another architecture.
You're totally right that in practice, you usually don't need to think about the host OS when you're using k8s. It is nice to not worry about what packages it has installed, etc. But it is not a tool that allows you to run an arbitrary container anywhere.
Nope, I don't think (and don't think I said) it's a VM, or that it can allow you to run any software on any hardware. I have been coding long enough to remember using VirtualBox to do Ruby work for clients :)
I may have alluded to that experience - in saying that we used to use VMs for the same use case (isolation) before mainstream containerization like Docker. But yeah I know the two are unrelated.
The idea of installing software in an isolated (emulated) environment - a snapshot of the OS ("disk image") - is not so different from the PSX emulator analogy since emulators also work that way.
Docker got popular before Kubernetes was even created. It was after the fact that it became its own thing, and tried to become just an "orchestration layer" but it means nothing without containerization.
To say you ported it to the browser with no working containers doesn't mean anything to me. What was ported?
It's like saying you ported PlayStation to Chrome but no games will play. How is it a port of anything.
Sorry to be blunt but from the messages you have written in this threads it is pretty clear you don't know well enough what you are talking about.A real working Kubernetes cluster has many layers of abstractions and the lower ones are outside Kubernetes completely (i.e. containerd or the Linux kernel itself).
Kubernetes runs on the infrastructure where your services are deployed.
That is not happening here. This is a simulation of a web based kubernetes control plane.
The whole point of the movement toward Docker/kubernetes is that you can run services anywhere without needing a 1:1 OS/physical machine configured for that service. It's an evolution on hijacking VMs for this use case. Consider what this technology is, and is for.
To say it has been ported to the browser would mean I could run e.g. postgres service in my browser the same way installing kubernetes on some cloud provider lets me run it there without having access to that machine directly.
He hasn't ported kubernetes to a browser. If I use some cloud provider UI to configure kubernetes I would not say that k8s is running in that browser tab. I'd just be using a web based dashboard.
Yes it can visualize activity, logs, etc. but kubernetes is not actually provisioning, managing state, scheduling, etc. in its environment (the browser) the way it did in an OS environment. And correct me if I'm wrong - but it's not even calling out to other environments - these are mere simulations of services that aren't running anywhere. Aren't they?
It wouldn't be impossible to do what the title implies is happening - See JSLinux to actually see Linux in a browser. It aint pretty, but that's the kind of thing I'd think of if somebody said they ported kubernetes to the browser. I should be able to run stuff there.
> Make points. mAnY lAyERs aside if it doesn’t actually do anything you have not ported anything.
You might consider reflecting on this long thread which seems to be solely about your personal definition of the word "port", and arguing with others that the definition should be what you say.
Particularly because you're now stooping to insulting other HN posters over one technical definition of one word.
The only thing that would change my opinion is if it actually worked.
And I don't think I was being insulting at all.
What I replied to:
"pretty clear you don't know well enough what you are talking about" is the real insult in this thread, which is what I called out :) Those statements are so boring and don't prove anything. Anyone can say "You don't know what you are talking about" but he hasn't proven anything. It's just an empty insult.
Making letters lower/upper to stress emphasis in a reply to that is part of conveying that.
You haven't changed my mind at all so far, I still think this doesn't qualify as a port.
Question for you: What would you use this project for in production? How could I replace k8s today with this browser port?
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.
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.
This is genuinely really cool. I guess the added complexity and/or performance hit will require some justification but I can see it paying off for some use cases.
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 :-)
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?
> Could you explain your mental model of the situation a bit more?
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.
Hmm but isn't your point moot if the GLM 5.2 type models are good enough to do these large scale port to Rust projects? Like maybe Anthropic goes bust but doesn't really matter for this case.
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.
No, they don't, they can also be defaulted on/written off. Open weights are there to stay, plus research, plus the GPUs, just the power needs to be paid.
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.
As SRE, Deployment, Replica Sets and Services are generally the easy part. The hard part which he noted:
>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.
I agree. This isn't what people struggle with to be honest.
With the limitations, right now it is sloppy unfortunately...
Yet cool to release it nontheless.
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.
giving yourself (or your llm) infinite future work in maintaining all that duplicated kubernetes source code is a bad idea, surely? the author notes they could have compiled the kubernetes to wasm, but doesn't due to... bundle size? i haven't tried, but surely it wouldn't work because all os-level functionality would cause panics.
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.
The author clearly explains his process in detail, explaining the pitfalls. Not sure why you’d make a dig like this.
There are some useful insights in the article
> 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.
I don't understand it. What's the point of this project? I know kubernetes is like a docker but more complex. What's the point of running out in the browser?
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.
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.
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.
katacoda got bought by o'reilly and went to shit from there. We tried to give them money in 2020 and they just sent us a templated email to "go self qualify with this form" and it was clear they only cared about enterprise sized customers. which is a real shame because it was a great platform.
Huh, looks like they mothballed it a year later.
As someone who loves teaching and building this can be very useful
For example i built this https://kubernetes-made-simple.vercel.app/
Now i can add this
The reconciliation simulator goes crazy when I change the expected pods on iphone.
Its a cool site btw
same on firefox on android
This is really cool but the trace advances quite quickly I had to run through a couple of times to read all of the text.
Read the whole thing, good stuff. Would be great to expand on gateway, and maybe mention CRDs.
Awesome site.
What’s one thing most people get wrong about k8s that makes learning unnecessarily difficult?
Thinking that the range of capabilities is a setup todo list.
Particularly storage.
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.
I mean this is a specific case where you literally have a spec to code against. Not all coding endeavors have that opportunity, unfortunately.
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.
For a lot of us, the spec is Product Market Fit and Profit Dollars.
Investing early in this hn post before it’s a banger. Instant classic
It's Web Scale Technology™
100%
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.
Right, that's what I thought - still very cool!
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.
I don’t want to come across as diminishing OPs work. But it was alot of work to simulate what Kubernetes is doing.
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.
Sure - but to use another analogy...
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
I don't think this analogy holds. Version control and diffing are some core capabilities of git. Sam lists core capabilities of k8s that his port can handle: pod lifecycles, container garbage collection, IP allocation, etc.
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 me the interesting part is the use case.
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.
I get your point. I will disagree that it "doesn't work". It does! You just can't use it for real production workloads since it runs in your browser. If you ported kubernetes to your toaster would it be a port? I think so, but you probably couldn't deploy prod on it. That's just a fun semantics conversation though. Is a taco a sandwich? :-)
Considering what kubernetes actually is - there's a fantastic use case if you really did port it to the browser. So when someone says they did it, I kinda expect that they literally ported that containerization logic to JavaScript.
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 doesn't run containers, container runtime environments do.
K8s sits on top of those and orchestrates them.
This “port” doesn’t even do that
But Kubernetes isn't postgres or ruby or containers. It's the orchestration service. Your comparison doesn't make sense.
It’s like saying you ported PlayStation to the browser but no games work.
It would be the most pointless emulator ever.
And it wouldn’t qualify as being ported IMO
Separately from any details of this post, I think you misunderstand what kubernetes is. To me, that's something worth reading and thinking about.
You seem to think it's like a virtual machine, and it lets you run containers anywhere regardless of operating system or host machine. This is not correct. You can't run containers using k8s directly on a Mac, for example, because there is no Linux kernel to run the container. You need a VM first, then you can run k8s inside of that VM. Kubernetes does not let you magically run a container with ARM binaries on an x86 machine either. You would need additional tools to run binaries for another architecture.
You're totally right that in practice, you usually don't need to think about the host OS when you're using k8s. It is nice to not worry about what packages it has installed, etc. But it is not a tool that allows you to run an arbitrary container anywhere.
Nope, I don't think (and don't think I said) it's a VM, or that it can allow you to run any software on any hardware. I have been coding long enough to remember using VirtualBox to do Ruby work for clients :)
I may have alluded to that experience - in saying that we used to use VMs for the same use case (isolation) before mainstream containerization like Docker. But yeah I know the two are unrelated.
The idea of installing software in an isolated (emulated) environment - a snapshot of the OS ("disk image") - is not so different from the PSX emulator analogy since emulators also work that way.
Docker got popular before Kubernetes was even created. It was after the fact that it became its own thing, and tried to become just an "orchestration layer" but it means nothing without containerization.
To say you ported it to the browser with no working containers doesn't mean anything to me. What was ported?
It's like saying you ported PlayStation to Chrome but no games will play. How is it a port of anything.
Sorry to be blunt but from the messages you have written in this threads it is pretty clear you don't know well enough what you are talking about.A real working Kubernetes cluster has many layers of abstractions and the lower ones are outside Kubernetes completely (i.e. containerd or the Linux kernel itself).
Save the insults. Make points.
mAnY lAyERs aside if it doesn’t actually do anything you have not ported anything.
It has to WORK to be a port.
See the PlayStation emulator example - same thing. The game itself is not ported but it still runs. That’s the point!
It is porting, and I quote the post
> A partial port of Kubernetes’ “kubelet” binary, enough to run pods and probe them.
> Ports of several Kubernetes “controllers”: pod scheduler, namespace controller, kube-proxy, deployment controller, and a few more.
plus a re-implementation of the CNI and a container runtime.
Kubernetes runs on the infrastructure where your services are deployed.
That is not happening here. This is a simulation of a web based kubernetes control plane.
The whole point of the movement toward Docker/kubernetes is that you can run services anywhere without needing a 1:1 OS/physical machine configured for that service. It's an evolution on hijacking VMs for this use case. Consider what this technology is, and is for.
To say it has been ported to the browser would mean I could run e.g. postgres service in my browser the same way installing kubernetes on some cloud provider lets me run it there without having access to that machine directly.
He hasn't ported kubernetes to a browser. If I use some cloud provider UI to configure kubernetes I would not say that k8s is running in that browser tab. I'd just be using a web based dashboard.
Yes it can visualize activity, logs, etc. but kubernetes is not actually provisioning, managing state, scheduling, etc. in its environment (the browser) the way it did in an OS environment. And correct me if I'm wrong - but it's not even calling out to other environments - these are mere simulations of services that aren't running anywhere. Aren't they?
It wouldn't be impossible to do what the title implies is happening - See JSLinux to actually see Linux in a browser. It aint pretty, but that's the kind of thing I'd think of if somebody said they ported kubernetes to the browser. I should be able to run stuff there.
> Make points. mAnY lAyERs aside if it doesn’t actually do anything you have not ported anything.
You might consider reflecting on this long thread which seems to be solely about your personal definition of the word "port", and arguing with others that the definition should be what you say.
Particularly because you're now stooping to insulting other HN posters over one technical definition of one word.
I am not redefining what a port is – but you are
No amount of whining is going to change anything.
The only thing that would change my opinion is if it actually worked.
And I don't think I was being insulting at all.
What I replied to:
"pretty clear you don't know well enough what you are talking about" is the real insult in this thread, which is what I called out :) Those statements are so boring and don't prove anything. Anyone can say "You don't know what you are talking about" but he hasn't proven anything. It's just an empty insult.
Making letters lower/upper to stress emphasis in a reply to that is part of conveying that.
You haven't changed my mind at all so far, I still think this doesn't qualify as a port.
Question for you: What would you use this project for in production? How could I replace k8s today with this browser port?
> I am not redefining what a port is – but you are
> You haven't changed my mind at all so far, I still think this doesn't qualify as a port.
as it turns out, I'm not actually interested in debating over the meaning of a word, or convincing anyone to change their mind on it
> K8s doesn't run containers, container runtime environments do.
> K8s sits on top of those and orchestrates them.
> I'm not actually interested in debating over the meaning
Ok.
Did you know that k8s came after containerization, and means nothing without it
> Webernetes is intended to be used to make interactive Kubernetes content;
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.
Nate Abele gave a talk about this at the Carolina Code Conference last year.
https://youtu.be/t7L2iROVaRg?is=xoV4aiCXcYMVvVDL
Relatedly, I vibecoded this a few days ago for fun: https://imjasonh.github.io/kubescheduler-the-game/
It was fun.
This game has got my name written all over it
First of all, this is wonderful stuff!
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.
DM-ed :)
This is genuinely really cool. I guess the added complexity and/or performance hit will require some justification but I can see it paying off for some use cases.
This is awesome. Wish I had the idea first. I see this as a fun learning and experimental tool.
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.
I have some potentially bad news for you:
https://samwho.dev/load-balancing https://encore.dev/blog/queueing
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 :-)
Completely agree! Wasn’t trying to discourage, hope it doesn’t have that effect.
I wonder if stuff like this will also be created when token costs explode.
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.
No, because those loans still have to be repaid.
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?
> Could you explain your mental model of the situation a bit more?
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.
Hmm but isn't your point moot if the GLM 5.2 type models are good enough to do these large scale port to Rust projects? Like maybe Anthropic goes bust but doesn't really matter for this case.
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.
It will be very difficult to get those used in production in any US enterprise in the Fortune 500.
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.
No, they don't, they can also be defaulted on/written off. Open weights are there to stay, plus research, plus the GPUs, just the power needs to be paid.
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.
> There's a limit to price hikes due to competition
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.
Yes, because you can buy infinity tokens for $10,000 with hardware.
People can and do still run local models.
This is cool and impressive
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
wasm should be the "image" type for webernetes
As SRE, Deployment, Replica Sets and Services are generally the easy part. The hard part which he noted:
>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.
I agree. This isn't what people struggle with to be honest. With the limitations, right now it is sloppy unfortunately... Yet cool to release it nontheless.
The demo is cool. What would I use this for?
What are you using to replace etcd here? Where is state stored?
They implemented a store in TypeScript: https://github.com/ngrok/webernetes/blob/main/src/cluster/st...
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.
I learned that etcd wasn’t required while making webernetes! I’d always thought it was, was cool to learn some clusters use other storage backends.
giving yourself (or your llm) infinite future work in maintaining all that duplicated kubernetes source code is a bad idea, surely? the author notes they could have compiled the kubernetes to wasm, but doesn't due to... bundle size? i haven't tried, but surely it wouldn't work because all os-level functionality would cause panics.
also the title is false
I've also wondered whether implementing OS calls would have been smarter. Maybe there's already a library that does 90% for you.
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.
Thank you!
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.
Why is the title false?
the author paid for a robot to write the software while they watched.
it's a bad faith dig at ai-driven development, not the part of the comment that was supposed to be taken seriously, sorry.
The author clearly explains his process in detail, explaining the pitfalls. Not sure why you’d make a dig like this. There are some useful insights in the article
does this actually work across browsers or its just inside a single browser?
Single browser.
There's even a blog/article write-up with a more succinct demo of Kubernetes: https://ngrok.com/blog/i-ported-kubernetes-to-the-browser
edit: added the slop-free remarksI don't understand it. What's the point of this project? I know kubernetes is like a docker but more complex. What's the point of running out in the browser?
definitely cool. nice work peterdemin whoever you are
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.
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.
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:
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 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.
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!
+1 CC helped me finally shipped a Rust project I had been sleeping on for years.
I've seen Sam working on this real time as I follow him on BlueSky. So maybe it's technically a slop but I've seen a proof of work.
Won't comment on the product because not my cup of tea.
I'm team cli ftw :)
This is great!
And now for a fun game with this: try and delete all the pods!
https://xkcd.com/763/
>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.
"Just because one can do a thing does not mean one should do that thing."
I gave my boss every opportunity to stop me.
A new low in AI slop.
[flagged]
[dead]
[dead]
[dead]
Please port Kubernetes to common house flies so that they drop dead out of all the unnecessary overhead. That would be helpful.
what will we port to the spiders whose population will otherwise surely explode?