Skip to main content
← Back

WebAssembly on Kubernetes: Benchmarking wasmCloud & Embedding wash

The January 22, 2025 wasmCloud community call opens by welcoming a wave of new maintainers, then turns to running WebAssembly on Kubernetes. Liam Randall demos a proof-of-concept that embeds the wadm and wasmCloud host libraries directly into the wash CLI — folding three separate binaries into one for the wash dev loop. Taylor Thomas then demos the new wasmCloud benchmark Helm chart, which uses k6 load testing with a bundled Grafana, Loki, and Tempo stack to measure WebAssembly workload performance inside a cluster. The call closes with a walkthrough of the Q1 roadmap and a frank discussion of provider and CI workflow testing.

Key Takeaways​

  • A new cohort of wasmCloud maintainers was welcomed: Jiaxiao "Mossaka" Zhou, Mark Kovari, Masoud Baharlouie (ossfellow), Luke (luk3ark), and Aditya Salunkhe — recognized for contributions spanning providers, examples, the platform Helm chart, and a full wRPC interface implementation
  • Embedding wadm and wasmCloud into wash is a proof-of-concept that runs NATS, wadm, and the wasmCloud host inside a single wash process, so wash dev spins up an entire local platform without downloading separate binaries — and works offline
  • In-memory stream persistence for wadm and wasmCloud streams means an ephemeral wash dev session cleans itself up automatically, eliminating leftover links, config, and manifests even after an abrupt kill
  • Binary size stays reasonable: the statically linked wash binary grows from ~21 MB to roughly ~45 MB with the embedded host libraries and NATS — versus separately downloading ~22 MB (wadm) + 14 MB (NATS) + 34 MB (wasmCloud)
  • The wasmCloud benchmark Helm chart is now published to OCI and targets teams running WebAssembly on Kubernetes — install it, set a test URL, and it stands up an isolated load-testing stack
  • k6 powers the load tests, distributing load via the k6 operator and emitting OpenTelemetry data into a self-contained Grafana, Loki, and Tempo stack for latency percentiles, failure rates, and per-pod CPU/memory
  • The Q1 roadmap centers on stabilization, rigor, capability providers, SDKs, advancing Wasm standards, and integrating WASI Preview 3 — all tracked in GitHub Projects, with the goal of closing one roadmap item per week
  • Provider and CI workflow testing remain hard problems: the team discussed wRPC-call testing in provider integration tests, the limits of tools like act for GitHub Actions, and an open invitation for contributors passionate about test tooling

Chapters​

Meeting Notes​

Welcoming New wasmCloud Maintainers​

Liam opened the call by welcoming a new group of wasmCloud maintainers, several of whom were on the call. The new maintainers are Jiaxiao "Mossaka" Zhou (@mossaka), Mark Kovari (@markkovari), Masoud Baharlouie (@ossfellow), Luke (@luk3ark), and Aditya Salunkhe (@Aditya1404Sal).

Each was recognized for sustained contributions: ossfellow for the platform Helm chart, the NATS key-value store provider, and the NATS object store provider, plus community leadership and Slack troubleshooting; Aditya for many features and fixes and an entire wRPC interface implementation across providers; luk3ark for building a full platform on wasmCloud and catching bugs and race conditions while pushing the runtime to its limits; markkovari for fast Slack support and PRs across the project; and Mossaka — a long-time Wasm community member and WASI Cloud champion at Microsoft — who contributed a fully featured Azure Blob Store provider.

Demo: Embedding wadm and wasmCloud into wash​

Liam walked through a proof-of-concept that embeds the wadm and wasmCloud host libraries directly into the wash CLI, an idea Roman originally filed (see the GitHub issue). Because the wasmCloud host binary is essentially a thin wrapper around the host library — just like the wadm binary wraps its own library — those libraries can be compiled directly into wash.

Today, wash up and wash dev download NATS, wadm, and wasmCloud from GitHub releases and execute them as separate processes. With a temporary fully-embedded flag, wash instead calls start_nats, start_wadm, and start_host in-process, attaching the runtime to the single wash process so everything tears down together on Ctrl-C. The result: a complete local WebAssembly platform that needs no extra downloads and works offline. This work is closely related to the wash dev rapid developer loop that the team had just shipped.

Demo: The wasmCloud Benchmark Helm Chart on Kubernetes​

