Configuring Wasm On Azure Kubernetes Service (AKS)

When it comes to deploying new workloads, new companies emerging and needing to deploy application stacks, or moving from legacy, Kubernetes seems to be the de facto standard path that everyone is moving towards. However, Kubernetes is an orchestrator, as in it needs a workload to orchestrate.

That’s where Wasm comes into play.

In this blog post, you’ll learn how you can configure Azure Kubernetes Service (AKS) to run WebAssembly (Wasm) workloads.

Why Extra Tooling?

Kubernetes, by itself, is an orchestration system. It gives you the ability to do things like deploy application stacks at scale, self-heal those app stacks with the use of Kubernetes Controllers, and run several types of workloads from containers to Virtual Machines (VM). The thing is that Kubernetes, by default, does not know how to talk to these workloads. For example, Kubernetes needs the Container Runtime Interface (CRI) to run containers.

With Wasm, it’s no different. Kubernetes doesn’t know how to run it by default. Because of that, it needs extra tooling to sit in the middle (sometimes called a shim) between the Wasm binaries and itself.

Enter Spin and Kwasm

Spin And Kwasm

As mentioned in the previous section, Kubernetes needs a way to run Wasm workloads. For AKS, that way is Kwasm and Spin.

Spin is a serverless framework that’s designed to run Wasm in the cloud. You can see it as kind of like the Knative for Wasm. It’s meant to be lightweight, easily run, and not take up too many resources. The goal of spin is to easily implement “Wasm micrososervices”. Spin often reminds people of a combination of serverless and a library/package with all of the tools you need embedded (Spin also has great Component support). So, if Spin is how Wasm workloads are run, how does Kubernetes know how to talk to Wasm?

Kubernetes knows how to talk to Wasm by using a Shim, and in this case, that Shim is Kwasm. Kwasm is a Kubernetes Operator that adds support to Kubernetes for your Wasm workloads. One thing to point out, and hopefully this will change, is that Kwasm is still very much in an alpha stage. In fact, per the website, which you can find here, it states that Kwasm should only be used for development or testing purposes. Hopefully that means Microsoft will dedicate full support for it by May 2025.

Please note: This is a new method of deployment. Originally, you’d use the Wasi runtime on the Kubernetes Worker Node much like with a CRI like so:

az aks nodepool add --resource-group devrelasaservice \\
--cluster-name aksenvironment01 \\
--name mywasipool \\
--node-count 1 \\
--workload-runtime WasmWasi

However, come May of 2025, Microsoft will no longer support this method in favor of Spin and Kwasm.

Installation and Configuration

Now that you know why you’d use Spin and Kwasm, let’s dive into the installation and configuration of Wasm on AKS.

First, you’ll need one prerequisite, which is cert-manager to handle SSL for you inside of the cluster. It looks like either Spin, Kwasm, or both need it, but the documentation doesn’t say which one needs it.

1. Install the CRDs for cert-manager.

kubectl apply -f <https://github.com/cert-manager/cert-manager/releases/download/v1.14.3/cert-manager.crds.yaml>

1. Install cert-manager with Helm.

helm repo add jetstack <https://charts.jetstack.io>
helm repo update

helm install \\
  cert-manager jetstack/cert-manager --version v1.14.3 \\
  --namespace cert-manager --create-namespace \\
  --wait

1. Install Kwasm with Helm.

helm repo add kwasm <http://kwasm.sh/kwasm-operator/>

helm install \\
  kwasm-operator kwasm/kwasm-operator \\
  --namespace kwasm --create-namespace \\
  --version 0.2.3 \\
  --set kwasmOperator.installerImage=ghcr.io/spinkube/containerd-shim-spin/node-installer:v0.15.1

1. Annotate the Worker Nodes that are currently running to support Wasm. In the example below, it specifies all nodes, but you don’t have to specify all nodes.

kubectl annotate node --all kwasm.sh/kwasm-node=true

1. Deploy the Spin CRDs.

kubectl apply -f <https://github.com/spinkube/spin-operator/releases/download/v0.2.0/spin-operator.crds.yaml>
kubectl apply -f <https://github.com/spinkube/spin-operator/releases/download/v0.2.0/spin-operator.runtime-class.yaml>

1. Deploy the Spin Operator with Helm.

helm install spin-operator --version 0.2.0 \\
  --namespace spin-operator --create-namespace \\
  --wait oci://ghcr.io/spinkube/charts/spin-operator

1. Deploy the Spin Executor, which is how Spin apps can successfully run (execute).

kubectl apply -f <https://github.com/spinkube/spin-operator/releases/download/v0.2.0/spin-operator.shim-executor.yaml>

Spin and Kwasm are now deployed on your AKS cluster.

Running An App

Once Kwasm and Spin are deployed, you can run an app to test out the configuration on your AKS cluster.

The example below is a Kubernetes Deployment that uses a Rust container image that’s packaged with a Wasm binary. Save the file as deployment.yaml and run it with kubectl apply -f deployment.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wasm-spin
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wasm-spin
  template:
    metadata:
      labels:
        app: wasm-spin
    spec:
      runtimeClassName: wasmtime-spin-v2
      containers:
        - name: spin-hello
          image: ghcr.io/spinkube/containerd-shim-spin/examples/spin-rust-hello:v0.15.1
          command: ["/"]
          resources:
            limits:
              cpu: 100m
              memory: 128Mi
            requests:
              cpu: 100m
              memory: 128Mi

Closing Thoughts

Wasm is a very interesting space for two reasons. First, it’s new and my prediction is that by 2028, it’ll be the “new standard” and containerization will be “legacy” for new organizations. Second, there are a lot of moving parts. It makes things interesting, but it’s certainly difficult to keep up with all of the innovation around Wasm.

Overall, it’s a great technology and a lot of fun to use with a great production use case.