Krustlet, the WebAssembly Kubelet | Hacker News Reader

Krustlet, the WebAssembly Kubelet

deislabs.io

118 pointsdankohn119 comments

Really cool and I think there will be more innovation to come in the form of kubelet implementations.

> We took this time to prove that we could achieve something that seemed incredibly difficult a few months ago: writing projects against the Kubernetes API in languages other than Go

Is this a comment on the API, or ecosystem, or does it convey a change in personal understanding?

I mean ... I don't like client-go. Each version is superglued to particular API versions which effectively imposes release forks on downstream consumers. An unexpectedly large amount of magic is hidden in it. And I just don't like code generation, as a rule.

But I don't see the Kubernetes API, the thing you can talk raw HTTP to, in itself, as super hard. I have a (private) codebase where I was able to recreate a proxy server from the OpenAPI spec that's good enough to fool kubectl. And I can just as easily poke it with curl and figure out what it does.

I get the feeling of magic. Seems like a lot of your pain points are around versioning and code gen. any chance you've seen https://godoc.org/sigs.k8s.io/controller-runtime/pkg/client or other dynamic clients that make life a bit easier?

Glad to see Deis still alive. The developer tools/cloud devops field doesn't pay but it is important to have smaller players like Deis and Flynn around otherwise we would all be forced to suck from the teats of the AWS-GOOG-MSFT oligopoly.

I direct your attention to the footer of the page, which says:

"Deis Labs: Open Source from Microsoft Azure."

My experience of working with fiendish teat-touting oligopolists is that the folks at the coalface are just folks. Google engineers: just folks. Microsoft engineers: just folks. IBM, Red Hat, SAP, Heroku/Salesforce, VMware: all just folks.

Most of the nonsense comes from upper managements, so far as I am able to determine.

I missed the acquisition, this is a tragedy for open source but I suppose it is great for the Deis team.

Is https://flynn.io/ still alive?

They're still very active and now much more insulated from the danger of their employer running out of money and thereafter being scattered to the four winds. Maybe it's not a tragedy.

What are the limitations? For example: if I have a Python script that makes some HTTPS requests, will this runtime provide to my compiled binary everything it needs to perform this task?

Hi! Krustlet maintainer here.

The idea behind the project is to run WebAssembly modules in Kubernetes. You would have to compile your Python script to WebAssembly before it could be executed.

If your WebAssembly module complies with the WebAssembly System Interface, Krustlet can run it.

It's important to note that the WASI standard and wasmtime are still under heavy development. There are some key features (like networking) that are currently missing, but will be made available in future updates.

Maybe a dumb question, but can I run Krustlet in the browser? (maybe via browser WASI polyfill?). Does this mean you could assemble ad-hoc clusters using volunteer browsers? Not saying one _should_, but could you?

> assemble ad-hoc clusters using volunteer browsers

It sounds far-fetched, but I think it may eventually become practical with WASM and WebRTC, to use peer-to-peer networking for distributed computing.

Closest example in that direction, I've heard of malicious WASM payloads that mine cryptocurrencies:

Persistent drive-by cryptomining coming to a browser near you (2017)

https://blog.malwarebytes.com/cybercrime/2017/11/persistent-...

I'm optimistic that people will find socially beneficial application of this idea.

Krustlet is not in WebAssembly itself. It's an implementation of kubelet in rust that runs WebAssembly inside WASI or WASCC runtime, not other way around.

No.

From what I can understand, this runs webassembly artifacts natively on a k8s cluster. So where you'd normally be running a docker container on the cluster, you'll instead run a webassembly binary or multiple copies of them.

I can't answer your question exactly, but I assume that it can run any compiled binary.

Another way to run WASM in Kubernetes would be to use Lucet (from Fastly) inside a Firecracker microvm, managed by Kubernetes with something like Weave Ignite

That's neat. Do you have a project or a demonstration showing how this can be done, or is this all just hypothetical?

Why do you continue to use Deis Labs instead of Microsoft?

why is this needed..?

Seems to me that it's potentially safer to run untrusted WebAssembly applications than native Linux binaries, since the format is designed to run in browsers without pre-approval by the user and/or reviewers. So you could run a service published by a third-party on your own Kubernetes cluster alongside your own apps.

Title is confusing and make it seems like it's a kubelet that runs in WA runtime. It's the opposite, it's a kubelet that runs WA workloads.

It's needed because WebAssembly becoming a nice and secure way to run your workloads and have plugins written in multiple languages.

Reply on news.ycombinator.com