Taylor Thomas demoed a new benchmark Helm chart landed in the main repo, aimed at teams running WebAssembly on Kubernetes. The chart is published to OCI, so a single helm install from the registry — with just a test URL set — stands up a self-contained Grafana, Loki, and Tempo stack isolated from the rest of your cluster.

Under the hood it installs the k6 operator (a Grafana load-testing tool) to distribute load across nodes or node pools, runs a roughly one-minute HTTP test, and streams OpenTelemetry data into the bundled observability stack. The dashboards show latency percentiles (P50/P90/P95/P99), success and failure rates over time, and per-pod CPU and memory usage. The chart targets an HTTP endpoint — whether served by the built-in HTTP server, the HTTP server provider, or anything else inside or outside the cluster — and is designed to be deleted entirely once a test run is done. This chart became the subject of a follow-up blog post a few weeks later.

The wasmCloud Q1 Roadmap​

Liam walked the Q1 roadmap, planned during the prior week's community session and tracked in GitHub Projects. After a Q4 retrospective — big Golang performance gains, auto-generated docs, and a renewed focus on wash dev — the quarter's high-level goals are stabilization, rigor, capability providers, SDKs, advancing Wasm standards and WASI Preview 3, and continuing to enable developers to build WebAssembly components without vendor lock-in or platform-specific dependencies. With the benchmark chart already done and embedding the host into wash underway, the team set itself a target of closing roughly one roadmap item per week.

WebAssembly News and Updates​

The big ecosystem thread on this call is performance measurement for WebAssembly on Kubernetes. The new wasmCloud benchmark Helm chart leans on the broader cloud-native observability toolkit — k6 for load generation, Grafana, Loki, and Tempo for dashboards and traces, and OpenTelemetry as the wire format — to give teams a repeatable way to measure WebAssembly workload performance. On the standards side, the roadmap reaffirmed wasmCloud's commitment to the Wasm component model and the road toward WASI Preview 3, themes the project would return to throughout 2025. For ongoing updates, follow the Bytecode Alliance and the wasmCloud blog.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#, and more) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's host is built on Wasmtime, uses NATS as its transport, and packages workloads via OCI registries. With built-in OpenTelemetry observability and a Kubernetes operator, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: Running WebAssembly on Kubernetes​

The benchmark chart demo is a window into how wasmCloud treats WebAssembly on Kubernetes as a first-class deployment target. Because wasmCloud workloads are scheduled by a Kubernetes operator and run as ordinary pods, the same cluster primitives that operators already rely on — namespaces, node pools, tolerations, selectors, and Custom Resource Definitions — apply directly to load testing. The benchmark chart installs the k6 operator (so you need CRD permissions), then uses standard Kubernetes scheduling to place load generators on dedicated node pools, away from the workloads under test.

What makes this compelling is portability: a WebAssembly component is the same artifact whether it runs locally under wash dev or in an AKS cluster. The benchmark chart can point at any HTTP endpoint — the built-in HTTP server, the HTTP server provider, or a non-wasmCloud service — and the observability stack it bundles (Grafana, Loki, Tempo, all OpenTelemetry-fed) is the same stack platform teams already operate. That alignment, plus the WebAssembly component model's language-agnostic interfaces, is what lets wasmCloud slot WebAssembly into existing Kubernetes-native workflows rather than asking teams to adopt a parallel toolchain.

Who Should Watch This​

This call is especially valuable for platform engineers running WebAssembly on Kubernetes who want a repeatable, OpenTelemetry-instrumented way to benchmark workloads (start with Taylor's chart demo at 24:35), wasmCloud contributors and tooling developers weighing the embedded-host wash approach and the project's CI/provider testing challenges (Liam's POC at 6:30 and the testing discussion at 40:15), and anyone planning Q1 work who wants the roadmap context (walkthrough at 38:00).

Up Next​

Future community calls will continue the Q1 roadmap themes: stabilization and rigor across the platform, capability providers and SDKs, advancing Wasm standards toward WASI Preview 3, and maturing the embedded-host wash experience into a draft PR. Watch for standard wasmCloud benchmarks built on the new chart, and ongoing discussion of better provider and CI workflow testing. A reminder from the call: Cloud Native Rejects submissions close that weekend — a fun, chill venue for talks that didn't make the KubeCon cut.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →