How to Run WebAssembly Containers on Kubernetes Using containerd

Background

WebAssembly (WASM) has become an official web standard alongside HTML, CSS, and JavaScript, offering a safe, portable, and high‑performance virtual machine that can run on any operating system or CPU architecture. The WebAssembly System Interface (WASI) extends this capability beyond browsers, providing POSIX‑like APIs for file, network, and memory access, and enabling the Bytecode Alliance to drive a modular ecosystem.

WebAssembly vs. Containers

Because of its security, portability, and low overhead, WASM is attracting interest from container, serverless, and edge‑computing communities. CDN providers such as Fastly and Cloudflare use WASM sandboxes for millisecond‑level cold starts, and Alibaba Cloud’s EdgeRoutine implements similar technology. However, WASM cannot yet match Docker containers in isolation depth, resource‑quota enforcement, or mature networking models.

Application Distribution

Docker images standardize application packaging via the OCI image format, enabling reproducible builds and distribution through registries. For WASM, the WAPM package manager offers similar distribution semantics, and WASM images can be stored as OCI images, allowing reuse of existing Docker tooling (e.g., Docker Registry, image signing) for version tracking and secure supply‑chain management.

Security Isolation

WASI adopts a capability‑based security model where an application can only access explicitly granted resources, reducing the attack surface compared with traditional OS permissions. Nevertheless, current WASI implementations lack fine‑grained CPU, memory, and I/O quota controls, and the static capability model does not yet support dynamic network service discovery required by many micro‑service workloads.

Setting Up the containerd WASM Shim

Install wasmer (v0.13) and upgrade containerd to at least v1.3.2. Then download the containerd‑shim‑wasm‑v1 binary and place it in /usr/bin. Add the following snippet to /etc/containerd/config.toml and restart containerd:

disabled_plugins = ["restart" ]
[plugins.cri.containerd.runtimes.wasm]
  runtime_type = "io.containerd.wasm.v1"

Verify the shim by pulling and running a simple WASM hello‑world image:

$ sudo ctr image pull docker.io/denverdino/hellowasm:latest
$ sudo ctr run --rm --runtime io.containerd.wasm.v1 docker.io/denverdino/hellowasm:latest test1
Hello world

Similarly, pull and run an Nginx WASM image to see the container’s logs.

Running WASM Containers in Kubernetes

Create a RuntimeClass that references the WASM handler:

apiVersion: node.k8s.io/v1beta1
kind: RuntimeClass
metadata:
  name: wasm
handler: wasm

Apply it with kubectl apply -f wasm-runtimeclass.yaml. Then define a pod manifest that uses this RuntimeClass and a WASM‑based Nginx image:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-wasm
spec:
  runtimeClassName: wasm
  containers:
  - name: nginx
    image: denverdino/nginxwasm
    ports:
    - containerPort: 8080

Deploy the pod ( kubectl apply -f nginx-wasm.yaml) and verify it reaches the Running state. Access the service via the Minikube IP and port 8080.

Conclusion

WebAssembly is still early‑stage, with ongoing work on SIMD, multithreading, and richer networking APIs, but its lightweight, secure, and portable nature makes it a compelling runtime for cloud‑native workloads, serverless functions, and edge devices. By extending containerd with a WASM shim and integrating with Kubernetes through RuntimeClass, developers can manage WASM applications with the same distribution, delivery, and operational models used for traditional containers.