![[The AI Show Episode 142]: ChatGPT’s New Image Generator, Studio Ghibli Craze and Backlash, Gemini 2.5, OpenAI Academy, 4o Updates, Vibe Marketing & xAI Acquires X](https://www.marketingaiinstitute.com/hubfs/ep%20142%20cover.png)
![[DEALS] The Premium Learn to Code Certification Bundle (97% off) & Other Deals Up To 98% Off – Offers End Soon!](https://www.javacodegeeks.com/wp-content/uploads/2012/12/jcg-logo.jpg){kind=logo}
![From drop-out to software architect with Jason Lengstorf [Podcast #167]](https://cdn.hashnode.com/res/hashnode/image/upload/v1743796461357/f3d19cd7-e6f5-4d7c-8bfc-eb974bc8da68.png?#)
.png?#)
.jpg?#)
![iPhone 17 Pro Won't Feature Two-Toned Back [Gurman]](https://www.iclarified.com/images/news/96944/96944/96944-640.jpg)
_Christophe_Coat_Alamy.jpg?#)
 (1).webp?#)
![Tariffs Threaten Apple's $999 iPhone Price Point in the U.S. [Gurman]](https://www.iclarified.com/images/news/96943/96943/96943-640.jpg)
WebAssembly on Kubernetes
Like a couple of innovative technologies, different people have different viewpoints on where WebAssembly fits the technology landscape. WebAssembly (also called Wasm) is certainly the subject of much hype right now. But what is it? Is it the JavaScript Killer? Is it a new programming language for the web? Is it (as we like to say) the next wave of cloud compute? We’ve heard it called many things: a better eBPF, the alternative to RISC V, a competitor to Java (or Flash), a performance booster for browsers, a replacement for Docker. -- How to think about WebAssembly In this post, I'll stay away from these debates and focus solely on how to use WebAssembly on Kubernetes. My approach and the use case Unlike regular programming languages, you don't write WebAssembly directly: you write code that generates WebAssembly. At the moment, Go and Rust are the main source languages. I know Kotlin and Python are working toward this objective. There might be other languages I'm not aware of. I've settled on Rust for this post because of my familiarity with the language. In particular, I'll keep the same code across three different architectures: Regular Rust-to-native code as the baseline Rust-to-WebAssembly using a WasmEdge embedded runtime Rust-to-WebAssembly using an external runtime Don't worry; I'll explain the difference between the two last approaches later. The use case should be more advanced than Hello World to highlight the capabilities of WebAssembly. I've implemented an HTTP server mimicking a single endpoint of the excellent httpbin API testing utility. The code itself is not essential as the post is not about Rust, but in case you're interested, you can find it on GitHub. I add a field to the response to explicitly return the underlying approach, respectively native, embed, or runtime. Baseline: regular Rust-to-native For the regular native compilation, I'm using a multistage Docker file: FROM rust:1.84-slim AS build #1 RUN
Like a couple of innovative technologies, different people have different viewpoints on where WebAssembly fits the technology landscape.
WebAssembly (also called Wasm) is certainly the subject of much hype right now. But what is it? Is it the JavaScript Killer? Is it a new programming language for the web? Is it (as we like to say) the next wave of cloud compute? We’ve heard it called many things: a better eBPF, the alternative to RISC V, a competitor to Java (or Flash), a performance booster for browsers, a replacement for Docker.
In this post, I'll stay away from these debates and focus solely on how to use WebAssembly on Kubernetes.
My approach and the use case
Unlike regular programming languages, you don't write WebAssembly directly: you write code that generates WebAssembly. At the moment, Go and Rust are the main source languages. I know Kotlin and Python are working toward this objective. There might be other languages I'm not aware of.
I've settled on Rust for this post because of my familiarity with the language. In particular, I'll keep the same code across three different architectures:
- Regular Rust-to-native code as the baseline
- Rust-to-WebAssembly using a WasmEdge embedded runtime
- Rust-to-WebAssembly using an external runtime
Don't worry; I'll explain the difference between the two last approaches later.
The use case should be more advanced than Hello World to highlight the capabilities of WebAssembly. I've implemented an HTTP server mimicking a single endpoint of the excellent httpbin API testing utility. The code itself is not essential as the post is not about Rust, but in case you're interested, you can find it on GitHub. I add a field to the response to explicitly return the underlying approach, respectively native, embed, or runtime.
Baseline: regular Rust-to-native
For the regular native compilation, I'm using a multistage Docker file:
FROM rust:1.84-slim AS build #1
RUN <<EOB #2
apt-get update
apt-get install -y musl-tools musl-dev
rustup target add aarch64-unknown-linux-musl #3
EOB
WORKDIR /native
COPY native/Cargo.toml Cargo.toml
WORKDIR /
COPY src src
WORKDIR /native
RUN RUSTFLAGS="-C target-feature=+crt-static" cargo build --target aarch64-unknown-linux-musl --release #4
FROM gcr.io/distroless/static #5
COPY --from=build /native/target/aarch64-unknown-linux-musl/release/httpbin httpbin #6
ENTRYPOINT ["./httpbin"]
- Start from the latest Rust image
- Heredocs for the win
- Install the necessary toolchain to cross-compile
- Statically compile
- I could potentially use
FROM scratch, but after reading this, I prefer to use distroless - Copy the executable from the previous compilation phase
The final wasm-kubernetes:native image weighs 8.71M, with its base image distroless/static taking 6.03M of them.
Adapting to WebAssembly
The main idea behind WebAssembly is that it's secure because it can't access the host system. However, we must open a socket to listen to incoming requests to run an HTTP server. WebAssembly can't do that. We need a runtime that provides this feature and other system-dependent capabilities. It's the goal of WASI.
The WebAssembly System Interface (WASI) is a group of standards-track API specifications for software compiled to the W3C WebAssembly (Wasm) standard. WASI is designed to provide a secure standard interface for applications that can be compiled to Wasm from any language, and that may run anywhere—from browsers to clouds to embedded devices.
The specification v0.2 defines the following system interfaces:
- Clocks
- Random
- Filesystem
- Sockets
- CLI
- HTTP
A couple of runtimes already implement the specification:
- Wasmtime, developed by the Bytecode Alliance
- Wasmer
- Wazero, Go-based
- WasmEdge, designed for cloud, edge computing, and AI applications
- Spin for serverless workloads
I had to choose without being an expert in any of these. I finally decided on WasmEdge because of its focus on the Cloud.
We must intercept code that calls with system APIs and redirect them to the runtime. Instead of runtime interception, the Rust ecosystem provides a patch mechanism: we replace code that calls system APIs with code that calls WASI APIs. We must know which dependency calls which system API and hope a patch exists for our dependency version.
[patch.crates-io]
tokio = { git = "https://github.com/second-state/wasi_tokio.git", branch = "v1.36.x" } #1-2
socket2 = { git = "https://github.com/second-state/socket2.git", branch = "v0.5.x" } #1
[dependencies]
tokio = { version = "1.36", features = ["rt", "macros", "net", "time", "io-util"] } #2
axum = "0.8"
serde = { version = "1.0.217", features = ["derive"] }
- Patch the
tokioandsocket2crates with WASI-related calls - The latest
tokiocrate is 1.43, but the latest (and only) patch v1.36. We can't use the latest version because there's no patch.
We must change the Dockerfile to compiler WebAssembly code instead of native:
FROM --platform=$BUILDPLATFORM rust:1.84-slim AS build
RUN <<EOT bash
set -ex
apt-get update
apt-get install -y git clang
rustup target add wasm32-wasip1 #1
EOT
WORKDIR /wasm
COPY wasm/Cargo.toml Cargo.toml
WORKDIR /
COPY src src
WORKDIR /wasm
RUN RUSTFLAGS="--cfg wasmedge --cfg tokio_unstable" cargo build --target wasm32-wasip1 --release #2-3
- Install the WASM target
- Compile to WASM
- We must activate the
wasmedgeflag, as well as thetokio_unstableone, to successfully compile to WebAssembly
At this stage, we have two options for the second stage:
-
Use the WasmEdge runtime as a base image:
FROM --platform=$BUILDPLATFORM wasmedge/slim-runtime:0.13.5 COPY --from=build /wasm/target/wasm32-wasip1/release/httpbin.wasm /httpbin.wasm CMD ["wasmedge", "--dir", ".:/", "/httpbin.wasm"]From a usage perspective, it's pretty similar to the native approach.
-
Copy the WebAssembly file and make it a runtime responsibility:
FROM scratch COPY --from=build /wasm/target/wasm32-wasip1/release/httpbin.wasm /httpbin.wasm ENTRYPOINT ["/httpbin.wasm"]It's where things get interesting.
The native approach is slightly better than the embed one, but the runtime is the leanest since it contains only a single Webassembly file.
Running the Wasm image on Docker
Not all Docker runtimes are equal, and to run Wasm workloads, we need to delve a bit into the Docker name. While Docker, the company, created Docker as the product, the current reality is that containers have evolved beyond Docker and now answer to specifications.
The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes.
Established in June 2015 by Docker and other leaders in the container industry, the OCI currently contains three specifications: the Runtime Specification (runtime-spec), the Image Specification (image-spec) and the Distribution Specification (distribution-spec). The Runtime Specification outlines how to run a “filesystem bundle” that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.
From then on, I'll use the proper terminology for OCI images and containers. Not all OCI runtimes are equal, and far from all of them can run Wasm workloads: OrbStack, my current OCI runtime, can't, but Docker Desktop can, as an experimental feature. As per the documentation, we must:
- Use
containerdfor pulling and storing images - Enable Wasm
Finally, we can run the above OCI image containing the Wasm file by selecting a Wasm runtime, Wasmedge, in my case. Let's do it:
docker run --rm -p3000:3000 --runtime=io.containerd.wasmedge.v1 ghcr.io/ajavageek/wasm-kubernetes:runtime
io.containerd.wasmedge.v1 is the current version of the Wasmedge runtime. You must be authenticated with GitHub if you want to try it out.
curl localhost:3000/get\?foo=bar | jq
The result is the same as for the native version:
{
"flavor": "runtime",
"args": {
"foo": "bar"
},
"headers": {
"accept": "*/*",
"host": "localhost:3000",
"user-agent": "curl/8.7.1"
},
"url": "/get?foo=bar"
}
Wasi on Docker Desktop allows you to spin up an HTTP server that behaves like a regular native image! Even better, the image size is as tiny as the WebAssembly file it contains:
| Repository | Tag | Size (Mb) |
|---|---|---|
| ghcr.io/ajavageek/wasm-kubernetes | runtime | 1.15 |
| ghcr.io/ajavageek/wasm-kubernetes | embed | 12.4 |
| ghcr.io/ajavageek/wasm-kubernetes | native | 8.7 |
Running the Wasm image on Kubernetes
Now comes the fun part: your favorite Cloud provider(s) isn't using Docker Desktop. Despite this, we can still run WebAssembly workloads on Kubernetes. For this, we need to understand a bit about the not-too-low levels of what happens when you run a container, regardless of whether it's from an OCI runtime or Kubernetes.
The latter executes a process; in our case, it's containerd. Yet, containerd is only an orchestrator of other container processes. It detects the "flavor" of the container and calls the relevant executable. For example, for "regular" containers, it calls runc via a shim. The good thing is that we can install other shims dedicated to other container types, such as Wasm. The following illustration, taken from the Wasmedge website, summarizes the flow:
Despite some of the mainstream Cloud providers offering Wasm integration, none of them provide such a low-level one. I'll continue on my laptop, but Docker Desktop doesn't offer a direct integration either: it's time to be creative. For example, minikube is a full-fledged Kubernetes distribution that creates an intermediate Linux virtual machine within a Docker environment. We can SSH into the VM and configure it to our heart's content. Let's start by installing minikube.
brew install minikube
Now, we start minikube with the containerd driver and specify a profile to enable differently configured VMs. We unimaginatively call this profile wasm.
minikube start --driver=docker --container-runtime=containerd -p=wasm
Depending on whether you have already installed minikube and whether it has already downloaded its images, starting can take a few seconds to dozens of minutes. Be patient. The output should be something akin to:
