WebAssembly on Kubernetes • Nicolas Frankel • YOW! 2025

Nicolas Fränkel, in an exploratory talk at YOW! Australia 2025, delves into the evolving landscape of WebAssembly (Wasm) and its integration with Kubernetes. He acknowledges the rapidly changing nature of this field and encourages further research.

The Evolving Mental Model of WebAssembly

Fränkel highlights how the perception of WebAssembly has shifted over time, akin to the parable of the blind men and the elephant:

Wasm in 2018: “Compilation to the Web”

Initially, Wasm was conceived as a performance booster for web browsers, addressing JavaScript’s limitations for computationally intensive tasks like 3D or multimedia. An example shown was Conway’s Game of Life, where Wasm handled computations at ~60 frames per second, with JavaScript managing UI interactions.

Wasm in 2020: Expanding Scope

Two years later, Wasm was described as a “stack-based virtual machine,” explicitly mentioning its applicability for both client and server applications. Its scope broadened to include:

• Polyglot Environments: Enabling teams to use their preferred languages (e.g., Java, Rust, .NET) and compile to Wasm, fostering collaboration towards a common goal.
• Platform Extension: Allowing vendors to offer performant and restricted extension mechanisms, superior to limited custom scripting languages or overly permissive ones like Groovy/Lua.
• Functions as a Service (FaaS): Due to its small footprint and performance characteristics.

Wasm “Now”: Universal Language Support & Cloud-Native Potential

Today, Wasm is positioned for “all programming languages,” with support for languages like Kotlin, Python, Java, and .NET. Key capabilities that make Wasm suitable beyond the web include:

• Strong Security: Wasm modules run in a sandbox.
• Small Binary Sizes.
• Performance.
• Support for diverse OS and Architectures.
• Browser Compatibility.

Fränkel cites a foundational blog post by Fermyon, emphasizing that Wasm has moved “over the boundaries of the web.” This has led to a “very vivid, very living ecosystem” with companies like Spin Cube, Wasmer Cloud/Edge, and projects like Envoy leveraging Wasm for extensions.

Practical Demonstration: Wasm on Kubernetes

The core of the talk is a demonstration focusing on container size, Rust development, and Kubernetes configuration.

Project Architecture & Requirements

Fränkel aims to run an HTTP server built with Rust and the Axum framework within Kubernetes. This challenges Wasm’s traditional limitation of not directly opening ports or controlling networks. The demo uses three container flavors, all from the exact same Rust source code (with a minor compilation-time flag variation for flavor identification):

1. Native Rust: Compiled to native binary, running on a minimal base image (distroless/static).
2. WebAssembly Embedded: Wasm module running on a base image containing a Wasm runtime.
3. WebAssembly Scratch: Wasm module running from a scratch (empty) base image.

The HTTP server implements a GET endpoint, returning request details as JSON.

Code & Dockerfile Insights

• Rust Source: A single source file uses Rust’s conditional compilation (cfg attributes) to bake the flavor (native, embedded, wasm) into the binary, rather than runtime configuration.
• TCP Listener: The Rust code directly creates a TCP listener and starts a web application, demonstrating Wasm’s ability to handle network operations in this specific context.
• Cargo.toml Patching: Crucially, for the WebAssembly builds, certain Rust crates (like web server components) are “patched” to adapt them for a WebAssembly context.
• Dockerfiles: Multi-stage builds are used. The “WebAssembly Scratch” Dockerfile is particularly striking: it compiles Rust to Wasm, then copies only the .wasm file into an empty scratch image.

Local Docker Results

• Native Rust: Works as expected.
• Image Sizes: Native Rust: ~12 MB, WebAssembly Embedded (with runtime): ~8 MB, WebAssembly Scratch: ~2 MB. The 2 MB Wasm image is “unbeatable” in size.
• Challenge: The 2 MB WebAssembly scratch container did not run directly with Docker, indicating Docker’s lack of native Wasm execution capabilities.

Integrating WebAssembly with Kubernetes

The solution for running the 2 MB Wasm container lies in Kubernetes’ extensible runtime architecture.

Kubernetes Runtime Mechanics

Kubernetes (and Docker) don’t directly run containers; they delegate to containerd, which delegates to a shim (e.g., containerd-shim), which then delegates to a low-level runtime like runc. The strategy is to introduce a wasmedge-shim to delegate to the wasmedge binary instead of runc.

WasmEdge Setup (Recorded Demo)

Fränkel used WasmEdge as the runtime (though he later questions this choice). The setup involved:

1. Installing Rust (required to compile WasmEdge).
2. Cloning the WasmEdge repository.
3. Building WasmEdge from source.
4. Configuring Kubernetes (kubelet configuration) to recognize wasm-edge-shim as a runtime class, telling it to use wasmedge for Wasm workloads.

Kubernetes Deployment & Success

After configuring Kubernetes, all three container types (Native, WebAssembly Embedded, WebAssembly Scratch) were successfully deployed and accessed. The crucial point: the 2 MB WebAssembly scratch container, which failed to run with Docker locally, worked perfectly within Kubernetes, delivering identical results to the larger native containers. This demonstrated a “2 megs container running in Kubernetes. Unbeatable.”

Reflection: The Good, The Bad, & The Ugly

Fränkel provides a candid assessment:

• The Good: Achieving an HTTP server in Wasm with an incredibly small 2 MB container footprint.
• The Bad: The chosen WasmEdge runtime’s code isn’t actively maintained (last commit March 2024 for shim, even older for the runtime itself).
• The Ugly: The rapid, unstable evolution of the ecosystem. Code that worked perfectly six months prior for the initial preparation of the talk (e.g., downgrading Tokio version) broke before another conference (Go to Amsterdam), highlighting significant compatibility challenges and the lack of confidence this instills.

Conclusion & Recommendation

WebAssembly on Kubernetes is an extremely fast-evolving domain. Fränkel offers a differentiated recommendation:

• Startups: “If you are a startup and this you want to leverage this to have competitive advantage, just embrace it. It can give It can give you amazing results.” The risks are worth the potential gain.
• Traditional Software Shops: “I wouldn’t recommend it because it’s super super risky and you might need to invest a lot of things into well, stuff that doesn’t work out in the end or you need to get back in time.” The instability poses too great a threat for established organizations.

• Tags:
• Software Engineering
• Microservices
• Kubernetes
• Cloud Native
• Performance Optimization
• Rust
• Containerization
• WebAssembly
• WASM
• WasmEdge
• Application Deployment