Really cool and I think there will be more innovation to come in the form of kubelet implementations.<p>> <i>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</i><p>Is this a comment on the API, or ecosystem, or does it convey a change in personal understanding?<p>I mean ... I don't <i>like</i> 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.<p>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.
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.
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?
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