WASM on Kubernetes made simple with SpinKube

WASM and Kubernetes

The idea of running WASM on K8s isn't new. It was first introduced by the Krustlet project built at Microsoft and then found a more generic support in the runwasi initiative. Runwasi provides a library that lies at the foundation of containerd-shim-wasm that allows to run generic WASM workloads on top of containerd using one of the leading WebAssembly runtimes (wasmtime,wasmer or wasmedge).

SpinKube provides a higher-level containerd shim (built on top of the wasm shim) for running Spin application bundles on container hosts. It also gives us spin-operator and a CRD that allows us to manage Spin apps in Kubernetes as if they were regular container deployments - with support for scheduling constraints, resource allocations and HPA.

The selling points of WebAssembly are tiny binary sizes, lightning fast initialization and low resource footprint. All great for maximum efficiency and cost optimization. Or, as we like to put it at PerfectScale by DoiT - for keeping your clusters lean.

So quite naturally I was curious to take SpinKube for a spin. I also like to go into a bit more detail in order to understand how things work. So here's my own walkthrough that goes beyond the basic "getting started".

Things we're gonna need:

• A k3d cluster
• A SpinKube-enabled node
• A Spin application

As a side note - if running WASM on Kubernetes excites you as much as it does me - join our upcoming webinar with Saiyam Pathak of Civo, where we'll dive deeper into WASM and how it fits into the cloud native landscape.

A k3d cluster with SpinKube

Create the Cluster

If you're a cloud native aficionado like myself - high chance you already have a k3d cluster running on your machine. If you're ok with using it for this experiment - skip to the next section. If not - install k3d and then create the cluster with the following command:

 k3d cluster create spincluster \
  --api-port 6550 \
  -p "8081:80@loadbalancer" \
  --agents 1 \
  --registry-create spincluster-registry:12345

This creates a cluster with:

• an API server exposed on port 6550
• ingress load balancer exposed on local port 8081
• just one agent node - because I want to have one 'regular' node for running Linux containers and one Spin-enabled node for running Spin applications (which we'll add in the next section).
• internal OCI registry - it will be available at localhost:12345 from our docker host and at spincluster-registry:5000 from within k3d nodes.

Add a Spin-enabled Node

The SpinKube project is providing a container image which includes the containerd-shim-spin already installed. Let's create a k3d node from it:

k3d node create spin-node -c spincluster \
--k3s-node-label spin=enabled \
--image ghcr.io/spinkube/containerd-shim-spin/k3d:v0.13.1

Verify the all nodes are up and running:

docker exec  k3d-spin-node-0 sh -c "ls bin/containerd*"

And for another reality check - let's verify that the containerd shim for Spin is installed in the node we've added:

 docker exec  k3d-spin-node-0 sh -c "ls bin/containerd*"

Yup, the shim is there. Now let's configure the cluster.