What next for WASI on Azure Kubernetes Service?

Microsoft announced at the end of January 2025 that it would be closing its experimental support for WASI (WebAssembly System Interface) node pools in its managed Azure Kubernetes Service. This shouldn’t have been a surprise if you have been following the evolution of WASI on Kubernetes. The closure does require anyone using server-side WASI code on AKS to do some work as part of migrating to an alternate runtime.

It’s important to note that the two options Microsoft is suggesting don’t mean migrating away from WASI. WebAssembly and Kubernetes are two technologies that work well together. As a result, several different open source projects fill the gap, allowing you to add a new layer to your AKS platform and ensuring that you can continue running with minimal disruption.

If you’re using WASI node pools in AKS, the last day you can create a new one is May 5. You can continue using existing WASI workloads, but it’s time to look at alternatives for new developments and upgrades. You shouldn’t wait until Microsoft’s own WASI AKS service stops working; you can start planning your transition now, with official support for two alternative approaches.

From Krustlets to what?

The big issue for AKS WASI node pools was its dependency on the experimental Krustlet project, which used Rust to build WebAssembly-ready Kubelets. Unfortunately, even though Krustlet was a Cloud Native Computing Foundation Sandbox project, it’s no longer maintained, as team members have moved on to other projects. With no maintainers, the project would be left behind as both Kubernetes and WebAssembly continued to evolve.

With it no longer possible to rely on a key dependency, it’s clear that Microsoft had no choice but to change its approach to WebAssembly in AKS. Luckily for Microsoft, with AKS offering a managed way to work with Kubernetes, it still supports the wider Kubernetes ecosystem via standard APIs. That allows it to offer alternate approaches to running WASI on its platform.

Run WebAssembly functions on AKS with SpinKube

One option is to use another WASI-on-Kubernetes project’s runtime. SpinKube has been developing a shim for the standard Kubernetes container host, containerd, which lets you use runwasi to host WASI workloads without needing to change the underlying Kubernetes infrastructure. Sponsored by WebAssembly specialist Fermyon, Spin is part of a long heritage of Kubernetes tools from a team that includes the authors of Helm and Brigade.

SpinKube is a serverless computing platform that uses WASI workloads and manages them with Kubernetes. Its containerd-shim-spin tool adds runwasi support, so your nodes can host WASI code, treating it as standard Kubernetes resources. Nodes host a WASI runtime and are labeled to ensure that your workloads are scheduled appropriately, allowing you to run both WASI and standard containers at the same time, as well as tools like KEDA (Kubernetes Event-driven Autoscaling) for event-driven operations.

Other Spin tools handle deploying and managing the life cycle of shims, ensuring that you’re always running an up-to-date version and that the containerd shim is deployed as part of an application deployment. This allows you to automate working with WASI workloads, and although this requires more management than the original WASI node pools implementation, it’s a useful step away from having to do everything through the command line and kubectl.

Microsoft recommends SpinKube as a replacement for its tool and provides instructions on how to use it in AKS. You can’t use it with a Windows-based Kubernetes instance, so make sure you have a Linux-based AKS cluster to work with it. Usefully you don’t need to start from scratch as you can deploy SpinKube to existing AKS clusters. This approach ensures that you can migrate to SpinKube-based WASI node pools and keep running with Microsoft’s own tools until you’ve finished updating your infrastructure.

Deploying SpinKube on AKS

Although it’s technically available through the Azure Marketplace, most of the instructions for working with SpinKube and AKS are based on you installing it from the platform’s own repositories, using Kubernetes tools. This may be a more complex approach, but it’s more in line with how most Kubernetes operators are installed, and you’re more likely to get community support.

You will need the Azure CLI to deploy SpinKube after you have created an AKS cluster. This is where you run the Kubernetes kubectl tools, using your AKS credentials. Your cluster will need to be running cert-manager, which can be deployed using Helm. Once that’s in place, follow up by installing SpinKube’s runtime-class-manager and its associated operator. This can be found in its own repository under its original name, KWasm.

You can now deploy the containerd shim to your cluster via kubectl, using the annotate node command. This informs the runtime-class-manager to deploy the shim, labeling nodes that are ready to use. You now can add the SpinKube custom resource definitions and runtime classes to the cluster, using kubectl to copy the spin components from GitHub and apply them to your cluster. Once these are in place, you will use Helm to deploy the spin-operator before adding a SpinAppExecutor.

Getting up and running is a relatively complex set of steps, however, you do have the choice of wrapping the entire deployment process in an Azure CLI script. This will allow you to automate the process and repeat it across application instances and Azure regions.

Once the SpinKube nodes are in place, you can bring your WASI applications across to the new environment. Spin is designed to load WASI code from an OCI-compliant registry, so you will need to set one up in your Azure infrastructure. You also have the option of using a CI/CD integrated registry like the one included as part of the GitHub Packages service. If you take this route, you should use a GitHub Enterprise account to keep your registry private.

With this approach, you can compile code to WASI as part of a GitHub Action, using the same Action to save it in the repository. Your AKS application will always have access to the latest build of your WASI modules. Like all Kubernetes applications, you will need to define a YAML description for your code and use the containerd shim as the executor for your code.

Use WASI microservices on AKS with wasmCloud

As an alternative to SpinKube, you can use another CNCF project, wasmCloud. Here you need a Helm chart to install the various wasmCloud components at the same time. This requires having the Azure CLI and kubectl manage AKS, as there’s no integration with the Azure Portal. At the same time, as there is quite a different architectural approach, you need to start from scratch, rearchitecting your cluster and application for use with wasmCloud.

Start by creating a Kubernetes namespace for wasmCloud, before using Helm to install the wasmCloud platform components. Once the pods have restarted, use kubectl to start a wasmCloud instance and then deploy the components that make up your application. WasmCloud has its own command-line management tool, and you need to forward traffic to the management pod to use it.

Again, you must use YAML to describe your application; however, now you’re using wasmCloud’s own orchestration tools, so you will use its descriptions of your application components. Once complete, you can use the command-line tool to deploy and run the application. WasmCloud is designed to support a component model for building and running applications, with the intent of delivering a standard way of describing and calling WASI components, with support from Cosmonic.

A philosophical difference

With two alternatives for Microsoft’s WASI node pools, it’s clear there’s still a future for WebAssembly on AKS. But why two quite different ways of working with and running WASI?

The underlying philosophies of wasmCloud and SpinKube are very different; wasmCloud is designed to host full-scale WASI-based applications, assembling and orchestrating microservice components, while SpinKube is very much about quickly launching WASI-based functions, scaling from zero in very little time as an alternative to services like AWS Lambdas or Azure Functions. Having support for both in AKS makes sense so you can choose the right WASI platform for your needs.

We’re still exploring what WebAssembly can do for us, so it’s good we’re not being locked into only one way to work with it in AKS. Having many different options is very much the Kubernetes way of doing things, as it’s a way to build and manage distributed applications. Like our PCs and servers, it’s a flexible and powerful platform ready for your applications, whether they’re serverless functions or large-scale enterprise services, written in whatever language, and hosted in whatever containerd-compliant environment you want.