With WASM, you get better isolation than a regular virtual machine, you can be more granular with scheduling and the attack surface is far smaller than a regular VM. When compared to namespaces containers, you don’t need to rely on the kernel attack surface being tight for security. And you get to intercept all syacalls ala gvisor with less complexity. The downside is interaction with specialty hardware and performance.

This doesn’t answer my question. A container is not a VM.

A container can be a VM, this provides a container with similar isolation characteristics to a VM with less complexity on the orchestrator/runc side of things.

Why WASM and not gVisor, which runs any program compiled to your architecture with similar isolation from the host kernel?

> With WASM, you get better isolation than a regular virtual machine, you can be more granular with scheduling

Why is this so?

Hey SpinKube maintainer here. You're right that you could just run your Wasm (or Spin app) directly in a container and there often are reasons you might want to do that. But, SpinKube executes WebAssembly using a containerd-shim which means we avoid the overhead of starting a container and rather just directly execute the Wasm.

https://www.spinkube.dev/blog/2024/03/13/introducing-spinkub... is a really good blog post on Spin that talks about this.

Does this also support running WASI? Or spin only?

The project is focused on supporting Spin. But Spin supports a large amount of the WASI API surface and is headed in the direction of using WASI in place of Spin specific APIs wherever possible.

Do you really feel that container overhead is a significant issue?

Hey, one of the SpinKube maintainers here!

You are correct that there is nothing extra required if what you want is to run Wasm inside a container.

However, that comes with a few disadvantages, primarily stemming from bundling your wasm runtime with each container image — and while your wasm workload is portable, the runtime itself needs to be compiled for the specific OS and architecture you need to execute on.

SpinKube comes with a containerd shim (or plugin) that executes Wasm workloads directly, so you can continue to integrate with the Kubernetes API (either by using regular pods with a runtime class, or the Spin application manifest), but not get the overhead of a full Linux container for your lightweight wasm component.