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