Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I ported Kubernetes to the browser

ngrok.com

Post reply on HN
Print view View original

41–50 of 110 posts

Re: I ported Kubernetes to the browser

#41

Post by playorizaya »

firesteelrain wrote: post #36
playorizaya wrote: post #33

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?…

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…

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.

Re: I ported Kubernetes to the browser

#42

Post by tekacs »

samwho wrote: post #35
tekacs wrote: post #30

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 atomi…

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!

Re: I ported Kubernetes to the browser

#43

Post by firesteelrain »

playorizaya wrote: post #41
firesteelrain wrote: post #36

Earlier quoted context omitted.

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…

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.

Re: I ported Kubernetes to the browser

#44

Post by samwho »

ambicapter wrote: post #11
raychis wrote: post #10

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 team…

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.

Re: I ported Kubernetes to the browser

#45

Post by samwho »

tekacs wrote: post #42
samwho wrote: post #35

Earlier quoted context omitted.

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…

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.

Re: I ported Kubernetes to the browser

#46

Post by playorizaya »

firesteelrain wrote: post #43
playorizaya wrote: post #41

Earlier quoted context omitted.

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.

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

Re: I ported Kubernetes to the browser

#47

Post by samwho »

firesteelrain wrote: post #43
playorizaya wrote: post #41

Earlier quoted context omitted.

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.

Re: I ported Kubernetes to the browser

#49

Post by leetrout »

samwho wrote: post #34
dinkleberg wrote: post #14

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 ed…

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.

Re: I ported Kubernetes to the browser

#50

Post by stackskipton »

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.

Post reply on HN