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.

▲

playorizaya 4 hours ago | parent [-]

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.

▲

firesteelrain 4 hours ago | parent [-]

I don’t want to come across as diminishing OPs work. But it was alot of work to simulate what Kubernetes is doing.

▲

playorizaya 4 hours ago | parent | next [-]

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

▲

austin-schick 3 hours ago | parent [-]

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!

▲

playorizaya 3 hours ago | parent [-]

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.

	▲	austin-schick 2 hours ago \| parent [-]
		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? :-)

▲

samwho 4 hours ago | parent | prev [-]

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.